Bug 626305 - [vdsm] [libvirt] RFE - libvirt should allow user to ask for force eject
[vdsm] [libvirt] RFE - libvirt should allow user to ask for force eject
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.1
All Linux
urgent Severity high
: rc
: ---
Assigned To: Cole Robinson
Virtualization Bugs
: FutureFeature, ZStream
Depends On:
Blocks: 602685 626334 658147
  Show dependency treegraph
 
Reported: 2010-08-23 03:08 EDT by Haim
Modified: 2015-02-25 11:34 EST (History)
20 users (show)

See Also:
Fixed In Version: libvirt-0.8.6-1.el6
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-19 09:20:38 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)
Add flag to force eject a CDROM (7.77 KB, text/plain)
2010-11-10 13:01 EST, Cole Robinson
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0596 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-05-18 13:56:36 EDT

  None (edit)
Description Haim 2010-08-23 03:08:03 EDT
Description of problem:

libvirt should allow the user to ask for force eject, otherwise, in case 'cd' is already mounted by the file system, user is prompted for error when trying to eject: 

libvirtError: internal error unable to execute QEMU command 'eject':
Device 'drive-ide0-1-0' is locked

we need this option in vdsm to allow admin to forcely change cd from RHEVM, this is how we worked before libvirt (rhel5.5). 
I suggest to add such a flag to virDomainUpdateDeviceFlags

this is high priority for RHEV deployment. 

repro steps + flow: 

1) run change disk command and chose new iso

10:35:46.006: debug : qemuMonitorJSONCommandWithFd:217 : Send command '{"execute":"change","arguments":{"device":"drive-ide0-1-0","target":"/rhev/data-center/6
acd4aff-334a-44e1-8370-048f1ba9962b/f8c32b6b-d9da-41f7-bf48-0810e307c564/images/11111111-1111-1111-1111-111111111111/IT_WINXP_PRO_VL_ISO.iso","arg":"raw"}}' fo
r write with FD -1

2) mount that iso via linux guest 

3) run change cd and chose new iso: 

0:36:50.689: error : qemuMonitorJSONCheckError:316 : internal error unable to execute QEMU command 'change': Device 'drive-ide0-1-0' is locked
Comment 6 Cole Robinson 2010-11-08 13:08:06 EST
Patch posted upstream:

https://www.redhat.com/archives/libvir-list/2010-November/msg00328.html
Comment 7 Cole Robinson 2010-11-10 13:01:14 EST
Created attachment 459504 [details]
Add flag to force eject a CDROM

This can be invoked via virDomainUpdateDeviceFlags with the new flag VIR_DOMAIN_DEVICE_MODIFY_FORCE.
Comment 8 Jiri Denemark 2010-11-26 07:48:45 EST
Fixed upstream in v0.8.5-61-g96d52fc

commit 96d52fcf43f61a95d3aec44aaf8738a1495e447a
Author: Cole Robinson <crobinso@redhat.com>
Date:   Mon Nov 8 12:52:48 2010 -0500

    qemu: Add flag to force a CDROM eject
    
    QEMU allows forcing a CDROM eject even if the guest has locked the device.
    Expose this via a new UpdateDevice flag, VIR_DOMAIN_DEVICE_MODIFY_FORCE.
    
    This has been requested for RHEV:
    
    https://bugzilla.redhat.com/show_bug.cgi?id=626305
    
    v2: Change flag name, bool cleanups
Comment 11 Dan Kenigsberg 2010-12-21 11:31:06 EST
The new flag name is not the same in RHEL 6.0.z and RHEL 6.1. I do not care which version gives in, but the difference is too ugly to keep.

