[Switch] KVM virtio paravirtualized drivers: Why they matter

Http://www.ilsistemista.net/index.php/virtualization/42-kvm-virtio-paravirtualized-drivers-why-they-matter.html? Limitstart = 0

As you probably already know, there are basically two different schools in the specified aliztion CHAMP:

• The para-specific alization one, where a modified Guest OS uses specific host-side syscall (hypercall) to do its "dirty work" with physical devices
• The Full Hardware virtualization alization one (hvm), where the guest OS run unmodified and the host system "traps" when the guest try to access a physical device

The two approach are vastly different: the former requires extensive kernel modifications on both guest and host OSes but give you maximum performance, as both kernels are virtualization-aware and so they are optimized for the typical workload they experience. the latter approach is totally transparent to the guest OS and often do not require each kernel-level changes to the host side but, as the guest OS is not fully alization aware, it generally has lower performance.

So it appear that you had to do a conscious choice between performance and Guest OS compatibility: The paravirtualized approach prioritize performance, while the hvm one prioritize compatibility. however, in this case it is possible to have the best of both worlds: By using para-receivalized guest Device Driver in an otherwise hvm environment, you can have compatibility and performance.

In short, a paravirtualizad device driver is a limited, targeted form of paravirtualization, useful when running specific guest OSes for which paravirtualization drivers are available. while being largely transparent to the guest OS (you simply need to install a driver), they relieve the specified alizer from emulating a real physical device (which is a complex operation, as it must emulate register, port, memory, ECC), substituting the emulation with some host-side syscall. the KVM-based framework to write paravirtualized drivers is called virtio.

Things are much more complex than this, of course. anyway, in this article I am not going to explain in detail how a paravirtualized driver works, but to measure the performance implication of using it. being a targeted paravirtualization form requiring guest-specific drivers, it is obvious that virtio is restricted to areas where it matter most, so disk and network subsystems are prime candidates for those upload drivers. let see if, and how, both Linux (centos 6 x86-64) and Windows (win2012r2 x64) are affected from that paravirtualized goodness.Testbed and Methods

All test run on a Dell d620 laptop. The complete system specifications are:

• Core2 t7200 CPU @ 2.0 GHz
• 4 GB of DDR2-667 Ram
• Quadro nvs110 videocard (used in text-only mode)
• A Seagate st980825as 7200 RPM 80 gb sata hard disk drive (in IDE compatibility mode, as the d620's BIOS does not support ahci Operation)
• Centos 6.5 host-side OS with kernel version 2.6.32-431.1.2.0.1.el6.x86 _ 64
• A 512 MB ramdisk driver used for disk speed measurements

On the guest side, we have:

• A first centos 6.5 guest (kernel version 2.6.32-431.1.2.0.1.el6.x86 _ 64)
• A second windows 2012 R2 x64 Virtual Machine

The virtio paravirtualized drivers are already encoded in the standard Linux kernel, so for the centos guest no special action or installation was needed. on the Windows Guest, I installed the virtio disk and network drivers from the virtio-0.1-74.iso package.

For quick disk benchmark, I used DD on the Linux side and Atto on the windows one. to pose additional strain on guest disk subsystem and the host was alizer, I run all disk tests against a ramdisk drive: in this manner I was sure that eventual differences were not masked out by the slow mechanical disk. networking speed was measured with the same tool on both VMS: iperf, version 2.0.5.

Host CPU load was measured using mpstat.

OK, let see the numbers...Centos 6 x86-64 guest

The first graph shows centos 6 guest disk speed with and without the paravirtualized DRIVER:

Native performances are supported for reference only. We can see that para-receivalized Disk Driver provide a good speedup versus the standard receivalized ide controller. Anyway, both approaches are far behind the native scores.

Net speed now:

In this case the paravirtualized Network Driver makes an huge difference: while it can't touch native speed, it is way ahead of the virtualized e1000 Nic adapter. the rtl8139 was benchmarked for Pure curiosity, and it show a strange behavior: While output speed is in line with Nic speed (100 Mb/s), input speed is much higher (~ 400 Mb/s). Strange, but true.

While host CPU load is lower on the full receivalized tables, it is only because they deliver much lower performance. in other word, the MB/s per CPU load ratio is much higher on the Para already alized network driver.

Windows 2012 R2 x64 guest

Let see if windows guest has some surprise for us. Disk benchmark first:

This time, the fully receivalized ide driver is much behind the para-receivalized driver. In other word: always install the paravirtualized driver when dealing with Windows guests.

Network, please:

The paravirtualized driver continues to be much better then the fully receivalized tables.

Conclusions

It is obvious that the paravirtualized drivers are an important piece of the KVM ecosystem. while the fully inclualized drivers are quite efficient and the only way to support a large variety of guest OSes, you should really use a paravirtualized driver if available for your guest virtual machine.

Obviusly performance are only part of the equation, stability being even more important. Anyway I found the current virtio drivers release very stable, at least with the tested guests.

In short: When possible, use the virtio paravirtualized drivers!