Bug 725673
Summary: | do not fail migration if destination does not see ejected cdrom | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Dan Kenigsberg <danken> |
Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 6.2 | CC: | abaron, cpelland, dallan, dron, dyuan, gren, mzhan, rwu, weizhan |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | libvirt-0.9.4-14.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-12-06 11:17:46 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: | 723270 | ||
Bug Blocks: |
Description
Dan Kenigsberg
2011-07-26 09:06:51 UTC
This is the same request as https://bugzilla.redhat.com/show_bug.cgi?id=575160, libvirt still has no way to known wether the medium is ejected or not in the guest, so can not decide wether to do cgroup setting on the cdrom image or not, or something others can also triger the failure. qemu have not implemented the event yet. See the qemu bugs: https://bugzilla.redhat.com/show_bug.cgi?id=723270 https://bugzilla.redhat.com/show_bug.cgi?id=575159 (In reply to comment #1) > This is the same request as https://bugzilla.redhat.com/show_bug.cgi?id=575160, Not exactly. > libvirt still has no way to known wether the medium is ejected or not in the > guest, so can not decide wether to do cgroup setting on the cdrom image or not, > or something others can also triger the failure. It could query the block device prior to migration. I wonder if there is a race, however, between starting migration and the guest ejecting the disk. > See the qemu bugs: > > https://bugzilla.redhat.com/show_bug.cgi?id=723270 I believe this would work for us. (In reply to comment #2) > (In reply to comment #1) > > This is the same request as https://bugzilla.redhat.com/show_bug.cgi?id=575160, > > Not exactly. > > > libvirt still has no way to known wether the medium is ejected or not in the > > guest, so can not decide wether to do cgroup setting on the cdrom image or not, > > or something others can also triger the failure. > > It could query the block device prior to migration. As far as I understand, qemu monitor command such as "info block" can't get if the cd is ejected or not currently, the patches is posted to upstream, but not commited yet. See 723270. > I wonder if there is a > race, however, between starting migration and the guest ejecting the disk. > Hmm, seems no one considered this before, this might be a problem if qemu just changes the output of "info block", but no event throwed back. > > See the qemu bugs: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=723270 > > I believe this would work for us. (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > This is the same request as https://bugzilla.redhat.com/show_bug.cgi?id=575160, > > > > Not exactly. > > > > > libvirt still has no way to known wether the medium is ejected or not in the > > > guest, so can not decide wether to do cgroup setting on the cdrom image or not, > > > or something others can also triger the failure. > > > > It could query the block device prior to migration. > > As far as I understand, qemu monitor command such as "info block" can't get if > the cd is ejected or not currently, the patches is posted to upstream, but not > commited yet. See 723270. > I tried to look up the cdrom disk's status after ejected it *inside* guest. The disk path is still there after ejected. (QEMU) query-block {u'return': [{u'device': u'drive-ide0-0-0', u'inserted': {u'encrypted': False, u'ro': False, u'file': u'/var/lib/libvirt/images/virtlab_test', u'drv': u'raw'}, u'locked': False, u'removable': False, u'type': u'hd'}, {u'device': u'drive-ide0-1-0', u'inserted': {u'encrypted': False, u'ro': True, u'file': u'/var/lib/libvirt/images/test.iso', u'drv': u'raw'}, u'locked': False, u'removable': True, u'type': u'cdrom'}]} Making this bug dependent on 723270 (qemu exposing this info in "info block") Hmmm, it is most important to not fail domain restore, too, if cdrom is not visible (I'd say that it even does not need to be ejected. Any removable media should be able to magically disappear after the domain was save for a month or two). (In reply to comment #6) > Hmmm, it is most important to not fail domain restore, too, if cdrom is not > visible (I'd say that it even does not need to be ejected. Any removable media > should be able to magically disappear after the domain was save for a month or > two). Agreed regarding domain restore, but I don't think we should force eject media if the guest has not ejected it; that's likely to cause great difficulties for any processes in the guest that have the media open. Patch sent upstream: https://www.redhat.com/archives/libvir-list/2011-September/msg00465.html *** Bug 739388 has been marked as a duplicate of this bug. *** Moving to POST: http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-September/msg00919.html This bug depends on qemu-kvm bug 723270, so we will verify this bug after qemu-kvm bug verified. verify pass on qemu-kvm-0.12.1.2-2.199.el6.x86_64 kernel-2.6.32-207.el6.x86_64 libvirt-0.9.4-19.el6.x86_64 Steps: 1. start a guest with ide cdrom which connects 1 local iso file on it(not in nfs dir). 2. on guest, do # eject /dev/cdrom 3. do migration # virsh migrate --live guest qemu+ssh://{target ip}/system migration succeeds with no error on target host, the guest's ide cdrom exists without iso file connected Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1513.html |