From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpJKR-0004Ei-Dn for qemu-devel@nongnu.org; Wed, 19 Jun 2013 10:25:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpJKO-00053y-E4 for qemu-devel@nongnu.org; Wed, 19 Jun 2013 10:25:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19875) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpJKN-00053r-W1 for qemu-devel@nongnu.org; Wed, 19 Jun 2013 10:25:40 -0400 Date: Wed, 19 Jun 2013 16:24:58 +0200 From: Stefan Hajnoczi Message-ID: <20130619142458.GA4586@stefanha-thinkpad.muc.redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51C17192.6050405@linux.vnet.ibm.com> Content-Transfer-Encoding: quoted-printable 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: Wenchao Xia 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 On Wed, Jun 19, 2013 at 04:53:38PM +0800, Wenchao Xia wrote: > =E4=BA=8E 2013-6-19 15:46, Stefan Hajnoczi =E5=86=99=E9=81=93: > >On Wed, Jun 19, 2013 at 02:18:48PM +0800, Wenchao Xia wrote: > >>=E4=BA=8E 2013-6-18 22:20, Stefan Hajnoczi =E5=86=99=E9=81=93: > >>>On Mon, Jun 17, 2013 at 11:25:26AM +0800, Wenchao Xia wrote: > >>>>=E4=BA=8E 2013-6-15 17:55, Eric Blake =E5=86=99=E9=81=93: > >>>>>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 bo= th > >>>>>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 o= ne has > >>>>>problems? > >>>> > >>>> I think adding it in transaction is not very useful but brings m= ore > >>>>complexity. Transcation is used to guareentee all operations are ta= ken > >>>>in one time point, for example, snapshot creation use it to make su= re > >>>>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? >=20 > It seems not much difference with following methods: >=20 > 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