This article assumes a KVM guest that runs from raw or qcow2 devices using emulated ide access. Since some time now, full virtualisation for block devices is available, facilitating the benefit of paravirtualisation.
Benchmarked in bonnie++
, the difference looks like this, revealing a way better performance of virtio
:
IDE:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
<host> 2G 856 94 33126 7 30392 7 4727 92 739753 70 300.4 20
Latency 51096us 2473ms 972ms 5240us 1516us 382ms
Version 1.96 ------Sequential Create------ --------Random Create--------
<host> -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 35 0 +++++ +++ 46 0 34 0 +++++ +++ 44 0
Latency 338ms 808us 2136ms 341ms 155us 2016ms
Virtio:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
<host> 2G 732 91 58767 8 72183 11 4026 94 1477698 80 321.6 9
Latency 16751us 1159ms 492ms 4155us 624us 422ms
Version 1.96 ------Sequential Create------ --------Random Create--------
<host> -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 34 0 +++++ +++ 46 0 34 0 +++++ +++ 45 0
Latency 240ms 790us 1502ms 296ms 167us 1450ms
So in order to make the switch from from ide
to virtio
, the following steps need to be taken:
Run virsh edit <your_vm_name>
. From there, edit the config file and adjust all lines of
<target dev='hda' bus='ide'/>
so they look like this
<target dev='vda' bus='virtio'/>
Furthermore, remove all <address type .../>
lines so that libvirt
can regenerate them appropriately.
Inside the guest, edit /etc/fstab
and replace all occurrences of /dev/sdX
with /dev/vdX`.
That's it, now shutdown the machine and start it with an virsh start <your_vm_name>
(just a reboot inside the started VM won't work).
Dirk,
I don’t normally do this, but… thanks!
This post gave me the clue I needed to save the day.
We use Proxmox VE so no virsh, but the idea is still transferable.
Our Windows VM uses VIRTIO for disk emulation. That machine’s MBR was corrupted, and even though VIRTIO drivers loaded, the disk wasn’t seen during windows repair operations.
Switching from ‘virtio0’ to ‘sata0’ in the config enables the Windows VM to display the disk, and thus be able to start repairs and system restore. The system restore failed – as I think Windows did not like the hardware change to ‘sata0’ despite this I changed the disk back to ‘virtio0’ next reboot, and Windows was properly restored!
The lesson is to backup even new VMs! But nonetheless a fun exercise. Thanks for the post.