A few questions:

1. About what "event" are you referring to? There has never been a proper event for that, I believe vdsm used to check it manually when it had access to the monitor, so what's stopping it from doing the same check by using libvirt's API?

2. What qemu-kvm version did you use? Can you please check whether the real problem here is bug 558256 ?

(In reply to comment #3)
> A few questions:
> 
> 1. About what "event" are you referring to? There has never been a proper event
> for that, I believe vdsm used to check it manually when it had access to the
> monitor, so what's stopping it from doing the same check by using libvirt's
> API?

this should be answered by the vdsm team. adding Danken
> 
> 2. What qemu-kvm version did you use? Can you please check whether the real
> problem here is bug 558256 ?

I tested both on qemu-kvm-0.12.1.2-2.153.el6.x86_64 and on the latest: 

qemu-kvm-0.12.1.2-2.160.el6.x86_64

the bug 558256 is a much earlier version: qemu-kvm-0.12.1.2-2.9.el6.x86_64

also, it's not the same issue. the problem here is that ejecting cd in guest is not comunicated to vdsm - hence the guest sees that there is no cd while vdsm and rhevm will still have a link to the image.

Thanks for the testing.

Please, note that the ejecting of the cdrom in the guest has never been communicated by the user monitor. If that exists in rhel5, then it's a RHEL-only patch I'm not aware of.

blocker flag was automatically added by mistake. removing it.

Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.