Thin Provisioning in ESX 3.5
One of the nice new features of vSphere 4 is thin provisioning of virtual disks. Thin provisioned (TP) disks will be familiar if you’ve ever used VMware Workstation where they are used by default, (you need to select Allocate All Disk Space Now to create thick disks). Essentially, rather than allocate all disk space at creation, disk space is allocated on the fly, meaning that a 50GB virtual disk with only 5GB being used by the guest, would only consume 5GB of space. This can obviously result in real savings, but it does have an impact on machine performance due to the increased disk provisioning overhead as the machine grows.
VirtualGeek had an interesting article on thin-provisioning in vSphere 4, and whether this should be done at the VM level, or at the array level. As well as containing a good description of the different disk types (Thick, Thin & Eagerzeroedthick), there was a brief mention of using TP disks in VI 3.5. This was the first time I’d heard of this, and despite it’s unsupported nature, it deserved some consideration. We’re still using VI 3.5, and disk space is probably our number one capacity constraint; the potential opportunity to reduce our disk-footprint without investing in any new hardware or software was too good to pass up.
I soon discovered that we already used TP disks in a very limited way. One of the options in vCenter’s Clone to Template operation allows the creation of a compact template, and we had been using this to reduce the amount of space used by templates. Templates created in this manner use TP disks, and if you convert that template to a machine, the machine inherits the TP disk. However VMs deployed from the template are created with normal (thick) disks. If you’re curious to see if you’ve got any existing TP machines, Eric Gray wrote a PowerShell script to find existing thin provisioned disks.
After only a little more digging, my dream of being lauded for increasing our free space overnight came to an end. In an article on Virtual Future, Sven Huisman wrote:
Apparently, when you move a VM with a thinprovisioned disk from vCenter server, it converts to a thick-disk. This is because thinprovisioned disks is not integrated with vCenter server yet.
Also, when you deploy from a template with a thinprovisioned disk, the new VM will get a thick-disk.
I imagine this is what they mean by “unsupported”, and this is why the TP functionality in VI 3.5 is largely undocumented.
This changes the conversion process from a one-off time-consuming action to something that would need to be done on an ongoing basis. I think we’ll just have to wait until we get the chance to upgrade to vSphere 4.
Add Drive Persistence State to the VI Client using Powershell
I’ve further adapted Hugo’s script to add a custom attribute which shows the drive persistence state(s) when the script was run.
The script also adds drive state information for templates as well as VM objects.
# Add drive persistence as a custom attribute for VMs and Templates $VCServerName = "MyVCServer" $VC = Connect-VIServer $VCServerName $SI = Get-View ServiceInstance $CFM = Get-View $SI.Content.CustomFieldsManager # Variables $CustomFieldName = “HD Persistence” $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) } # Get the machine objects $objVMs = (Get-VM) + (Get-Template) # Loop through each of the machine objects ForEach ($objVM in $objVMs){ $strPersistence = "" $objHardDisks = $objVM | Get-HardDisk # Count the number of hard drives $intHardDisks = ($objHardDisks | Measure-Object).count # Loop through each of the hard disks ForEach ($objHardDisk in $objHardDisks){ # Replace default persisstence states with initials for brevity Switch ($objHardDisk.Persistence) { Persistent { $strPersistenceInitial = "P" } IndependentPersistent { $strPersistenceInitial = "IP" } IndependentNonPersistent { $strPersistenceInitial = "INP" } } # Concatenate the initial onto the persistence string $strPersistence = "$strPersistence" + $strPersistenceInitial # If there are more hard drives to add If ($intHardDisks -gt 1) { # Append a comma and a space (there may be a more elegant way of doing this) $strPersistence = "$strPersistence" + ", " # Count down the number of hard drives $intHardDisks -= 1 } } # Add the $strPersistence to custom attribute $CustomFieldName (HD Persistence) If ($strPersistence){ $VMView = $objVM | Get-View $VMView.setCustomValue($CustomFieldName,$strPersistence) } } # End of script
Storage vMotion from the GUI
While I’m a big fan of the command-line, there are times when you just want to be able to do something from the GUI.
Storage vMotion is usually only available using the rCLI Appliance but this VI plug-in allows you to do this task from the context menu in VIC, simply install, restart VIC if necessary, then get moving those VMs.
An option to move more than one VM at a time would be nice, and you still can’t move non-persistent machines; but it’s still easier than connecting to the rCLI.
Add Disk Size Information to the VI Client using Powershell
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) } }
Creating new Virtual Port Groups in ESX with PowerShell
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.
VMware Tools vulnerabilities
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 preview video
Video from vCritical showing installation and GUI on the new vCenter.
vSphere PowerCLI.
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.
Virtualization EcoShell
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 available for pre-order
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.
