* Daniel P. Berrange <berra...@redhat.com> [2010-11-08 11:05]: > On Mon, Nov 08, 2010 at 06:56:02PM +0200, Michael S. Tsirkin wrote: > > 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: > > > > >> Here's how the various objects are connected to each other: > > > > >> > > > > >> contains > > > > >> drivelist -----------> DriveInfo > > > > >> | > > > > >> | .bdrv > > > > >> | .id == .bdrv->device_name > > > > >> | > > > > >> contains V > > > > >> bdrv_states -----------> BlockDriverState > > > > >> | ^ > > > > >> .peer | | > > > > >> | | host part > > > > >> -----------------------------|---|----------------------------------- > > > > >> | | guest part > > > > >> | | property "drive" > > > > >> v | > > > > >> DeviceState > > > > >> > > > > >> To disconnect host from guest part, you need to cut both pointers. > > > > >> To > > > > >> delete the host part, you need to delete both objects, > > > > >> BlockDriverState > > > > >> and DriveInfo. > > > > > > > > > > > > > > > If we remove DriveInfo, how can management later detect that guest > > > > > part > > > > > was deleted? > > > > > > > > Directly: check whether the qdev is gone. > > > > > > > > I don't know how to check that indirectly, via DriveInfo. > > > > > > > > > If you want symmetry with netdev, it's possible to keep a > > > > > shell of BlockDriverState/DriveInfo around (solving dangling pointer > > > > > problems). > > > > > > > > netdev_del deletes the host network part: > > > > > > > > (qemu) info network > > > > Devices not on any VLAN: > > > > net.0: net=10.0.2.0, restricted=n peer=nic.0 > > > > nic.0: model=virtio-net-pci,macaddr=52:54:00:12:34:56 peer=net.0 > > > > (qemu) netdev_del net.0 > > > > (qemu) info network > > > > Devices not on any VLAN: > > > > nic.0: model=virtio-net-pci,macaddr=52:54:00:12:34:56 peer=net.0 > > > > > > > > It leaves around the VLAN object. Since qdev property points to that, > > > > it doesn't dangle. > > > > > > > > In my opinion, drive_del should make the drive vanish from "info block", > > > > > > Yeah; that's the right thing to do here. Let me respin the patch with > > > the name change and the additional work to fix up the pointers and > > > ensure that we don't see the drive in info block. > > > > 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? > > We don't use info block for anything. Having to parse the full qdev tree > to determine if a single device is gone seems rather tedious. It would > be better if query-qdev took an optional argument, which is the name > of the device to root the tree at. Then checking whether a device > named 'foo' is gone just means running 'query-qdev foo' and seeing if > that returns an error about the device not existing, then we know it > has gone. No need to parse anything. Being able to query the qdev data > for a single device, or sub-tree of devices seems useful in its own > right.
Since I'm not looking forward to parsing info block (easy) nor parsing all of qdev tree (much harder) I really like the query approach. That makes it easy to put a query in the netdev_del/drive_del commands to skip invoking them if the guest has already responded. > > 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 :| -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com
