The Good and the Bad of the new Native Driver Architecture in ESXi 5.5


I recently became aware of that with vSphere 5.5 VMware introduced a new Native Driver Architecture for ESXi. William Lam has written an excellent blog post describing the motivation behind and the benefits of this new architecture. I will shortly summarize it here, but also add some concerns about the way it is introduced, because - in the future - it might severely limit the ability to run ESXi on white box and commodity hardware.

The Good ...

As some of you may know the current driver architecture of ESXi uses Linux kernel drivers that are plugged into the VMkernel with the help of a shim layer (called vmklinux) that translates the function calls of the VMkernel driver interface into calls that are compatible with the Linux specific interface of the driver. This basically means that you can use already existing Linux device drivers with ESXi - you just need to slightly adapt the original source code to work with the vmklinux layer and re-compile it.

However, this architecture has drawbacks: It introduces
  • growing complexity because of the needed compatibility to the Linux kernel (which quickly evolves itself and is a matter of constant change)
  • sub-optimal performance because of the translation layer overhead
  • boundaries of driver functionality because it limits an ESXi driver to what the corresponding Linux device driver can provide
  • a dependency on the stability and reliability that is provided by the Linux driver (although these tend to be quite solid)
In the new architecture the translation layer is removed and the Linux device driver is replaced by a new native ESXi driver that directly implements the VMkernel interface. This instantly eliminates all the drawbacks listed above.

So this is definitely a good move and I welcome it!

... and the Bad ...

The ability to use Linux device drivers in ESXi also had one huge benefit: Like the Linux kernel itself the vast majority of Linux device drivers are Open Source and available under the terms of the GNU General Public License (GPL). This forced VMware to license the corresponding ESXi drivers also under the GPL and make their source code publicly available.

Now there is a small but excellent community of developers that make use of this published Open Source Code to build ESXi device drivers for devices that are not supported by VMware out-of-the-box. These drivers enable users to install ESXi on so-called white box hardware: commodity PCs and servers that are not on the VMware HCL - the Hardware Compatibility List of officially supported systems and devices.

Can they do the same for the new native driver model? No, they can not, because
  • VMware won't make the new drivers available under the GPL and publish their source code, and
  • the Native Driver Development Kit (NDDK) that you need to develop drivers on your own is currently only available to members of the VMware Technology Alliance Partner (TAP) program, a program that is usually limited to companies producing commercial hardware or software solutions for VMware products like ESXi. 
In ESXi 5.5 the legacy vmklinux driver architecture is still included for backwards compatibility and this will probably also apply to at least the next version of ESXi, but - some day - ESXi will be limited to native drivers that can be developed only by VMware and its hardware partners. And I do not expect these to include drivers for commodity hardware. Remember: The Realtek NIC drivers have already been removed from ESXi 5.5!

... and how to make it better

I really hope that VMware will change its mind here. They do not need to make native drivers available as Open Source and under the GPL, but they should definitely provide free public access to the NDDK! This would be utilized by only a small community of skilled developers, but the huge community of commodity hardware users would benefit from their work!


This post first appeared on the VMware Front Experience Blog and was written by Andreas Peetz. Follow him on Twitter to keep up to date with what he posts.



3 comments:

  1. I agree with free public access to the DDK. I recently developed a network driver using the open source code and access to the DDK would be helpful (all trying to see if ACPI drivers are supported as no open source ACPI drivers are available for ESXi). The port from Linux was easy as worked flawlessly. Having to develop a native driver in the future would really suck as maintaining a Windows and Linux driver is already work enough.

    But..gotta do what you gotta do I guess. Hopefully more questions will be answered one we get our hands on the DDK. Please consider making it freely available VMware!

    ReplyDelete
  2. The sad reality is that VMware has plenty of mind-share because commodity hardware allows countless up and coming professionals to run home-labs. If this goes away then VMware will essentially push us towards Xen or, more likely, Hyper-V. I hope that day doesn't come but VMware's moves in recent memory don't include as much goodwill to those of us who champion their products through free licensing options.

    ReplyDelete
  3. Excellent info..Thanks Mr.Andreas Peetz

    ReplyDelete

***** All comments will be moderated! *****
- Please post only comments or questions that are related to this post's contents!
- Advertising and link spamming will not be tolerated!