# rpm -q libvirt ; pydoc libvirt |grep FORCE
libvirt-0.8.1-28.el6.x86_64         VIR_DOMAIN_DEVICE_EJECT_FORCE = 4
libvirt-0.8.1-27.el6_0.2.x86_64     VIR_DOMAIN_DEVICE_MODIFY_FORCE = 4
Comment 12 Eric Blake 2010-12-21 11:47:06 EST
6.0.z is correct (the backport ended up requiring two patches rather than one, to match a botch in how the proposed patch was applied upstream).  libvirt-0.8.1-28.el6 is NOT the RHEL 6.1 target; it was built merely as a stopgap measure to be able to move the bug into MODIFIED in order to create the z-stream bug in the first place.  The RHEL 6.1 build will automatically pick up the correct name of DEVICE_MODIFY_FORCE as part of a proper rebasing to 0.8.6 or newer.
Comment 13 Dan Kenigsberg 2010-12-21 12:13:00 EST
Lovely. I'll fix vdsm to use to correct API. I'd appreciate if the not-to-be-published series of libvirt-0.8.1-28 onward is either removed from brew or fixed, so as not to mislead others.
Comment 18 wangyimiao 2010-12-27 23:22:24 EST
Follow the comment 17,that just fixed a part. 
From bug description and steps it need to change a new ISO file.
From the result shows issue still exists.

Test it on build  :
libvirt-0.8.6-1.el6.x86_64
libvirt-client-0.8.6-1.el6.x86_64
qemu-kvm-0.12.1.2-2.128.el6.x86_64
qemu-img-0.12.1.2-2.128.el6.x86_64
kernel-2.6.32-93.el6.x86_64

Test steps:
1.Create ISO file.
# mkisofs -o  /var/lib/libvirt/images/test.iso  /tmp
# mkisofs -o  /var/lib/libvirt/images/test1.iso  /tmp

2.Add that XML in the domain config XML.
..............................   
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/test.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>
................................   

3.Define and start the domain
# virsh define test.xml 
Domain http_test defined from test.xml

# virsh start http_test
Domain http_test started

4.Log in the guest domain.
# mount /dev/scd0 /mnt

