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