From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpUlN-00067T-0F for qemu-devel@nongnu.org; Wed, 19 Jun 2013 22:38:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpUlL-0006dE-Hk for qemu-devel@nongnu.org; Wed, 19 Jun 2013 22:38:16 -0400 Received: from e28smtp09.in.ibm.com ([122.248.162.9]:43134) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpUlL-0006c7-0a for qemu-devel@nongnu.org; Wed, 19 Jun 2013 22:38:15 -0400 Received: from /spool/local by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 20 Jun 2013 08:03:40 +0530 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id 84418E0053 for ; Thu, 20 Jun 2013 08:07:36 +0530 (IST) Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5K2cHKF23265442 for ; Thu, 20 Jun 2013 08:08:17 +0530 Received: from d28av02.in.ibm.com (loopback [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5K2c9T3004493 for ; Thu, 20 Jun 2013 12:38:09 +1000 Message-ID: <51C26AF5.5000404@linux.vnet.ibm.com> Date: Thu, 20 Jun 2013 10:37:41 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1371209999-15579-1-git-send-email-xiawenc@linux.vnet.ibm.com> <1371209999-15579-10-git-send-email-xiawenc@linux.vnet.ibm.com> <51BC3A10.6040001@redhat.com> <51BE81A6.1090202@linux.vnet.ibm.com> <20130618142037.GO7649@stefanha-thinkpad.redhat.com> <51C14D48.7040907@linux.vnet.ibm.com> <20130619074608.GC23822@stefanha-thinkpad.muc.redhat.com> <51C17192.6050405@linux.vnet.ibm.com> <20130619142458.GA4586@stefanha-thinkpad.muc.redhat.com> In-Reply-To: <20130619142458.GA4586@stefanha-thinkpad.muc.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH V2 09/12] qmp: add interface blockdev-snapshot-delete-internal-sync List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, phrdina@redhat.com, famz@redhat.com, Stefan Hajnoczi , armbru@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com, lcapitulino@redhat.com, dietmar@proxmox.com 于 2013-6-19 22:24, Stefan Hajnoczi 写道: > On Wed, Jun 19, 2013 at 04:53:38PM +0800, Wenchao Xia wrote: >> 于 2013-6-19 15:46, Stefan Hajnoczi 写道: >>> On Wed, Jun 19, 2013 at 02:18:48PM +0800, Wenchao Xia wrote: >>>> 于 2013-6-18 22:20, Stefan Hajnoczi 写道: >>>>> On Mon, Jun 17, 2013 at 11:25:26AM +0800, Wenchao Xia wrote: >>>>>> 于 2013-6-15 17:55, Eric Blake 写道: >>>>>>> Should this command be made available via 'transaction'? That is, if I >>>>>>> have a two-disk VM, and use 'transaction' to take a snapshot of both >>>>>>> disks at once, shouldn't I also have a way to delete the snapshots of >>>>>>> both at once, or gracefully fail without data loss if the second one has >>>>>>> problems? >>>>>> >>>>>> I think adding it in transaction is not very useful but brings more >>>>>> complexity. Transcation is used to guareentee all operations are taken >>>>>> in one time point, for example, snapshot creation use it to make sure >>>>>> all are consistent to VM. But for deletion, this requirement do not >>>>>> exist. >>>>> >>>>> I guess the problem is: can we make internal snapshot deletion >>>>> transactional? It's hard to do rollback for snapshot deletion. >>>>> >>>> Several deletion in transaction equals to several calls of >>>> 'blockdev-snapshot-delete-internal-sync', unlike creation, so I hope >>>> not add it which have rollback issue. >>>> >>>> >>>>> But batching is definitely useful for doing 'delvm' in QMP. I just >>>>> don't think transactions help. We just need a 'delvm' equivalent in >>>>> QMP. >>>>> >>>> Maybe the caller can encapsulate a batch interface at its level. >>> >>> 'delvm' is a batch interface - it deletes internal snapshots that have >>> the same name across multiple devices. >>> >>> It's not as flexible as: >>> blkdev-internal-snapshot-delete drive0 drive2 drive4 >>> >>> Because that would allow you to specify specific drives. >>> >> Do you mean this interface should be changed as >> blkdev-internal-snapshot-delete devices_array name *id? >> >> It seems not much difference with following methods: >> >> for device in device_list: >> blkdev-internal-snapshot-delete device name > > The ability to batch in a single QMP command feels a little nicer. > There are less opportunities for the operation to stop half-way through. > > It would be usable as a QMP 'delvm' and in a more flexible way to delete > multiple internal snapshots. > > Would be interesting to see what Eric Blake thinks from a libvirt > perspective. > > Stefan > Just want to mention: other interfaces for block device take single device as parameter now, use array here would be a little strange, and increase the complexity in qmp and hmp interface. My opinion is let caller do: for device in device_list: blkdev-internal-snapshot-delete device name Still, hope to know Eric's opinion. -- Best Regards Wenchao Xia