Bug 626305
Summary: | [vdsm] [libvirt] RFE - libvirt should allow user to ask for force eject | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Haim <hateya> | ||||
Component: | libvirt | Assignee: | Cole Robinson <crobinso> | ||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | urgent | ||||||
Version: | 6.1 | CC: | ccui, cpelland, dallan, danken, dyuan, eblake, gren, gsun, hateya, iheim, jdenemar, mgoldboi, mjenner, mkenneth, plyons, xen-maint, yeylon, yimwang, ykaul, yoyzhang | ||||
Target Milestone: | rc | Keywords: | FutureFeature, ZStream | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | libvirt-0.8.6-1.el6 | Doc Type: | Enhancement | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2011-05-19 13:20:38 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: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 602685, 626334, 658147 | ||||||
Attachments: |
|
Description
Haim
2010-08-23 07:08:03 UTC
Patch posted upstream: https://www.redhat.com/archives/libvir-list/2010-November/msg00328.html 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.
Fixed upstream in v0.8.5-61-g96d52fc commit 96d52fcf43f61a95d3aec44aaf8738a1495e447a Author: Cole Robinson <crobinso> 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 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 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. 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. 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 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. 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? 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. (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. 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. 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 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 |