vSphere Evaluator’s Guide
Eric Siebert at vSphere-Land.com points out that VMware have published a 120-page vSphere Evaluator’s Guide that’s chock-full of information about the new features (including a nice little demo of PowerCLI).
Definitely worth checking out.
VMware PowerCLI 4.0 released
I came back from a week’s holiday this morning to find that VMware PowerCLI 4.0 has been released as the successor to VI Toolkit 1.5. The jump from 1.5 to 4.0 is for version number consolidation, rather than being than indicitive of major changes.
They have however fixed one of the bugs that’s been annoying me, which is the inability to change drives to non-persistent, so I’ll need to revisit some of my old scripts from v1.0 and check that they still work.
You can download it from the community page. I’ll follow up with more information when I get a chance to investigate it fully.
VMware’s vSphere 4 Cheat Sheet
VMware’s vSphere 4 PDF cheat sheet from boche.net.
“VMware supports 4x more guest operating systems than Microsoft. In fact, VMware supports more versions of Windows than Microsoft.”
pwned!
Check if servers in a text list exist as VMware VMs
I got handed a list of around 1000 servers today, and asked if any of them were part of our VI environment.
Rather than work through it by hand, I wrote the following script:
# Check if Servers on Text List exist on VMware # Assumes that the VM object name matches the server's DNS name # Set this to the text file containing the list of servers, one per line $strServerList = "C:\path\to\textFile.txt" # Create empty array for servers which are found $arrFoundServers = @() # Assign all of the VM objects to a variable $objVMs = Get-VM # Read the list of servers, and assign it to a variable $strServersOnList = (Get-Content $serverlist) # Loop through each VM forEach ($objVM in $objVMs){ # Loop through each server on the list forEach ($strServer in $strServersOnList){ # If the current VM object name matches the current item on the list if ($objVM.Name -Like $strServer){ # Add it to the array of found machines $arrFoundServers += $objVM } } } # Display the list of found machines $arrFoundServers
If your VM Object names do not match the DNS names on the list, then this won’t work, but I suppose you could combine this with some logic from the script I wrote to find mismatches.
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
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) } }
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.
