Actually it's still kind of an issue. The qemu virtio device reads only from the hosts /dev/random device (not urandom) so you can still starve the hypervisor. Also the guest -- even though is properly seeded -- can entropy starve because who knows what is installed on it. And clearly there's still confusion about using /dev/random.

I don't even think the solution is to point everything to /dev/urandom. Why maintain two? Why constantly have to explain to people the difference? The BSD developers merged both devices into /dev/urandom and I think that's the right approach.

It's configurable. You can even forward host's /dev/urandom as guest's /dev/random.

Actually it's not supported with virtio-rng. Here[0] is a proposed patch to add support.

[0] http://www.redhat.com/archives/libvir-list/2016-March/msg010...

I knew you can change the source (it accepts egd after all), but didn't know they actually prevent you from choosing urandom. This is sad :(

That VirtIORNG documentation page is really sad though, with all the warnings and quirks about the guest starving the host of entropy. The source end of that device should be fed by something like fortuna, or attach directly to urandom if available.

The way this currently looks to me, is that it all but ensures poor adoption rates.

bhyve on FreeBSD has virtio_random, and it simply hooks up to /dev/random (which on FreeBSD is nonblocking and can't starve).