How-tos

Issue using the Count method to count objects with PowerShell 2.0

by

 

I came across a small issue with a little helper script I wrote to count vSphere objects using PowerCLI this morning. It’s been a couple of a weeks since I last did a blog post – things have been very busy, so I have not been able to commit much time over the last few weeks to blogging. As such, I thought I would do a quick post around this small issue I came across earlier. It has more than likely been covered off elsewhere, but will be a good reference point to come back to if I ever forget!

 

So to the issue I saw. Essentially, if an object count is 1 or less, then the object is returned as the object type itself. For example, where only one Distributed Virtual Switch exists in a vSphere environment, and we use the cmdlet, Get-VirtualSwitch -Distributed, a single object is returned of BaseType “VMware.VimAutomation.ViCore.Impl.V1.VIObjectImpl“.

 

However, if we had more than one dvSwitch, then we would get a BaseType of “System.Array” returned.

 

We are able to use the Count() method on an array with PowerShell version 2.0, but are not able to use the Count() method on a single object. The work around I found here (when using PowerShell 2.0) is to cast the object type specifically as an array.

So in the case of our dvSwitch example above, originally we would have done:

@dvSwitchCount = (Get-VirtualSwitch -Distributed).Count

 

To cast this as an array, and therefore having an accurate count of the objects, whether there are no members, one member, or more, we would use:

@dvSwitchCount = @(Get-VirtualSwitch -Distributed).Count

 

Note the addition of the “@” sign – used to cast the variable as an array.

Jonathan Medd also kindly pointed out that this is fixed with PowerShell 3.0 – have a read of the new features to see the addition that allows .Count to be used on any type of object over here.

PowerCLI – creating port groups and specifications to modify port groups

by

I wanted to quickly create some standard VM port groups across a particular vSwitch for all hosts in my lab / testing environment at work. Since I was using Standard vSwitches and not a dvSwitch, I didn’t feel like using the GUI to create these on every individual ESXi host. In addition to creating the port group on each vSwitch, I also wanted to change the security policy on each for Promiscuous mode to “Accept”. The reason for this being that this port group is going to be used to run virtual nested ESXi hosts, and this is required to allow nested VMs to communicate on the network.

 

So the obvious solution here for me was to create a quick PowerCLI script to create these port groups on all hosts and set the security option for each too. Here is the script:

 

$vSwitch = "vSwitch0"
$portgrpname = "vInception Portgroup"
$AllConnectedHosts = Get-VMHost | Where {$_.ConnectionState -eq "Connected"}

foreach ($esxihost in $AllConnectedHosts) {
	$currentvSwitch = $esxihost | Get-VirtualSwitch | Where {$_.Name -eq $vSwitch}
	New-VirtualPortGroup -Name $portgrpname -VirtualSwitch $currentvSwitch -Confirm:$false
	$currentesxihost = Get-VMHost $esxihost | Get-View
	$netsys = Get-View $currentesxihost.configmanager.networksystem
	$portgroupspec = New-Object VMWare.Vim.HostPortGroupSpec
	$portgroupspec.vswitchname = $vSwitch
	$portgroupspec.Name = $portgrpname
	$portgroupspec.policy = New-object vmware.vim.HostNetworkPolicy
	$portgroupspec.policy.Security = New-object vmware.vim.HostNetworkSecurityPolicy
	$portgroupspec.policy.Security.AllowPromiscuous = $true
	$netsys.UpdatePortGroup($portgrpname,$PortGroupSpec)
	
}

 
Keep in mind that this script will create the port group on “vSwitch0” – change this if your vSwitch that is hosting this port group on each host is named differently. It will obviously rely on this vSwitch existing to work. You can also modify the $portgrpname to your own choice of course.

Lastly, you can easily modify this script to change other Security options for the new port group, as the port group specification has already been created in this script. Just use the $portgroupspec.policy.Security object to add other specifications.

Enjoy!
 

Getting up and running with the vSphere 5.1 Web Client

by

Getting up and running with the vSphere 5.1 Web Client and vCenter 5.1 is now easier than before. The steps to follow are listed below, along with the steps you should use if you also have vCenter 5.0 instances to manage with the 5.1 Web Client.

 

  • If you have a vCenter 5.1 Server instance, you’ll just need to install the Web Client using standard installer from the vCenter autorun.
  • Don’t forget to install the latest Adobe Flash too.
  • With vSphere 5.1 you now have integration with the vCenter Single Sign on (SSO) service. If your vCenter server uses the same vCenter Single Sign On server as that which the Web Client uses, then you do not need to manually register vCenter 5.1 instances with the Web Client Server. Instead, just install the Web Client server as normal, and then sign in to it from the local machine at https://localhostl:9443/vsphere-client or remotely from another management machine at https://remotemachine:9443/vsphere-client. The vSphere Web Client can now locate these vCenter Server 5.1 systems by using the VMware Lookup Service.
  • If you run into any errors when you try to access the web client via the URL (local or remote), give it a few more minutes if you have just finished the installation. I found that it took my system up to 3 minutes before I could login. This must be due to automatic registration with the Lookup Service taking place in the background.

This definitely makes life a bit easier when setting up a vCenter 5.1 and the Web client, and makes complete sense as VMware have announced that the standard vSphere Client 5.1 (Windows application) is their final release of the vSphere Client software. From then on, everything will be managed via the Web Client!

