Re: [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from device removal

[Ryan Harper]

* Daniel P. Berrange <address@hidden> [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 <address@hidden> [2010-11-08 06:04]:
> > > > "Michael S. Tsirkin" <address@hidden> 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
address@hidden