Latest QEMU proposal just requires libvirt to be able to configure a character device, and optionally emit an event to client apps when entropy is desired

http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg03329.html

Anthony's new proposal upstream has two options:

    qemu -chardev socket,host=localhost,port=1024,id=chr0 \
         -object rng-egd,chardev=chr0,id=egd0 \
         -device virtio-rng-pci,rng=egd0

and

    qemu -object rng-urandom,id=rng0 -device virtio-rng-pci,rng=rng0

The first one uses a chardev and we feed in entropy using the egd protocol.

The second one will open /dev/urandom and feed in entropy to the guest.

If this proposal is accepted and merged, we'll have to have an alternative implementation for RHEL6, as we don't have QOM.  This alternative implementation will just end up looking like the proposal linked from comment #6.

In this case, what is preferable to the libvirt team: having a QEVENT emitted each time guest asks for entropy, or to not have the QEVENT?  Keep in mind that there's no QEVENT in the proposal mentioned above by Anthony.

For libvirt POV we would like QEMU to operate as closely as possible to the upstream QEMU.  Even though we don't have QOM in RHEL6, can't we do a little forward compat patch to just parse the two "-object" args you describe in comment #7 and setup RNG manually without using QOM.  If upstream won't have a QEVENT, then we don't want one in RHEL either.

(In reply to comment #9)
> For libvirt POV we would like QEMU to operate as closely as possible to the
> upstream QEMU.  Even though we don't have QOM in RHEL6, can't we do a little
> forward compat patch to just parse the two "-object" args you describe in
> comment #7 and setup RNG manually without using QOM.

I'm not sure about that -- we could get into compat problems, if upstream changes -object behaviour before it lands in RHEL7 or a released upstream version.

>  If upstream won't have
> a QEVENT, then we don't want one in RHEL either.

Agreed on ths.

I believe this is the patchset from Anthony that's mentioned in comment 7:

http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg04236.html

Patches for qemu have been merged upstream.  See qemu.git commits

16c915ba42b45df7a64a6908287f03bfa3764bed
904d6f588063fb5ad2b61998acdf1e73fb465067

Peter, this is done upstream, right?

Yes, the basic support was committed to upstream libvirt and is included in the 1.0.3 release.

The core of the functionality was added by commits:

commit 820019fcdff27264bc5ae8fd01095840d3456aa6
Author: Peter Krempa <pkrempa>
Date:   Wed Feb 13 11:22:23 2013 +0100

    qemu: Implement support for EGD backend for virtio-rng
    
    This patch adds a new capability bit QEMU_CAPS_OBJECT_RNG_EGD and code
    to support the egd backend for the VirtIO RNG device.
    
    The device is added by 3 qemu command line options:
    -chardev socket,id=charrng0,host=1.2.3.4,port=1234 (communication
                                                        backend)
    -object rng-egd,chardev=charrng0,id=rng0 (RNG protocol client)
    -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x4 (the RNG device)

commit 234a55604eed46b1d4dd55a4d20b66e12a485bc6
Author: Peter Krempa <pkrempa>
Date:   Fri Jan 11 17:48:21 2013 +0100

    qemu: Implement support for default 'random' backend for virtio-rng
    
    This patch implements support for the virtio-rng-pci device and the
    rng-random backend in qemu.
    
    Two capabilities bits are added to track support for those:
    
    QEMU_CAPS_DEVICE_VIRTIO_RNG - for the device support and
    QEMU_CAPS_OBJECT_RNG_RANDOM - for the backend support.
    
    qemu is invoked with these additional parameters if the device is
    enabled:
    
    -object rng-random,id=rng0,filename=/test/phile (to add the backend)
    -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x4 (to add the device)

commit e2a0dfcfe99c96daa6e53c968a7630e6ae776dc1
Author: Peter Krempa <pkrempa>
Date:   Fri Jan 11 17:34:37 2013 +0100

    conf: Add support for RNG device configuration in XML
    
    This patch adds basic configuration support for the RNG device
    supporting the virtio model with the "random" and "egd" backend types as
    described in the schema in the previous patch.

commit fa16c80f52136371dcc88649052fd9f7adff73eb
Author: Peter Krempa <pkrempa>
Date:   Thu Dec 20 12:06:52 2012 +0100

    doc: schema: Add basic documentation for the virtual RNG device support
    
    This patch documents XML elements used for (basic) support of virtual
    RNG devices.
    
    In the devices section in the domain XML users may specify:
    
    For the default 'random' backend:
      <devices>
        <rng model='virtio'>
          <backend model='random'>/dev/urandom</backend>
        </rng>
      </devices>
    
    For the slightly more advanced EGD backend:
      <devices>
        <rng model='virtio'>
          <backend model='egd' type='udp'>
            <!-- this is a definition of a character device -->
            <source mode='bind' service='1234'/>
            <source mode='connect' host='1.2.3.4' service='1234'/>
            <!-- or other valid character device configuration -->
          </backend>
        </rng>
      </devices>
    
    For the planned random daemon/pool:
      <devices>
        <rng model='virtio'>
          <backend model='pool' pool='poolname'>class</backend>
        </rng>
      </devices>
    
    to enable the RNG device for guests.

There are a few related commits fixing some minor bugs in the implementation that are already pushed upstream.

In case the fair entropy distribution infrastructure is requested for RHEL6 too please clone https://bugzilla.redhat.com/show_bug.cgi?id=916194 that is tracking  the addition for RHEL7.

If the interface to qemu will differ from the virtio-RNG implementation in upstream qemu we will need to add a RHEL-only hack to bridge the differences as I doubt that libvirt upstream would accept such hacks.

The backport of the libvirt functionality should be straightforward as the code is already upstream. We're just waiting for the qemu backport to happen to have a testing environment if the backport was successful.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1374.html