Virtual guests have viewer entropy than physical machines because of viewer hardware events.
$ cat /proc/sys/kernel/random/entropy_avail 158
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.
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).
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.
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".
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
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.