WilliamLam.com

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.

How to change the default HTML5 VM console port in vSphere 5.5?

by // 1 Comment

A couple of weeks back I wrote an article on how to generate a pre-authenticated HTML5 VM console link in vSphere 5.5 which allows a user to access the new HTML5 VM console from any operating system including Mac OS X, Windows and Linux. In the article I also provided a script to automatically generate the HTML5 VM console URL given a VM name which looks something like the following:

http://reflex.primp-industries.com:7331/console/?vmId=vm-23&vmName=VCSA&host=reflex.primp-industries.com&sessionTicket=cst-VCT-5254c455-4340-2185-e149-01ce44b146e1--tp-4A-88-17-7C-F5-D0-79-E6-9D-A1-E3-83-97-52-97-EA-E5-D3-D8-07&thumbprint=4A:88:17:7C:F5:D0:79:E6:9D:A1:E3:83:97:52:97:EA:E5:D3:D8:07

If you have tried out the new HTML5 VM console which is enabled only for a Mac OS X system using the new vSphere Web Client 5.5, you may have noticed it opens up a connection on port 7331 by default. However, this port is actually dynamic and could change if the underlying operating system hosting the vSphere Web Client is already in use. If you are running on the VCSA (vCenter Server Appliance), there is a good chance that this will be the default port but for a Windows based installation, that may or may not be the case.

If you wish to find out what the default port is, you can take a look at the vSphere Web Client log file and search for the keyword "Djetty.port". On the VCSA, the log is located in /var/log/vmware/vsphere-client/logs/vsphere_client_virgo.log and here is a screenshot of what that looks like:

To change the default port, you will need to edit the vSphere Web Client configuration property file located in /var/lib/vmware/vsphere-client/webclient.properties for the VCSA and there is an equilvent for a Windows system as well. You will need to add the following entry:

html.console.port = PORT-NUMBER

Once you are done, you will need to save your changes and restart the vSphere Web Client service. On the VCSA, to restart the vSphere Web Client you will need to run the following command:

/etc/init.d/vsphere-client restart

Now if we go back to the vSphere Web Client and open the VM console on a Mac OS X system or generate a URL using the script, you should see the HTML5 VM console is now connecting to the new port.