On Mon, Nov 08, 2010 at 12:39:01PM -0600, Ryan Harper wrote: > * Michael S. Tsirkin <m...@redhat.com> [2010-11-08 10:57]: > > On Mon, Nov 08, 2010 at 08:02:50AM -0600, Ryan Harper wrote: > > > * Markus Armbruster <arm...@redhat.com> [2010-11-08 06:04]: > > > > "Michael S. Tsirkin" <m...@redhat.com> writes: > > > > > > > > > On Mon, Nov 08, 2010 at 11:32:01AM +0100, Markus Armbruster wrote: > > > > Daniel, I'd like your input here: can you live with > > device diappearing from info block and parsing > > qdev tree info to figure out whether device is really gone? > > AFAICT, libvirt doesn't look at or use info block at all. > > I'd rather not have to add info block to libvirt; but currently I can't > see how else we can determine if we should call drive_unplug if we do a > device_del() and the guest removes it before we call drive_unplug(). > > What happens is that the guest removes the device and when we call > drive_unplug() it fails to find the target device (since it was deleted > by the guest). Then we fail the PCiDelDisk and libvirt keeps the device > config around even though the guest has finished removing it.
This needs drive_unplug to return an explicitly identifiable 'no such device' error code, which libvirt can catch and ignore. Making the call to drive_unplug conditional on a check to query-block/query-qdev is really a bug, because it has an designed in race condition which means you need to check for a 'no such device' error code regardless. So it is better to just blindly call drive_unplug and handle the non-fatal failure conditions every time - this ensures that codepath gets exercised more frequently too :-) Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|