From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42736 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PFWeU-0002KG-E6 for qemu-devel@nongnu.org; Mon, 08 Nov 2010 13:41:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PFWeS-0005PG-N2 for qemu-devel@nongnu.org; Mon, 08 Nov 2010 13:41:10 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:50736) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PFWeS-0005PB-JG for qemu-devel@nongnu.org; Mon, 08 Nov 2010 13:41:08 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oA8IJog8030111 for ; Mon, 8 Nov 2010 13:19:50 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oA8If7EF2224250 for ; Mon, 8 Nov 2010 13:41:07 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oA8If7wm011896 for ; Mon, 8 Nov 2010 13:41:07 -0500 Date: Mon, 8 Nov 2010 12:41:04 -0600 From: Ryan Harper Subject: Re: [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from device removal Message-ID: <20101108184104.GC22381@us.ibm.com> References: <20101105162218.GM22381@us.ibm.com> <20101108021926.GV22381@us.ibm.com> <20101108104906.GA855@redhat.com> <20101108140250.GW22381@us.ibm.com> <20101108165602.GF7962@redhat.com> <20101108170437.GB26714@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101108170437.GB26714@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Markus Armbruster , Anthony Liguori , Ryan Harper , Stefan Hajnoczi , yamahata@valinux.co.jp * Daniel P. Berrange [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 [2010-11-08 06:04]: > > > > "Michael S. Tsirkin" 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 ryanh@us.ibm.com