On Fri, Jan 25, 2013 at 01:20:43PM +0100, Michal Privoznik wrote: > 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 shortly > - 'change' > > However, the 'wait shortly' step is better to be substituted with > active polling on tray_open attribute on the device. Moreover, > even when doing bare 'eject', we should check for 'tray_open' as > guest may have locked the tray. QEMU emits an event when the tray state changes, so we should just be listening for that. In the case where we have an old QEMU lacking the tray state event, then we're also missing the tray state in the block info query, so no worse off. So just skip the polling and wait for the event to arrive. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list