A quick look at paravirtualization support in VMware and Linux
I’ve used VMware for many years. It’s the best virtual machine technology out there IMO, so I’ve been following VMware’s take on paravirtualization with great interest. In theory paravirtualization (where the guest kernel knows that it’s running on a hypervisor, not “real” hardware) is faster than pure hardware virtualization. The industry is fairly obsessed with “native” hypervisors these days, and Xen gets a lot of the attention (along with VMware’s “ESX” and, to a far lesser degree, Sun’s Logical Domains technology). But back in 2005 it was VMware that proposed a common paravirtualization interface for the Linux kernel, VMI, that would let a single binary Linux kernel run on any vendor’s hypervisor that supported the interface. It was a great idea. VMware’s proposal didn’t go forward quite as planned with a multi-vendor supported technology called paravirt-ops being chosen as the mainline virtual machine interface instead, and VMware adopted VMI to work within the paravirt-ops framework.
Years in the making, the results of all this work are finally here! VMware Workstation 6 is shipping which includes VMware’s hypervisor, and Ubuntu backported the 2.6.21 VMI stuff for the 7.04 “Feisty Fawn” release! So… what’s it look like and is it any faster?!
In Workstation 6 you go to your VM Settings -> Options -> Advanced and select the “Enable VMware paravirtual kernel support” option. When the kernel boots, it spots the VMI interface:
[ 0.000000] VMI: Found VMware, Inc. Hypervisor OPROM, API version 3.0, ROM version 1.0 [ 2344.765922] VMI timer cycles/sec = 1800100000 ; cycles/jiffy = 7200400 ;cycles/alarm = 18001000 [ 2345.230940] Booting paravirtualized kernel on vmi [ 2348.826057] Time: vmi-timer clocksource has been installed.
I tested quite a bit software and development processes relevant to me to get a feel for performance. I won’t publish the full set of results because I don’t want it to be construed as a “benchmark”, but I will share one very simple test I did: I extracted and built Python.
| Command | VMI disabled | VMI enabled | % improvement |
| Python extraction | 0m6.655s | 0m4.225s | 57% |
| Python ./configure | 0m45.592s | 0m31.291s | 45% |
| Pyton make | 2m8.840s | 1m58.095s | 9% |
Not bad! Basically any kind of load that generates system calls benefits the most. The python compile is mostly in user space where VMware was already fairly efficient, hence the relatively low 9% improvement. Overall, these are great results. I didn’t extensively test against the native OS since I do almost all my work within a virtual machine, but I can tell you that the paravirtualized kernel was typically between 10% and 20% slower than running on the bare hardware for the handful of simple tests I ran. Subjectively, everything felt snappier in X11/Gnome. Firefox in particular.
Kernel 2.6.22 is supposed to include Xen’s paravirt-ops interface. It’s great to see competitive cooperation in this space! I’d love to see OpenSolaris run on VMware’s hypervisor too, but in the short term at least it looks like we should get native Xen support before Solaris 11 ships. It sure would be cool if OpenSolaris could also support the paravirt-ops interface. I have no idea how technically feasible that is, however. I’m pretty amazed at just how good virtualized guest performance is getting. If I had any doubts about how prevalent hypervisors will be in the future they’ve been erased now. Exciting times in the virtualization world!









1 Comment
Jump to comment form | comments rss [?] | trackback uri [?]