5.# python
Python 2.6.5 (r265:79063, Jul 14 2010, 11:36:05) 
[GCC 4.4.4 20100630 (Red Hat 4.4.4-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import libvirt
>>> cd="""  <disk type='file' device='cdrom'>
...       <driver name='qemu' type='raw'/>
...       <source file='/var/lib/libvirt/images/test1.iso'/>
...       <target dev='hdc' bus='ide'/>
... </disk>"""
>>> c = libvirt.open('qemu:///system')
>>> d = c.lookupByName('http_test')
>>> d.updateDeviceFlags(cd,libvirt.VIR_DOMAIN_DEVICE_MODIFY_FORCE)
libvir: QEMU error : internal error unable to execute QEMU command 'change': Device 'drive-ide0-1-0' is locked
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 765, in updateDeviceFlags
    if ret == -1: raise libvirtError ('virDomainUpdateDeviceFlags() failed', dom=self)
libvirt.libvirtError: internal error unable to execute QEMU command 'change': Device 'drive-ide0-1-0' is locked

>>> empty="""<disk device='cdrom'>
... <target dev='hdc' bus='ide'/>
... <alias name='ide0-1-0'/>
... </disk>
... """
>>> c = libvirt.open('qemu:///system')
>>> d = c.lookupByName('http_test')
>>> d.updateDeviceFlags(empty,libvirt.VIR_DOMAIN_DEVICE_MODIFY_FORCE)
0
Comment 19 Jiri Denemark 2011-01-10 05:53:02 EST
The patch for this which went into libvirt-0.8.6-1.el6.x86_64 was not the right version (unlike the one which went into z-stream package). Could you retest with libvirt-0.8.7-1.el6?

BTW, libvirt-0.8.7 also includes support for --force flag to virsh update-device command, so you are not forced to use python any more.
Comment 20 Wayne Sun 2011-01-11 00:13:20 EST
Packages:
# rpm -qa |grep libvirt
libvirt-client-0.8.7-1.el6.x86_64
libvirt-0.8.7-1.el6.x86_64
libvirt-python-0.8.7-1.el6.x86_64

Steps to Reproduce:
1.Add that XML in the domain config XML.
..............................   
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/test.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>
................................   

2.Create ISO file.
# mkisofs -o  /var/lib/libvirt/images/test.iso  /tmp

3.Define and start the domain
# virsh define test.xml 
Domain http_test defined from test.xml

# virsh start http_test
Domain http_test started

4.Log in the guest domain.
# mount /dev/scd0 /mnt
mount: block device /dev/sr0 is write-protected, mounting read-only


5.create eject XML
# cat eject.xml 
 <disk type='block' device='cdrom'>
      <target dev='hdc' bus='ide'/>
    </disk>

6.Force eject cdrom 
# virsh update-device http_test eject.xml --force
Device updated successfully

7.Check guest xml
# virsh dumpxml http_test
...
    <disk type='block' 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>
...

Update success. 

But when check in the guest, the content still mount under /mnt. And when try to change cd under virt-manager with new iso file, window pops out says it will take effect after guest reboot, but after reboot the guest will back to original which because live update take off effect after guest reboot.
Also try to update device after eject, using 
# cat cdrom.xml
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/temp2.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>

# virsh update-device http_test cdrom.xml
error: Failed to update device from cdrom.xml
error: internal error unable to execute QEMU command 'change': Device 'drive-ide0-1-0' is locked

So, update-device can force eject the cdrom. But i'm afraid after eject, can't attach new iso file. And i don't think this is expected. 
So should i file a new bug again this?
Comment 21 Jiri Denemark 2011-01-13 09:26:46 EST
This is actually expected. When cdrom is mounted in the guest and you force eject its image, you could probably still see the content of it in the guest because of dentry cache. However, you shouldn't be able to actually read from the cdrom. If you unmount the cdrom in the guest, you shouldn't be able to mount it back.

BTW, does adding --force to the last update-device command succeed? I haven't tested it and I don't even know if qemu supports that, but you can try. Anyway, even if it succeeds, I can image the guest can be pretty confused without unmounting the cdrom and mounting it back.
Comment 22 Wayne Sun 2011-01-13 22:33:12 EST
(In reply to comment #21)
> This is actually expected. When cdrom is mounted in the guest and you force
> eject its image, you could probably still see the content of it in the guest
> because of dentry cache. However, you shouldn't be able to actually read from
> the cdrom. If you unmount the cdrom in the guest, you shouldn't be able to
> mount it back.
> 
^^^ Yep, after unmount the cdrom in the guest, it can't be mounted back.

> BTW, does adding --force to the last update-device command succeed? I haven't
> tested it and I don't even know if qemu supports that, but you can try. Anyway,
> even if it succeeds, I can image the guest can be pretty confused without
> unmounting the cdrom and mounting it back.

^^^ update-device command succeed with --force option. I first umount the cdrom in the guest then run  
# virsh update-device http_test eject.xml --force
Device updated successfully

But the problem is still can't change the cd content. After eject cdrom after step 7 in comment #20, the cdrom is empty now. Try to update it with new iso file by run:

Step 8:
# cat cdrom.xml
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/temp2.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>

# virsh update-device http_test cdrom.xml --force
error: Failed to update device from cdrom.xml
error: internal error unable to execute QEMU command 'change': Device
'drive-ide0-1-0' is locked

So, i think this bug is not fixed yet.
Comment 23 Jiri Denemark 2011-01-14 02:38:15 EST
If there is a bug, then it's a separate bug since this bz is asking for force eject and this apparently works now. So moving this BZ back to MODIFIED.

Did you unmount the cdrom in your guest between step 7 and 8? It doesn't really make much sense to try to stick another image in while the guest still thinks the old one is there.
Comment 25 Cui Chun 2011-02-10 01:22:23 EST
Rechecked it on the following test environment according to comment 20,21,22,23. "force eject" is fixed. so this bug is passed.

bug 676528 has been raised.

Test environment:
libvirt-0.8.7-5.el6
qemu-kvm-0.12.1.2-2.144.el6
kernel-2.6.32-94.el6
Comment 28 errata-xmlrpc 2011-05-19 09:20:38 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-0596.html

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