WilliamLam.com

Quick Tip - Using the CLI to upgrade to a specific VM virtual hardware version in vSphere 5.5

by // 4 Comments

For those of you who usually use the "legacy" vSphere C# Client to perform virtual machine virtual hardware upgrade (also known as Virtual Machine Compatibility) should know that the default behavior is to automatically upgrade to the latest supported version. This is usually not an issue, however with vSphere 5.5 if you do perform this upgrade, one caveat to be aware of that you will NOT be able to edit the virtual machine configurations using the vSphere C# Client afterwards. A confirmation dialog is even presented to warn the user before performing this operation and that the virtual machine can only be manage through the vSphere Web Client.

Note: Even though the virtual machine settings can not be managed/configured using the vSphere C# Client, you can still use the various vSphere API/CLIs to manage the virtual machine and those are fully supported.

I had noticed a couple of comments on Twitter the other day and even at VMworld Barcelona that this was not ideal that the vSphere C# Client automatically upgraded to the latest version. I know there are some folks that would have liked to upgrade to a specific version of virtual hardware. Luckily, you can easily do so by using the vSphere API/CLI such as PowerCLI for example if you have paid vSphere license.

You can use the Set-VM cmdlet and  specify the -Version property, here is the syntax for the command:

Set-Vm -VM (Get-VM -Name [VM-NAME]) -Version v[HW-VERSION]

Here is a screenshot of upgrading a VM called "Duncan" from vHW8 to vHW9:

Now this is great for customers who have a vSphere license that allows for both read/write access to the APIs which PowerCLI and other CLIs leverage. For customers using Free ESXi or just want a quick and simple way of upgrading to a specific virtual hardware version, you can leverage vim-cmd utility which is found in the ESXi Shell.

You can use the following command to upgrade to a specific virtual hardware version (you will need to specify the VM-ID by using vim-cmd vmsvc/getallvms):

vim-cmd vmsvc/upgrade [VM-ID] vmx-[HW-VERSION]

Here is a screenshot of upgrading a VM called "Cormac" from vHW7 to vHW9:

ESXi 5.5 introduces a new Native Device Driver Architecture Part 1

by // 12 Comments

With a new release of vSphere, many of us are excited about all the new features that we can see and touch. However, what you may or may not notice are some of the new features and enhancements that VMware Engineering has made to the underlying vSphere platform to continue making it better, faster and stronger. One such improvement is the introduction of a new Native Device Driver architecture in ESXi 5.5. Though this feature is primarily targeted at our hardware ecosystem partners, I know some of you have asked about this and I thought it might be useful to share some of the details.

Note: If you are a hardware ecosystem partner and would like to learn more, please reach out to your VMware TAP account managers.

If we take a look back at the early days of ESX, VMware made a decision to use Linux derived drivers to provide the widest variety of support for storage, network and other hardware devices for ESX. Since ESX and specifically the VMkernel is NOT Linux, to accomplish this we built a translation (shim) layer module called vmklinux which sits in between the VMkernel and drivers. This vmklinux module is what enables ESX to function with the linux derived drivers and provides an API which can speak directly to the VMkernel.

Here is a quick diagram of what that looks like:

So why the change in architecture? Since the stability, reliability and performance of these device drivers are importantly critical to ESX(i) second to the VMkernel itself. There is actually a variety of challenges with this architecture in addition to the overhead that is introduced with the translation layer. The vmklinux module must be tied to a specific Linux kernel version and the continued maintenance of vmklinux to provide backwards compatibility across both new and old drivers is quite challenging. From a functionality perspective, we are also limited by the capabilities of the Linux drivers as they are not built specifically for the VMkernel and can not support features such as hot-plug/ To solve this problem, VMware developed a new Native Device Driver model interface that allows a driver to speak directly to the VMkernel and removing the need for the “legacy” vmklinux interface.

Here is a quick diagram of what that looks like:
What are some of the benefits of this new device driver model?
  • More efficient and flexible device driver model compared to vmklinux
  • Standardized information for debugging/troubleshooting
  • Improved performance as we no longer have a translation layer
  • Support for new capabilities such as PCIe hot-plug

This new architecture was developed with backwards compatibility in mind as we all know it is not possible for our entire hardware ecosystem to port their current drivers in one release. To that extent, ESXi 5.5 can run a hybrid of both “legacy” vmklinux drivers as well as the new Native Device Driver. Going forward, VMware will be primarily investing in the Native Device Driver architecture and encourage new device drivers to be developed using the new architecture. VMware also provides an NDDK (Native Driver Development Kit) to our ecosystem partners as well as a sample Native Device Driver which some of you may have seen in the release of vSphere 5.1 with a native vmxnet3 VMkenel module for nested ESXi.

Hopefully this has given you a good overview of the new Native Device Driver architecture and in part 2 of the article I will go into a bit more details on where to find these drivers, which vendor supports this new architecture today and how they are loaded.

How to change hardware serial number for Mac OS X Guest?

by // 5 Comments

There was an interesting question that was asked the other day about changing the hardware serial number for an Apple Mac OS X guest as the generated serial number is not compatible with services such as Apple Caching Service or iMessage. I recall seeing this question get asked awhile back, but I could not immediately find the answer but thanks to Darius Davis (VMware Engineer) who provided the quick answer.

We have a facility to generate a "short" serial number which should be suitable for recent Apple software.  The option is enabled by default for OS X 10.9 guests.  To enable it for earlier guest OS versions, you'll need to power off your virtual machine and edit its configuration to add the following option:

SMBIOS.use12CharSerialNumber = "TRUE"

As mentioned by Darius, if you are running Mac OS X VM prior to 10.9 (Mavericks) you will need to add the following advanced VM setting by first powering it off and then add the above setting. There are two recommended ways of performing this change using either the vSphere C# Client or vSphere Web Client and instructions are listed below.

Note: Though you can also edit the VMX configuration file by hand, for those that are not familiar on how to reload the configuration file, it is best you use the UI.

vSphere C# Client:
Edit Settings -> VM Options -> Advanced -> Edit Configurations

vSphere Web Client:
Edit Settings -> Options -> Advanced -> General -> Configuration Parameters

Once you have added the advanced setting, you can now power back on your Mac OS X VM and when you click on the "About this Mac" option on the upper left hand side of the Apple icon you should see the Mac OS X version string. Click on the version string twice and you should now see the serial number that is generated which should not be longer than 12 characters.

As of writing this article the latest Mac OS X 10.9 (Mavericks) is not yet officially on the VMware HCL for latest release of ESXi 5.5 as the OS just came out recently, however it is still possible to create the a Mac OS X 10.9 guest using the new vSphere Web Client. Be sure to keep your eyes on the VMware HCL for support of Mac OS X 10.9 on ESXi 5.5 here.