Bug 892289
| Summary: | changing CD-ROM is not reliable with RHEL7 guests due to new udev behavior | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Sibiao Luo <sluo> |
| Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.0 | CC: | areis, armbru, chayang, cwei, dallan, dyuan, flang, gsun, hhuang, juzhang, kwolf, lsu, michen, mzhan, pbonzini, qzhang, shuang, sluo, virt-maint, weizhan |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-1.0.2-1.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-13 10:35:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This is not a bug, we are precisely emulating the guest's requests. udev is locking the tray so that the guest will receive "eject request" events. At this point, there is not much that QEMU can do for eject and change commands. When doing eject, the guest will receive an eject request. The response will be to unlock the medium and eject the tray. If you did "info block" before the second "change" command, you will see that it will report tray-open=1, which is why the second "change" command succeeds. The workaround is to do "eject" and after a short while "change". We cannot do anything about this, short of documenting it, but I'll move the bug to libvirt in case they have a bright idea. Michal, can you comment on this situation and whether there's anything that any component can do? Sure. After my IRC discussion with Paolo, it is shown libvirt can actually help here a little. I've proposed patches upstream: https://www.redhat.com/archives/libvir-list/2013-January/msg01845.html They basically implement Paolo's approach with "eject", wait for a while (libvirt in fact polls for tray to open, with my patches), after which "change" is issued. Okay, patch pushed upstream:
commit 84c59ffaecc983083e2e885fa59c4f0ec1812656
Author: Michal Privoznik <mprivozn>
AuthorDate: Thu Jan 24 15:14:14 2013 +0100
Commit: Michal Privoznik <mprivozn>
CommitDate: Sun Jan 27 08:47:48 2013 +0100
qemu_hotplug: Rework media changing process
https://bugzilla.redhat.com/show_bug.cgi?id=892289
It seems like with new udev within guest OS, the tray is locked,
so we need to:
- 'eject'
- wait for tray to open
- 'change'
Moreover, even when doing bare 'eject', we should check for
'tray_open' as guest may have locked the tray. However, the
waiting phase shouldn't be unbounded, so I've chosen 10 retries
maximum, each per 500ms. This should give enough time for guest
to eject a media and open the tray.
Hence, moving to POST.
Test with: libvirt-1.0.2-1.el7.x86_64
1, start guest with a empty tray
<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' target='0' unit='0'/>
</disk>
2,
virsh # update-device aaa cdrom1.xml
Device updated successfully
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/iso1.iso'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<alias name='ide0-1-0'/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
3,
virsh # update-device aaa cdrom2.xml ---> it will wait for 5 seconds
error: Failed to update device from cdrom2.xml
error: operation failed: Unable to eject media before changing it
and tray is open:
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/iso1.iso'/>
<target dev='hdc' bus='ide' tray='open'/>
<readonly/>
<alias name='ide0-1-0'/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
virsh # update-device aaa cdrom2.xml
Device updated successfully
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/iso2.iso'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<alias name='ide0-1-0'/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
4,
in guest, open the tray
# eject /dev/cdrom
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/iso2.iso'/>
<target dev='hdc' bus='ide' tray='open'/>
<readonly/>
<alias name='ide0-1-0'/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
virsh # update-device aaa cdrom1.xml
Device updated successfully
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/iso2.iso'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<alias name='ide0-1-0'/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
5,
virsh # update-device aaa cdromnone.xml ---> it will wait for 5 seconds
error: Failed to update device from cdromnone.xml
error: internal error unable to execute QEMU command 'eject': Device 'drive-ide0-1-0' is locked
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/iso2.iso'/>
<target dev='hdc' bus='ide' tray='open'/>
<readonly/>
<alias name='ide0-1-0'/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
virsh # update-device aaa cdromnone.xml
Device updated successfully
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<target dev='hdc' bus='ide' tray='open'/>
<readonly/>
<alias name='ide0-1-0'/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
And for all steps, cdrom works well in guest.
IMO error msg in step 5 should like in step 3, what do you think?
Correct a typo: Step4: virsh # update-device aaa cdrom1.xml should be: virsh # update-device aaa cdrom2.xml I don't think it should be the same. The difference is, while in step 3 you want to change the ISO, in step 5 you want to just do bare 'eject'. Or if they should be the same, then they should be as in step 5 (the origin of the error is qemu). In step 3 we are just overwriting the qemu error with our own. (In reply to comment #8) > I don't think it should be the same. The difference is, while in step 3 you > want to change the ISO, in step 5 you want to just do bare 'eject'. Or if > they should be the same, then they should be as in step 5 (the origin of the > error is qemu). In step 3 we are just overwriting the qemu error with our > own. Thanks for your help. And one more question: when the cdrom image is mounted in guest, i can update-device successfully without umount it. Is this expect? virsh # update-device aaa cdrom2.xml error: Failed to update device from cdrom2.xml error: operation failed: Unable to eject media before changing it virsh # update-device aaa cdrom2.xml Device updated successfully in guest: before update-device: #ls /mnt aaa after update-device: #ls /mnt aaa bbb That's guest responsibility to lock tray if cdrom is mounted. Some OS allows to eject the tray even if cdrom is mounted so it is not a bug. The update-device command simulates pressing the tray-eject button, removing the old medium and, possibly, inserting a new one, and pressing the buttong again to close the tray. In my experience - I am able to eject mountedd medium as well, however, whenever I try to access the medium again, I am flooded with I/O errors. Moreover, there's nothing that libvirt/qemu can do - mounting a medium is completely in control of the guest OS and is not visible from outside. Having said that, libvirt doesn't know if the medium user wants to change is mounted or not. I guess the guest agent could be extended to provide a list of mounted medias. But that's really just a workaround. Again, it's guest kernel resposibility to lock the tray. (In reply to comment #10) > That's guest responsibility to lock tray if cdrom is mounted. Some OS allows > to eject the tray even if cdrom is mounted so it is not a bug. The > update-device command simulates pressing the tray-eject button, removing the > old medium and, possibly, inserting a new one, and pressing the buttong > again to close the tray. In my experience - I am able to eject mountedd > medium as well, however, whenever I try to access the medium again, I am > flooded with I/O errors. Moreover, there's nothing that libvirt/qemu can do > - mounting a medium is completely in control of the guest OS and is not > visible from outside. Having said that, libvirt doesn't know if the medium > user wants to change is mounted or not. > > I guess the guest agent could be extended to provide a list of mounted > medias. But that's really just a workaround. Again, it's guest kernel > resposibility to lock the tray. Thanks for your information! So i think this bug is verified. This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. |
Description of problem: boot rhel7 guest on rhel7 host with CD-ROM using ide/scsi-cd, the locked=1, and fail to do 'change/eject', but if do the second time 'change/eject', it can make effect. btw, the cd-rom did not mount in the guest. Version-Release number of selected component (if applicable): host info: # uname -r && rpm -q qemu-kvm 3.6.0-0.29.el7.x86_64 qemu-kvm-1.2.0-21.el7.x86_64 guest info: # uname -r 3.6.0-0.29.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.boot guest with CD-ROM using ide/scsi-cd. e.g:...-drive file=/home/my-cdrom1.iso,if=none,media=cdrom,format=raw,id=drive-cdrom -device ide-drive,bus=ide.0,drive=drive-cdrom,id=cdrom 2.check the block info: (qemu) info block {"execute": "query-block"} 3.do change/eject. (qemu) change drive-cdrom /home/my-cdrom2.iso {"execute":"change","arguments":{"device":"drive-cdrom","target":"/home/my-cdrom2.iso"}} 4.do ange/eject again. Actual results: after step 2, (qemu) info block drive-virtio-disk: removable=0 io-status=ok file=/home/RHEL-7-Server-x86_64.qcow2 ro=0 drv=qcow2 encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0 drive-data-disk: removable=0 io-status=ok file=/home/my-data-disk.qcow2 ro=0 drv=qcow2 encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0 drive-cdrom: removable=1 locked=1 tray-open=0 io-status=ok file=/home/my-cdrom1.iso ro=1 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0 <------------the locked value should be 0 floppy0: removable=1 locked=0 tray-open=0 [not inserted] sd0: removable=1 locked=0 tray-open=0 [not inserted] after 3, it fail to change the cd-rom. (qemu) change drive-cdrom /home/my-cdrom2.iso Device 'drive-cdrom' is locked after 4, if can make effect at the second time, but the locked value also will be 1. (qemu) change drive-cdrom /home/my-cdrom2.iso (qemu) info block drive-virtio-disk: removable=0 io-status=ok file=/home/RHEL-7-Server-x86_64.qcow2 ro=0 drv=qcow2 encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0 drive-data-disk: removable=0 io-status=ok file=/home/my-data-disk.qcow2 ro=0 drv=qcow2 encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0 drive-cdrom: removable=1 locked=1 tray-open=0 io-status=ok file=/home/my-cdrom2.iso ro=1 drv=raw encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0 floppy0: removable=1 locked=0 tray-open=0 [not inserted] sd0: removable=1 locked=0 tray-open=0 [not inserted] Expected results: the locked value should be 0 when boot up guest with CD-ROM using ide/scsi-cd in rhel7, and could do change/eject successfully. Additional info: