Eric Blake <ebl...@redhat.com> writes: > On 03/01/2013 02:08 PM, Anthony Liguori wrote: > >>>> You can pass chardevs to the egd backend. It's really not a good idea >>>> to pass a fd via rng-rangom. > > Why not? If you are running a single guest, why can't libvirt pass that > one guest an fd instead of making qemu open() the file?
Why can't QEMU just open(/dev/random)? What's the advantage of libvirt doing the open? >>> Fine, then we won't use fd passing for this device, whatever the reason >>> may be. >> >> So let's step back. There are two backends currently supported: >> rng-random and rng-egd. I don't see any point in taking an fd for >> rng-random. I don't think labeling comes into play here. >> >> But if libvirt wants to interact with virtio-rng in a more intelligent >> way (implementing a policy to distribute entropy), then rng-egd is the >> right way to do that. > > Yes, libvirt will probably use rng-egd when distributing randomness > among multiple guests. But libvirt wants to target BOTH forms of rng, > in order to let the user choose which one is best for their needs. If > rng-random is not useful to any end user, then why did qemu expose it in > the first place? And if qemu thought it was worth exposing, then > libvirt thinks it is worth targetting, and by using qemu_open instead of > raw open, then fd passing is possible. Policy (whether it makes sense > to pass an fd for a random generator, and whether /dev/random or > /dev/urandom or something else is best) may be important, but it is > orthogonal to the issue that I raised about consistency. It seems a bit silly to me for QEMU to never open a file and to reinvent a namespace (via fdsets) to serve that purpose. I understand the reason that fdsets exist (because NFS is stupid and doesn't support labeling). But we aren't doing dynamic labeling of /dev/random and I strongly suspect it's not on NFS anyway. So why are we trying to pass fds here? Regards, Anthony Liguori > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org