Red Hat Bugzilla – Bug 1128095
chardev 'chr0' isn't initialized when we try to open rng backend
Last modified: 2015-05-24 20:08:08 EDT
Description of problem: Failed to start guest after adding RNG hardware: RNG Type: Entropy Gathering Daemon, Backend type: UDP, Host: 127.0.0.1 port 1708, Bind Host: 127.0.0.1 port 1710. Version-Release number of selected component (if applicable): kernel-3.10.0-143.el7.x86_64 libvirt-1.2.7-1.el7.x86_64 qemu-kvm-rhev-2.1.0-1.el7.x86_64 How reproducible: always Steps to Reproduce: 1. Prepare a health guest and keep in shutdown status. 2. Add the rng device like below: with Type: Entropy Gathering Daemon, Backend type: UDP, Host: 127.0.0.1 port 1708, Bind Host: 127.0.0.1 port 1710. # virsh dumpxml rhel77 | grep rng -A 10 <rng model='virtio'> <backend model='egd' type='udp'> <source mode='bind' host='127.0.0.1' service='1710'/> <source mode='connect' host='127.0.0.1' service='1708'/> </backend> 3. Start the guest. Actual results: Failed to start guest. # virsh start rhel77 error: Failed to start domain rhel77 error: internal error: process exited while connecting to monitor: 2014-08-08T07:29:39.116348Z qemu-kvm: -object rng-egd,chardev=charrng0,id=rng0: Device 'charrng0' not found Expected results: Guest can start successfully. Additional info: This issue doesn't hit with following version. 1. Download to qemu-kvm-rhev-1.5.3-60.el7ev.x86_64, guest can start successfully. 2 Remove qemu-kvm-rhev-2.1.0-1.el7.x86_64 and then install qemu-kvm-1.5.3-66.el7.x86_64 instead, guest can start successfully.
What's the full qemu command line? Why the bind and connect port is different?
Please also upload your full xml file as attachment.
A simple way to reproduce this bug: x86_64-softmmu/qemu-system-x86_64 -monitor stdio -vnc :0 \ -chardev socket,host=localhost,port=1024,id=chr0 \ -object rng-egd,chardev=chr0,id=rng0 qemu-system-x86_64: -object rng-egd,chardev=chr0,id=rng0: Device 'chr0' not found It's an upstream regression which was introduced by the following patch, it's not fixed: | commit 57d3e1b3f52d07d215ed96df946ee01f8d9f9526 | Author: Igor Mammedov <imammedo@redhat.com> | Date: Thu Jan 16 17:34:39 2014 +0100 | | virtio_rng: replace custom backend API with UserCreatable.complete() callback | | in addition fix default backend leak by releasing it if its | initialization failed. | | Signed-off-by: Igor Mammedov <imammedo@redhat.com> | Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> | Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Fix included in qemu-kvm-1.5.3-70.el7
(In reply to Miroslav Rezanina from comment #6) > Fix included in qemu-kvm-1.5.3-70.el7 The Component is qemu-kvm-rhev, we only need it for qemu-kvm-rhev. it doesn't need for qemu-kvm-rhel7, but it's harmless. Did I mark something wrong in bug/patch?
Hi Amos, you did nothing wrong. Looks like build -70.el7 was corrupted due other incorrectly submitted patches that cause inclusion of few rhev only patches to rhel build. Changing back to POST and putting patch back on queue...rhel build will be fixed with other incorrectly committed patches.
Reproduced this bug on qemu-kvm-rhev-2.1.0-4.el7.x86_64. Host: qemu-img-rhev-2.1.0-4.el7.x86_64 qemu-kvm-rhev-debuginfo-2.1.0-4.el7.x86_64 qemu-kvm-common-rhev-2.1.0-4.el7.x86_64 qemu-kvm-tools-rhev-2.1.0-4.el7.x86_64 qemu-kvm-rhev-2.1.0-4.el7.x86_64 Steps: # /usr/libexec/qemu-kvm -monitor stdio -vnc :0 -chardev socket,host=10.66.11.16,port=1024,id=chr0 -object rng-egd,chardev=chr0,id=rng0 qemu-kvm: -object rng-egd,chardev=chr0,id=rng0: Device 'chr0' not found Verified this bug on qemu-kvm-rhev-2.1.2-3.el7.x86_64. Host: qemu-kvm-common-rhev-2.1.2-3.el7.x86_64 qemu-kvm-rhev-debuginfo-2.1.2-3.el7.x86_64 qemu-img-rhev-2.1.2-3.el7.x86_64 qemu-kvm-tools-rhev-2.1.2-3.el7.x86_64 qemu-kvm-rhev-2.1.2-3.el7.x86_64 # /usr/libexec/qemu-kvm -monitor stdio -vnc :0 -chardev socket,host=10.66.11.16,port=1024,id=chr0 -object rng-egd,chardev=chr0,id=rng0 QEMU 2.1.2 monitor - type 'help' for more information (qemu)
Base on comment#10 set this bug verified, any problem please let me know. Thanks, Mazhang.
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. https://rhn.redhat.com/errata/RHSA-2015-0624.html