Bug 644706 - QEMU monitor hangs on first command when attempting start a guest with an encrypted qcow2 image
QEMU monitor hangs on first command when attempting start a guest with an enc...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm (Show other bugs)
5.6
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: Markus Armbruster
Virtualization Bugs
: Triaged
: 644705 (view as bug list)
Depends On:
Blocks: Rhel5KvmTier2
  Show dependency treegraph
 
Reported: 2010-10-19 22:00 EDT by wangyimiao
Modified: 2013-01-09 18:15 EST (History)
12 users (show)

See Also:
Fixed In Version: kvm-83-226.el5
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-21 04:50:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description wangyimiao 2010-10-19 22:00:58 EDT
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.
Comment 1 Jiri Denemark 2010-10-20 06:21:25 EDT
*** Bug 644705 has been marked as a duplicate of this bug. ***
Comment 2 Jiri Denemark 2010-10-21 10:12:32 EDT
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
Comment 4 Daniel Berrange 2010-10-29 08:59:45 EDT
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@siemens.com>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Comment 6 RHEL Product and Program Management 2011-01-11 15:52:05 EST
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.
Comment 7 RHEL Product and Program Management 2011-01-11 17:54:10 EST
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.
Comment 9 Shirley Zhou 2011-01-27 03:30:24 EST
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
Comment 14 Min Deng 2011-05-11 22:19:45 EDT
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
Comment 16 Tomas Capek 2011-07-19 05:02:10 EDT
    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.
Comment 17 errata-xmlrpc 2011-07-21 04:50:37 EDT
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
Comment 18 errata-xmlrpc 2011-07-21 07:48:58 EDT
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

Note You need to log in before you can comment on or make changes to this bug.