Bug 689101 - libvirt does not notice failure to change CD-ROM
Summary: libvirt does not notice failure to change CD-ROM
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-19 13:48 UTC by Stefan Hajnoczi
Modified: 2011-03-30 19:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-30 19:07:31 UTC
Embargoed:


Attachments (Terms of Use)

Description Stefan Hajnoczi 2011-03-19 13:48:30 UTC
Description of problem:

QEMU rejects changing the CD-ROM when the tray is locked (e.g. the guest has the CD-ROM mounted).  Virt-manager does not notice the error and incorrectly displays the CD-ROM as connected.

Version-Release number of selected component (if applicable):

virt-manager.git/master and virt-manager-0.8.4-8 Debian.

How reproducible:

Deterministic, just follow the steps.

Steps to Reproduce:
1. Start a VM and make sure a CD-ROM is connected.
2. Inside the guest unmount and mount the CD-ROM again to ensure the tray is locked.
3. Now disconnect and connect a new CD-ROM in virt-manager.
 
Actual results:

Virt-manager displays the new CD-ROM as connected.  Inside the guest you continue to access the old CD-ROM.

Expected results:

Virt-manager should display an error that the tray is locked.  It should not show the new CD-ROM as connected.

Comment 1 Cole Robinson 2011-03-21 15:08:48 UTC
Hmm, virt-manager seems to be catching hotplug errors correctly, so libvirt probably did not report the error.

What libvirt version is this?

You can change cdrom media using virsh, though it's a PITA. Copy the specific <disk> block you want to change into a separate file disk.xml. Edit the <source> line to point to the new media (or remove the <source> line altogether to eject). Then on for an active VM, do

virsh --connect qemu:///system attach-device $vmname disk.xml

Comment 2 Stefan Hajnoczi 2011-03-21 19:55:56 UTC
I am using libvirt 0.8.8-1 Debian.

Should I test what happens when I reproduce this using virsh instead of virt-manager?

Comment 3 Cole Robinson 2011-03-21 20:51:16 UTC
Yes, please test with virsh. If virsh claims the command succeeded, it's a libvirt or qemu issue.

Comment 4 Stefan Hajnoczi 2011-03-22 10:56:23 UTC
Virsh claims the command succeeded and the domain XML has been updated to remove the CD-ROM <source> tag.  This looks like a libvirt issue.

virsh # update-device fedora-14 /tmp/nocdrom.xml
Device updated successfully

virsh # dumpxml fedora-14
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>

virsh # qemu-monitor-command --hmp fedora-14 'info block'
drive-ide0-1-0: type=cdrom removable=1 locked=1 file=/home/stefanha/iso/test.iso ro=0 drv=raw encrypted=0

QEMU and libvirt are out of sync.

How do we move this bug over to libvirt?

Comment 5 Daniel Berrangé 2011-03-22 11:17:55 UTC
Actually you are comparing two different object's there.

  'ide0-1-0' refers to the guest device

  'drive-ide0-1-0' refers to the QEMU drive associated with the guest device.

libvirt always prepends 'drive-' to the geust device name when talking to the qemu monitor to access the drive data, so there is no sync problem here.

Comment 6 Stefan Hajnoczi 2011-03-22 14:18:03 UTC
I'm not sure we're talking about the same thing:

virsh dumpxml says that there is no <source> tag.  That means the medium is not present.

QEMU says that the open file is /home/stefanha/iso/test.iso.  But the file should not be open if the medium is not present!

So libvirt thinks there is no CD-ROM in the drive.  QEMU thinks there is a CD-ROM in the drive.

Comment 7 Cole Robinson 2011-03-22 14:37:18 UTC
I think the last piece to check is the actual monitor command response from qemu.

Please run libvirtd with

LIBVIRT_DEBUG=1 libvirtd > foo.log 2>&1

and reproduce. Then search the file for 'eject' or 'change' or whatever the monitor command is. That should hopefully narrow it down to either libvirt or qemu

Comment 8 Stefan Hajnoczi 2011-03-23 13:27:10 UTC
Here is what the libvirt log says about the response to the QEMU 'eject' command:

debug : qemuMonitorCommandWithHandler:236 : Receive command reply ret=0 errno=0 35 bytes 'Device 'drive-ide0-1-0' is locked

Does this mean it doesn't recognize the response as an error?

Comment 9 Jiri Denemark 2011-03-28 11:28:58 UTC
You are right, libvirt doesn't recognize the response as an error since it is expecting "device " and not "Device ". By looking at qemu source, it looks like "device" was changed into "Device" in 0.12.0 when QMP was introduced. We need to accept both spellings. A patch is coming soon...

Comment 10 Jiri Denemark 2011-03-30 19:07:31 UTC
Fixed by the following upstream commit which will be included in the upcoming 0.9.0 release of libvirt:

commit e586f57487f4a9f15837cd7d07e55c18187fbe9d
Author: Jiri Denemark <jdenemar>
Date:   Mon Mar 28 21:34:08 2011 +0200

    qemu: Fix media eject with qemu-0.12.*
    
    In qemu-0.12.* "device '...' is locked" message was changed to "Device
    ..." so libvirt was no longer detecting this as an error.


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