Bug 689101

Summary:	libvirt does not notice failure to change CD-ROM
Product:	[Community] Virtualization Tools	Reporter:	Stefan Hajnoczi <stefanha>
Component:	libvirt	Assignee:	Daniel Veillard <veillard>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	berrange, crobinso, jdenemar, xen-maint
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-03-30 19:07:31 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.