Category Archives: Virtualization

Disk configuration for VM guests in KVM / qemu

For KVM / qemu virtualization there are 2 settings to optimize performance for the virtual disks within the VM guest:

Cache mode
IO mode

In VMM (Virtual Machine Manager) if you create a new VM guest these are both set to "default". For newer versions of KVM / qemu this default seems to be:

Cache mode: writeback
IO mode: threads

The preferred configuration for both settings depends on the kind of storage you use for guest disk images:

Disk file (e.g. qcow2-file on an ext4 partition):
Cache mode: writeback
IO mode: threads

Block device (e.g. logical volume):
Cache mode: writethrough
IO mode: native

These settings are just a rough starting point. Because there are many layers of disk io and caching involved (guest application, guest fs / kernel, host fs / kernel, raid controller, hard drive cache, etc.) every installation is different and it is therefore almost impossible to give a general rule of thumb. You need to experiment yourself to find the best combination.

Share

Randomness in KVM virtual guests

1.)
Virtual guests have viewer entropy than physical machines because of viewer hardware events.

$ cat /proc/sys/kernel/random/entropy_avail
158

2.)
Still /dev/random and /dev/urandom work as expected. /dev/random blocks more often if used within a virtual guest with tools like ssh-keygen, but produces reliable results. If you are dependent on /dev/random to work faster, try to switch to /dev/urandom, or use the hosts hardware RNG (s. virtio-rnd, http://http://wiki.qemu-project.org/Features-Done/VirtIORNG).

Despite its reputation, /dev/urandom is as reliable as /dev/random (s. http://www.2uo.de/myths-about-urandom), even with low entropy. If in doubt, test it with rngtest (found on Debian Jessie 8 in package "rng-tools").

$ cat /dev/urandom | rngtest -c 5000
...
rngtest: FIPS 140-2 successes: 4996
rngtest: FIPS 140-2 failures: 4
...

This failure rate is acceptable for regular use of KVM guests.

3.)
Be careful not to exclusively use hardware RNGs. See current discussion about the use of Intel's RDRAND in linux kernel and openssl versions.

Because of concerns about the ability to audit this new Intel processor feature introduced with the Ivy Bridge CPU architecture, support was dropped in openssl completely. Openssl version 1.0.2 adds support of RDRAND again, but only in combination with other entropy sources.

That's how the current linux kernel works as well (XOR operation of RDRAND data with other entropy sources, s. https://www.change.org/p/linus-torvalds-remove-rdrand-from-dev-random-4/responses/9066).

4.)
Software RNGs are at least debatable. The most famous one is probably haveged. See discussion here: https://lwn.net/Articles/525459 . If you want to use haveged, use it only in combination with rngd, as rngd combines it with other entropy sources.

5.)
So far there is no need to change anything about RNGs in KVM guests. The only thing to worry about is the seeding of /dev/urandom at system startup. In most modern linux distributions, /dev/urandom is seeded with random numbers at system startup. The seed is produced by a system service and stored on disk during system shutdown.

In Debian (starting from Debian 8 Jessie) this service is called "systemd-random-seed" and the disk file for the seed is "/var/lib/systemd/random-seed".

6.)
Starting with kernel 4.8, a new DRBG algorithm is used to fill /dev/urandom: ChaCha20
ChaCha20 is supposed to work better and faster than the previous DRBG SP800-90A. Yet another reason to use /dev/urandom. Debian 9 Stretch e.g. uses kernel 4.9 and therefore ChaCha20.

The flow for /dev/urandom seems to be something like this:
external entropy sources (physical)  ->  entropy pool  ->  DRBG  ->  /dev/urandom

Source: https://lwn.net/Articles/686033/

Important things to note:

Whenever you clone a KVM guest or make a snapshot, the random seed file stays the same. Thus the initial seeding of /dev/urandom does not change making its output more predictable. To avoid this problem, you might want to restart the service a couple of times before or after cloning a guest or making a snapshot.

Share