Monthly Archives: March 2013

VMware vSphere 5.1 Clustering Deepdive book review

After procrastinating for months I finally headed over to amazon.com and purchased Duncan Epping and Frank Denneman’s VMware vSphere 5.1 Clustering Deepdive.  The Kindle Edition of the book was only just over $7 and to be perfectly honest I initially didn’t want to pay that.  Having now read through 3/4 of the book I couldn’t be happier with the purchase.

Epping and Denneman have three different editions of the book available on amazon.com for purchase.  The original edition was written for vSphere 4.1 with the subsequent two editions written for 5 and 5.1.  The vSphere 4.1 edition is selling for 99 cents and vSphere 5 edition for $4.99.

My initial hesitation in purchasing the book was because I knew most of the information was already out there on the net.  I’ve done a lot of work with HA and DRS.  I follow both Epping’s and Denneman’s blogs.  VMware have lots of papers on the subjects.  But herein lies the issue.  The information is all over the place.  Clustering Deepdive, on the other hand, provides one central source of information.  It provides a really good strong foundation of how these core features work along with all the various elements VMware utilise behind the scenes to make them work.

While I haven’t completed reading the book yet.  I wouldn’t classify the book as an instruction manual to implement HA and DRS.  You’re still going to need to read some VMware tech guides, play around with the product and get your hands dirty first.  Once you have those fundamentals this book is only going to help you better understand the features and better implement them in practice.  Leading on from that and for the season veterans you’ll then gain a strong understanding of how the technologies work under the covers and really take your knowledge to the next level.

An excellent book and well worth the money for the latest edition.  There’s also been enough changes in HA and DRS over previous vSphere versions that if you’re running old vSphere platforms you might well consider purchasing the other editions of the book as well.   There’s plenty of screenshots throughout the book as references and some well designed diagrams to rap your head around how these features work.

Who cares about Guest OS Version in vCenter

For years I’ve been setting the Guest OS type in VMware vSphere and Workstation and for years it’s bugged me.  What does it really do?  Does it really matter?  Sometimes just for fun I like to set the version to Windows but install Linux.  Each time I’ve always looked out the window towards the sky to make sure it’s not falling.

In the past if I needed to change the Guest OS type (i.e someone was being silly and set a Linux VM to a Windows Guest OS type) I would just power down the VM and change the setting.  Recently I noticed in my vSphere 5.1 environment I couldn’t change the Guest OS anymore.   In vCenter 5.1 there are now two options.  Guest OS and Guest OS Version.  A little research later and as of vSphere 5.1 you cannot change the Guest Operation System settings once the VM has been created.  They will appear greyed out.

guestos01

First, the most obvious thing it does is give us a whole bunch of default recommended values for the specified OS Version when creating a VM.  It can also restrict what devices are available to us to use.

For example if we set the OS Version to MS-DOS we get 16 MB has the default recommended memory and a 2 GB Hard Disk using an IDE controller.

guestos02

If we set it to Windows 2008 R2 (64-bit) we get a default value of 4096 MB for memory and a 40 GB Hard Disk using an LSI Logic SAS Controller.

guestos03

Second, it defines maximum values we can use.   This can be a little misleading because your true maximum values are always dictated but your Sphere version and edition.  I won’t get into this too much as this blog revolves around Guest OS type.  If we set the OS type to Windows 2000 our max vCPU is 8.  Whereas if I set the OS to Windows Server 2012 (64-bit) our max vCPU is 64 under Enterprise Plus Edition.  If I was running Standard Edition we would be limited to 8 vCPUs for both OS types.  Confused yet.

guestos04

Third, and now a more important consequence of selecting the right OS Version is VMware Tools.  If you push out VMware Tools via vCenter it will use the Guest OS Version to determine what Tools version it will attempt to deploy.  Mixing Linux and Windows OS Versions will cause VMware Tools deployment to fail.

