ben.neise.co.uk

This is based on Hugo Peeters’ script to Add Snapshot Information to the VI Client using Powershell.

Our users occasionally need larger machines created for packaging big applications.  After increasing the size, we used to append the VM Object name (e.g, “PACKVM01 – 10GB”), but this caused a mismatch between the virtual machine object name in VIC and the DNS host name. Also, it looked untidy!

We needed a new way for VIC users to be able to tell which were the larger machines, so I modified Hugo’s script to add disk size as a custom attribute.

# Add disk size as a custom attribute
 
$VCServerName = “MYVCSERVER”
$VC = Connect-VIServer $VCServerName
$SI = Get-View ServiceInstance
$CFM = Get-View $SI.Content.CustomFieldsManager
 
# Variables
$CustomFieldName = “HD Size (GB)”
$ManagedObjectType = “VirtualMachine”
 
# Check if the custom field already exists
$myCustomField = $CFM.Field | Where {$_.Name -eq $CustomFieldName}
If (!$myCustomField){
	# Create Custom Field
	$FieldCopy = $CFM.Field[0]
	$CFM.AddCustomFieldDef($CustomFieldName, $ManagedObjectType, $FieldCopy.FieldDefPrivileges, $FieldCopy.FieldInstancePrivileges)
}
 
$objVMs = Get-VM
ForEach ($objVM in $objVMs){
	$objTotalDiskSize = 0
	# Sum the total size of all disks attached to the VM
	ForEach	($objHardDisk in ($objVM | Get-HardDisk)){
			$objTotalDiskSize += ($objHardDisk.CapacityKB/1024/1024)
			}
	If ($objTotalDiskSize){
		# Round the size to one decimal place
		$objHDSize = "{0:N1}" -f $objTotalDiskSize
		$VMView = $objVM | Get-View
		$VMView.setCustomValue($CustomFieldName,$objHDSize)
	}
}

We frequently need to create new virtual port groups on our ESX hosts with VLAN tags which correspond to pre-assigned DHCP scopes. I wrote this PowerShell script to create the new VPG across all hosts.

$strNewVPG = "newVirtualPortGroup"
$strNewVlanTag = "123"
 
$ObjAllHosts = Get-VMHost | Sort-Object -Property Name
 
ForEach($objHost in $ObjAllHosts){
    $strVSwitch = Get-Virtualswitch -VMHost (Get-VMHost $objHost) | where-object { $_.Name -match "VMswitch" }
    Write-Host "Adding Virtual Port Group" $strNewVPG "with VLAN Tag" $strNewVlanTag "to" $objHost
    New-VirtualPortGroup -Name $strNewVPG -VirtualSwitch $strVSwitch -VLanId $strNewVlanTag
}

This assumes that your virtual port group is on a switch called “VMSwitch”. You could easily modify this to accept parameters from the command-line, rather than being specified in the script.

When it comes to re-naming existing virtual port groups across hosts there doesn’t seem to be an inbuilt cmdlet, instead I wrote a script to delete the old VPG, and create a new one with the same VLAN tag:-

$strOldVPG = "OldVPGName"
$strNewVPG = "NewVPGName"
$ObjAllHosts = (get-vmhost | Where-Object { $_.Name -notlike "e3acspacesxbu.lim.emea.dell.com" } | Sort-Object -Property Name)
ForEach($objHost in $ObjAllHosts){
    Write-Host " "
    Write-Host "Changing Virtual Port Group Settings on" $objHost
    $strVSwitch = Get-Virtualswitch -VMHost (Get-VMHost $objHost) | where-object { $_.Name -match "VMswitch" }
    $objOldVPG = Get-VirtualPortGroup (Get-VMHost $objHost) | where-object { $_.Name -match $strOldVPG }
    Write-Host "Removing Virtual Port Group" $objOldVPG
    Remove-VirtualPortGroup -VirtualPortGroup $objOldVPG -confirm:$false -whatif
    Write-Host "Adding Virtual Port Group" $strNewVPG "with VLAN Tag" $objOldVPG.VLanID
    New-VirtualPortGroup -Name $strNewVPG -VirtualSwitch $strVSwitch -VLanId $objOldVPG.VLanID -confirm:$false -WhatIf
}

Run it once to check it’s doing what you want, then remove the -WhatIf tags to run it for real.

Virtual Foundry’s article on hardening the VMX file to prevent VMware Tools vulnerabilities made me a little bit nervous, but after reading it. Most of the guests on our farm are single user, non-persistent machines, and therefore even if a user is capable of causing damage, the effects are limited.

The article is still pretty interesting, although in most cases I think the vulnerabilities are academic, and only worth taking precautions against in the most demanding of environments.

VMware vCenter Server

Video from vCritical showing installation and GUI on the new vCenter.

While speaking to a gentleman from VMware last year, I gently chided Citrix for their grand-renaming, and made comment that at least VMware didn’t succumb to this modern plague of replacing perfectly good names with ones formed from pure marketing-fluff. It was shortly after this that VMware announced the change from Virtual Infrastructure to vSphere.

Alongside this well publicised change; VMware Toolkit (for Windows) is now called vSphere PowerCLI.

I sometimes wonder if all this random capitalisation is part of some great scheme to prevent the world’s pinky fingers from atrophy by having them constantly reach for the Shift key.

There’s also a Twitter account, if you’re into that sort of thing.

I’ve started looking at the recently released beta of Vizioncore’s Virtualization EcoShell, which is a VMware tailored version of PowerGUI.

Both are GUI front-ends for (among other things) VMware’s Powershell based VI Toolkit, which I’ve talked about before.

I never got the full benefit from PowerGui, as by the time I’d realised there was more to it than the (very good) script editor, I’d already developed a lot of the scripts I needed – scripts which PowerGui would have been able to generate for me a lot more quickly (c’est la vie).

EcoShell has the ability to export some nice looking reports (although the Visio based vDiagram functionality still doesn’t work for me).

There’s more information on EcoShell over at Virtua-Al.

Hal Rottenberg’s book Managing VMWare Infrastructure with Windows PowerShell is now available for pre-order.

I’m a big fan of Hal‘s; he’s helped me out a few times on the VMware VI Toolkit forums. Sadly shipping to the UK is over $76, meaning that I’ll have to either wait for a digital copy, or see if a local publisher/distributer takes it up.