GPL Hyper-V Paravirtualized Drivers and Industry Next Steps

Yesterday Microsoft announced what I believe was a brilliant move – Hyper-V paravirtualized drivers (Microsoft calls them Integration Components) released under GPL 2.0. This announcement reflects Microsoft’s long term Linux strategy, in my opinion, and is the first step toward positioning Hyper-V as a platform for hosting Linux workloads. Getting Hyper-V paravirtualized device drivers in the mainline Linux kernel will simplify deployment of Linux-based VMs on the Hyper-V platform in coming years. In the short term, it’s important for Microsoft’s key partners (Novell and Red Hat) to backport the paravirtualilzed drivers so that their currently shipping Linux distros will run more efficiently on Hyper-V. Given Microsoft’s close partnerships with Novell and Red Hat, I see SUSE Linux Enterprise Server 10/11 and Red Hat Enterprise Linux 5 support as foregone conclusions.

With this move, I think that Microsoft has acknowledged that Linux is here to stay, and has provided additional momentum to the growing number of Linux-based VM appliances. A growth in Linux-based VM appliances benefits everyone, including the Linux community and VMware (who hosts the Virtual Appliance Marketplace). Microsoft still has more work to do on this Linux front. Open sourcing Hyper-V paravirtualized drivers was a great first step. Next up, I would like to see Microsoft support Linux VMs with multiple virtual CPUs on Hyper-V. This opens the door for Microsoft to tout Hyper-V as a platform for production-class Linux workloads.

To take this a step further, let’s turn back the clock to October 2008. At Catalyst Europe, I asked Steve Herrod and Ian Pratt about VMware and Citrix collaborating on an exchange of device driver libraries to further reduce VM compatibility issues between hypervisors, and both agreed to continue the conversation (more details here). Citrix XenServer and Microsoft Hyper-V share device driver libraries and include the driver libraries for each platform as part of their paravirtualized driver installation (i.e., XenServer Tools and Hyper-V Integration Components). With Microsoft releasing Hyper-V paravirtualized Linux drivers, I think it’s a good time to revisit the idea of an open source driver framework that supports the core paravirtualized driver libraries of each major hypervisor platform (ESX, Xen, Hyper-V, and KVM). Sure, we’ll need a community/standards body (or whatever you want to call it) to manage driver library updates, but I can’t see why it isn’t possible. Such collaboration would make life easier for everyone. Imagine being able to run a few tests on one of your VMs “in the cloud,” and not having to care what the hypervisor is. Isn’t that what cloud’s supposed to be about anyway? Here’s my service level and security requirements. Can you give me the service I need?

Yes I understand that my cloud analogy is overly simplistic and there will always be some benefits to having a consistent virtual infrastructure both internally and with external providers. Still there are times when such consistency isn’t needed, and that’s why shared driver libraries make a lot of sense (besides removing another barrier to vendor lock-in). VM configuration metadata is addressed with Open Virtualization Format (OVF). From a technology perspective, nothing is preventing collaboration on a common VM device driver framework and shared driver libraries (that is something I’d love to see in the mainline Linux kernel). And finally, hypervisor vendor support for both .vmdk and .vhd virtual hard disk formats is the last major hurdle blocking VM compatibility (without the necessary conversions) between hypervisors. Vendors – let’s not talk about cloud openness, open architectures, etc. Let’s do something about it. Microsoft made a great move yesterday. Next I’d like to see collaboration between all virtualization vendors that further promotes choice among users, IT departments, and service providers. VMware, Microsoft, Citrix, Novell, Red Hat, Oracle – what do you say?

http://www.chriswolf.com/?p=394