Description of problem: "virsh start demo" will be hang with an encrypted qcow2 img Version-Release number of selected component (if applicable): libvirt-0.8.2-7.el5 kvm-qemu-img-83-205.el5 kvm-83-205.el5 kernel-2.6.18-227.el5 How reproducible: 5/5 Steps to Reproduce: 1. Define a secret with an XML document. # cat demo-secret.xml <secret ephemeral='no' private='no'> <uuid>0a81f5b2-8403-7b23-c8d6-21ccc2f80d6f</uuid> <usage type='volume'> <volume>/var/lib/libvirt/images/demo.qcow2</volume> </usage> </secret> # virsh secret-define demo-secret.xml Secret 0a81f5b2-8403-7b23-c8d6-21ccc2f80d6f created 2. Set the value of the secret. # MYSECRET=`echo "open seseme" | base64` # virsh secret-set-value 0a81f5b2-8403-7b23-c8d6-21ccc2f80d6f $MYSECRET Secret value set 3. Define and active a pool with the following XML. # cat demo-pool.xml <pool type='dir'> <name>VirtualMachines</name> <source> </source> <target> <path>/var/lib/libvirt/images</path> </target> </pool> # virsh pool-define demo-pool.xml Pool VirtualMachines defined from demo-pool.xml # virsh pool-start VirtualMachines Pool VirtualMachines started 4. To create an encrypted volume within this pool with the follwing XML. # cat demo-disk.xml <volume> <name>demo.qcow2</name> <capacity>5368709120</capacity> <target> <format type='qcow2'/> <encryption format='qcow'> <secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccc2f80d6f'/> </encryption> </target> </volume> # virsh vol-create VirtualMachines demo-disk.xml Vol demo.qcow2 created from demo-disk.xml 5. With the following XML config which associates the qcow decryption ‘passphrase’ with the secret we defined to define a new RHEL5.5 guest, and then start it. # wget http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL5.5-Server-20100322.0/tree-x86_64/images/pxeboot/initrd.img # wget http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL5.5-Server-20100322.0/tree-x86_64/images/pxeboot/vmlinuz # cp initrd.img vmlinuz /var/lib/libvirt/boot/ # cat demo-guest.xml <domain type='kvm'> <name>demo</name> <memory>524288</memory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='pc'>hvm</type> <kernel>/var/lib/libvirt/boot/vmlinuz</kernel> <initrd>/var/lib/libvirt/boot/initrd.img</initrd> <boot dev='hd'/> </os> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/demo.qcow2'/> <target dev='hda' bus='ide'/> <encryption format='qcow'> <secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccc2f80d6f'/> </encryption> </disk> <interface type='network'> <mac address='52:54:00:53:a6:f0'/> <source network='default'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target port='0'/> </console> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes'/> </devices> </domain> # virsh define demo-guest.xml Domain demo defined from demo-guest.xml # virsh start demo Actual results: "virsh start demo" will be hang and guest can not be start successfully. Expected results: Command will be done succeddfully and guest will be start successfully.
*** Bug 644705 has been marked as a duplicate of this bug. ***
qemu-kvm is stuck in "info cpus". Can be reproduced with qemu-kvm alone, I tried issuing several info commands in qemu monitor and they worked. After sending info cpus command, qemu-kvm hangs. The qemu-kvm command I used: LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -S -M rhel5.4.0 -m 256 -smp 1 -name console -uuid d405cd1e-1f9d-db45-d33d-8a7b44fa02cb -monitor unix:/var/lib/libvirt/qemu/console.monitor,server,nowait -boot c -drive file=/var/lib/libvirt/images/kvm-console.img,if=ide,bus=0,unit=0,boot=on,format=raw -drive file=/var/lib/libvirt/images/encrypted.qcow2,if=ide,bus=0,unit=1,format=qcow2 -serial pty -parallel none -usb -vnc 127.0.0.1:0 -k en-us -vga std -balloon virtio
At a guess we're missing at least this changeset commit bb5fc20f7c1c65e95030da3629dd0d7a0cce38cd Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162> Date: Thu Mar 5 23:01:15 2009 +0000 monitor: Rework modal password input (Jan Kiszka) Currently, waiting for the user to type in some password blocks the whole VM because monitor_readline starts its own I/O loop. And this loop also screws up reading passwords from virtual console. Patch below fixes the shortcomings by using normal I/O processing also for waiting on a password. To keep to modal property for the monitor terminal, the command handler is temporarily replaced by a password handler and a callback infrastructure is established to process the result before switching back to command mode. Signed-off-by: Jan Kiszka <jan.kiszka> Signed-off-by: Anthony Liguori <aliguori.com>
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release.
Reproduce steps: 1. create qcow2 file with encrypted qemu-img create -f qcow2 -e /home/bug.img 20G 2. start this created image -drive file=/home/bug.img,if=ide,bus=0,unit=1,format=qcow2 -monitor stdio 3.query cpus info (qemu) info cpus after step3, monitor become hang
I can reproduce the bug via kvm-qemu-img-83-205.el5 kvm-83-205.el5 Cannot reproduce it via kvm-qemu-img-83-232.el5 kvm-83-232.el5 Steps to reproduce, 1.qemu-img create -f qcow2 -e /home/bugold.qcow2 20G 2./usr/libexec/qemu-kvm -rtc-td-hack -usbdevice tablet -no-hpet -drive file=/home/bugold.qcow2,if=virtio,boot=on,werror=stop,cache=none,format=qcow2,media=disk -smp 2 -m 2G -net nic,macaddr=00:12:24:58:a1:2f,model=virtio,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0 -uuid d203f8fe-eb02-4918-90d2-058bcf86e95b -boot dc -balloon virtio -notify all -monitor stdio -vnc :3 3.in monitor (qemu) info cpus
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, the QEMU monitor used an incorrect handler to process passwords to encrypted images. Consequently, the monitor became unresponsive on the first command when attempting to start a guest with an encrypted qcow2 (QEMU Copy-on-Write) image. With this update, the command handler and the password handler are used properly, and the guest now starts successfully in the described scenario.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1068.html