Forth, we have a few lesser consequences.  Some VM options are only enabled and available to certain OS Versions.  Fault Tolerance is not supported on certain types of OS and selecting the wrong OS version in vCenter could disable this setting.  The same can be said for HotAdd/Hot-Plug.  The wrong OS version can prevent this feature being used.

In conclusion, setting the OS Type / Version to match the underlining OS is recommended.

  • It provides recommended devices and values for your OS.
  • It limits your maximum values to what the underlining OS will support.
  • Helps in deploying the correct VMware Tools version
  • It allows the use of advanced (yet less common) features like Fault Tolerance and HotAdd/Hot-Plug support.
  • Once it’s set it can’t be change (vSphere 5.1)

References

Ensuring the guest operating system type is set correctly (1005870)

Cannot change the guest operating system selection of a virtual machine in ESXi 5.1 (2020801)

Compare vSphere Editions

Processors and guest operating systems that support VMware Fault Tolerance (1008027)

Downgrade VMware Hardware version -the unsupported way!

I tend to run a pretty tight shop with my VMware infrastructure. I always make sure that everything is up to date and running the latest versions. That usually includes the VM Hardware versions. Until recently this never posed an issue. I’m currently in the progress of migrating a vSphere 5.1 environment to a vCloud Director 1.5 environment (with an ESXi 4.x back end).  The maximum H/W version supported is 7 while my environment is version 8 / 9.

The OVF upload process in vCD 1.5 does a few sanity checks before starting an upload.  If it finds your H/W versin isn’t supported it won’t let you proceed.

vcd_hw01

VMware have three supported ways of downgrading.

1. Revert to a previous snapshot while on H/W version 7.

2. Use VMware Converter and perform a V2V to H/W version 7.

3. Create a new VM on H/W version 7 and attach the disks from the original VM.

All very safe ways but there is a fourth, and totally unsupported, quicker way to downgrade by hacking the VMX config file.

The process is relatively simple.   Inside the VMX file for the VM there are a few critical lines that tell vSphere / ESXi what hardware version the VM is.  By editing this file we can make it think it’s a Version 7 VM rather than 8.  In essence fooling it into think it’s an older version and basically making it just skip the new config values.

To start  Power Down the VM.  Then obtain shell access to the ESXi server that has visibility to the VM’s Datastore.  Then use VI to edit the VMX file of the VM.  If you haven’t used VI it’s pretty straight forward.  I to Insert, X to Delete (you’ll figure it out).

Below is the first 19 lines of the VMX file of my VM running on hardware version 8 on a ESXi 5.1 host.  The critical line to change is the virtualHW.version = “8”.  By changing the 8 to a 7 that’s technically all that’s needed.  I’ve taken it one step further and replaced all the 8’s with 7’s with the exception of the first line.

.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "8"
pciBridge0.present = "true"
pciBridge4.present = "true"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "true"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "true"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "true"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "true"
nvram = "MYSERVERNAME.nvram"
virtualHW.productCompatibility = "hosted"

My updated VMX config below.

.encoding = "UTF-8"
config.version = "7"
virtualHW.version = "7"
pciBridge0.present = "true"
pciBridge4.present = "true"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "7"
pciBridge5.present = "true"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "7"
pciBridge6.present = "true"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "7"
pciBridge7.present = "true"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "7"
vmci0.present = "true"
nvram = "MYSERVERNAME.nvram"
virtualHW.productCompatibility = "hosted"

Now exit VI and save the changes.  Back in vSphere select the VM and select the option “Remove from  Inventory” (don’t Delete from Disk).  Then open the Datastore that has the VM and select the VMX file of the VM and add back into Inventory.  Basically the same way you normally add a VM into the Inventory from a datastore.  If all has gone well when the VM is added back in inside vSphere it will now say VM Version: 7.

You can now happily migrate the VM between ESXi 5 and 4.  In my case create an OVF of the VM and upload it into vCD 1.5. I’ve performed this quite a lot of times without issue. Probably not recommended for production but in a TEST / DEV environment less of an issue.

Appendix
Supported Vmware KB article to Downgrade
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1028019