One of the challenges of managing a large estate of VMs has been keeping track and up to date with the VMware Tools packages. It was probably that particular exacerbated by the fact that a hardware level change would require a reboot – and the fact that certain operating systems driver models like Microsoft Windows would require a reboot to update drivers that back virtual devices such a NIC adapters, graphics cards, controls and so on.

Introducing “VM Compatibility”

Starting with vSphere 5.1 were moving away from a version model around hardware-levels and VMware Tools towards a more “VM Compatibility” model.  What that means is the vCenter will check the hardware-level and VMware Tools service to check that the VMs configuration is “supported”. That way you avoid doing unnecessary hardware level and tools upgrades merely for ticking the box marked “supported”. It’s part of process meant to avoid that thing that happens with an awful lot of ISVs where your SR bumped because all the ticks are not in the right place.  It’s become a bit of joke in our industry “have you applied the latest service pack”. The other good news is that coupled to this new approach is the broadening support for old hardware levels and tools versions on the vSphere5.1 platform.

So lets work backwards. vSphere5.1 introduces virtual machine hardware level 9 (vSphere 5.0 was hardware-level 8), and new version of VMware Tools (yes, VMware Tools 5.1. You cannot fault our imagination on the version numbering front!). However, starting with vSphere5.1 we will also support hardware-levels 8, 7 and 4 and VMware Tools versions as far back as version 4.x. This should mean we can upgrade from one flavour of vSphere to another without having to factor in a virtual hardware-level and tools upgrade as well. They can be done in windows aligns with other maintenance windows that suit the business (something I’ve recommended to customers for a while, but now it gets the proper stamp of approval from VMware).

There is a new status that appears on the properties of VM in the all-new web-client. However, the vSphere Client and CLIs still reference the older “hardware level” and VMware Tools parameters, that’s good news for PowerCLI fans out there – it means no need to modify your scripts that check this in this release.

part4-image1.png

part4-image2.png

What Compatibility Level to Choose

The upgrade process in the vSphere5.1 release is much the same as it is always been. So it still the case that you can upgrade, but not downgrade (unless you take a snapshot first, of course). When you create a new VM you get to chose what compatibility level you want to use choose – the more “mixed” your environment the more “populated” list will be. So if you only have ESX 5.0 and ESX 5.1 in the target cluster you won’t see compatibility modes for ESX 4.x. You can also set the default compatibility level on the properties of the cluster to save you having to select each and every time. One caveat – if you doing a rolling upgrade (gradually moving your clusters from one distro of ESX to another) and your creating a new VMs, make sure you choose the lowest level of compatibility to make sure your VM can be scheduled on all the available hosts in cluster.

And Finally – Goodbye Mr Reboot!

And finally – the really good news – what with changes in many guest operating systems and improvements in vSphere5.1 the days of having to do reboots for VMware Tools updates will be going away. So with all this work – hopefully this will less of a pain-point than it has been in the past.