I've been forced to use rng-tools and / or rng-usleep to get enough randomness in some Ubuntu VMs in the past. It's maddening to see SSL slowdowns for no good reason, and to have to trace it back to a blocking call to /dev/random for 8 lousy bytes.
Anyone know what relationship that product has with oVirt ( http://www.ovirt.org ) ? I thought oVirt was kind of the upstream. So wouldn't they be adding this to oVirt as well.
Interesting fact: The original product was written in C# and ran only on Windows. It was translated into Java, largely automatically at first with manual tidy ups, so it could run on Linux or Windows servers. (Well there are some Python and other bits too)
http://lpeer.blogspot.co.uk/2010/04/switching-from-c-to-java...
http://lpeer.blogspot.co.uk/2010/05/casing-moving-target.htm...
I am working with a bunch of C# code written for windows as well trying to make it work on Linux and went the Mono way. So far it worked pretty well (as long as no Desktop GUI forms are involved).
Just curious, but why should PIDs be randomized? Using 'watch pidof pidof' on my laptop, PIDs seems not so randomized.
Now, there is a valid contention that any code doing that is broken anyway and should just be fixed, and most code is much better about this now than 15 years ago. There is another contention that randomizing pids can help so why not.
See http://marc.info/?t=94754302700001&r=1&w=1 and http://marc.info/?t=94759485200001&r=1&w=1 for old discussion.
Keep in mind, though, that just accessing /dev/urandom in the guest won't need too much input from the host.
However, having a hwrng is obviously the preferred option where there is need for a lot of entropy.
https://software.intel.com/en-us/blogs/2012/11/17/the-differ...
Edit to add: we can obviously pass on the RDRAND instruction directly to the VM, but that's less portable, because not all servers in a server farm may have that instruction available, limiting live migration capabilities.
So we can just pass on output from RDSEED into the host's /dev/random, and feed the VM /dev/random by default as described.