Also remember that when you are setting up the vSphere web client, you are asked for the IP or FQDN of your vCenter server. If it uses IPv6 and you want to enter the IP address instead of using the FQDN, you must enter it in IPv6 format (ie. enclosing this address in square brackets).

 

If you are still using vCenter 5.0 or have vCenter 5.0 instances, you are still required to use the machine that the Web Client was installed on, and browse to https://localhost:9443/admin-app and then register these vCenter 5.0 instances as per the screenshots below. You do of course also have a couple of options depending on which vCenter Server 5.0 type you are using (Windows or the Appliance).

 

For vSphere vCenter 5.0 Windows instances you’ll still need to register these with the Web Client, login to the Web client on the machine it was installed on using the localhost address:

Register your vCenter Server 5.0 instance by using the IP or FQDN and correct credentials.

Accept and install the security certificate if applicable.

 

If you are using the vCenter 5.0 appliance, then you’ll need to register these instances using the command-line on the appliance. Use the following script to register your vCenter instance:

/usr/lib/vmware-vsphere-client/scripts/admin-cmd.sh register https://[IP or FQDN of the Web Client]:[HTTPS Port Number]/vsphere-client [VC IP Address] [VC Admin username] [VC Admin password]

If you have any special characters in your password, don’t forget to enclose this in single quote marks ( ‘ ).

 

Checking if your SSD supports “TRIM” using FreeNAS 8.x

by

I have been playing with the newer versions of FreeNAS for shared storage on my home VMware vSphere lab recently (after having last used it on version 7.x). I added a spare OCZ Vertex Plus 120GB SSD to my mini-ITX based FreeNAS box and was wondering how TRIM would be handled, if at all with FreeNAS.

 

To check to see if your SSD supports TRIM under FreeNAS, open up a Shell session to your FreeNAS box – i.e. PuTTy, or via the Web GUI. Then issue the following command, specifying your SSD drive where /dev/ada0 is used as an example below. Note that we are using the CAM control program that comes with FreeBSD. Please exercise caution with this command as it has the potential to cause damage if not used correctly!

 

camcontrol identify /dev/ada0

 

If you need to check disk/device names to figure out which one is your SSD, you could use the GUI. Go to Storage -> View Disks, then check the name column for the device names of each disk. Use /dev/diskname in the command above. After running the command above, you’ll get a list of disk information back, just check the “data set management (TRIM)” row to see if TRIM support is enabled or not.

 

I have not yet worked out a way to see if TRIM is actually being actively used yet though – so if anyone has any suggestions or ideas as to how to check that it is actually in use, please let me know!

 

Home labs – adding and modding a dual port Gigabit NIC to the HP Microserver N40L

by

I wanted to add more physical NICs to my HP Microserver N40L machine to use with vSphere. The box comes with an onboard 1GBit NIC, but I wanted to play around with VLANs and multiple uplinks in my home lab. The problem is finding an affordable solution – most dual port NICs that are any use with ESXi (Intel chipset based) cost almost as much as the Microserver itself which is quite off-putting!

After trawling ebay and the VMware HCL I found that that the HP NC360T PCI Express Dual Port Gigabit Network Card would work well with ESXi 5.0 and that I could get these NICs (used) fairly cheap. I picked up a used card off ebay for only £30 ($46.97 US), which was in my budget. Problem was I could not find a card with a low-profile bracket, so I thought I would just make do with the normal bracket and either remove it, or modify it to fit.

The NIC itself has two 1GBit ports, and is based on the Intel 82571EB chipset and offers a 4 lane (x4) PCI Express bus. This means that I could use it on the HP Microserver’s 16x PCI Express slot (which is downward compatible of course). Apparently there are also mods out there that can be used to get this card to work in the x1 slot if you don’t have the x16 slot free – but I haven’t attempted this yet.

I first tried it out without the bracket (by just removing two screws that hold the bracket to the PCB). This worked fine, but was really not a permanent solution, especially for plugging/unplugging cables whilst the machine was powered up.

not a good solution - the NIC without bracket - way too flimsy

 

So out came the tools as I decided to modify the existing bracket to fit the Microserver’s low-profile chassis.

The Intel card's bracket next to the Microserver's blanking plate.

 

HP NC360T PCI Express card with bracket removed

 

Step 1 – I drew a line at the point where the 90 degree bend in the bracket should be for a low-profile card. I then took a junior hacksaw and “scored” this line out (saw a little bit in to weaken the metal).

Step 2 – Now with the score mark in place, I simply used two pairs of pliers to bend the bracket along the score mark, which was now easy and accurate.

bending the bracket on the score mark

 

Step 3 – I marked off where the 90 degree protruding point of the bracket would end, and used the hacksaw to remove the excess. I then cut out a small notch in this top piece for the screw that holds the PCI card in place normally. I attached the bracket back to the NIC and installed in the Microserver.

 

The HP NIC fitted with modified bracket

 

And here is the final result after ESXi 5.0 recognises the new hardware –

The NIC recognised under Network adapters view - ESXi 5.0

If you have managed to find any good PCI Express NICs for the HP N40L Microserver, or have any advice or experiences with mods for hardware and the Microserver, please post in the comments section!