From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfYYt-0007fn-2c for qemu-devel@nongnu.org; Fri, 15 Jun 2012 11:35:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SfYYl-00037v-Sz for qemu-devel@nongnu.org; Fri, 15 Jun 2012 11:35:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SfYYl-00037O-KT for qemu-devel@nongnu.org; Fri, 15 Jun 2012 11:35:39 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5FFZbmT025893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 15 Jun 2012 11:35:37 -0400 Message-ID: <4FDB5647.90204@redhat.com> Date: Fri, 15 Jun 2012 11:35:35 -0400 From: Jeff Cody MIME-Version: 1.0 References: <806c66b2f071f03bec0b7d45a71512e394386885.1339617170.git.phrdina@redhat.com> <4FD9D67F.5080505@redhat.com> <4FD9FB83.8050208@redhat.com> <4FD9FD6A.2080702@redhat.com> <4FDA0188.4080705@redhat.com> <20120615110217.58ceff71@doriath.home> <4FDB42A2.1080404@redhat.com> <20120615114408.36d4dbe2@doriath.home> In-Reply-To: <20120615114408.36d4dbe2@doriath.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] qapi: converted commit Reply-To: jcody@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: kwolf@redhat.com, Pavel Hrdina , Eric Blake , qemu-devel@nongnu.org On 06/15/2012 10:44 AM, Luiz Capitulino wrote: > On Fri, 15 Jun 2012 10:11:46 -0400 > Jeff Cody wrote: > >> On 06/15/2012 10:02 AM, Luiz Capitulino wrote: >>> On Thu, 14 Jun 2012 17:21:44 +0200 >>> Pavel Hrdina wrote: >>> >>>> On 06/14/2012 05:04 PM, Eric Blake wrote: >>>>> On 06/14/2012 08:56 AM, Pavel Hrdina wrote: >>>>>> On 06/14/2012 02:18 PM, Eric Blake wrote: >>>>>>> On 06/14/2012 01:35 AM, Pavel Hrdina wrote: >>>>>>>> Signed-off-by: Pavel Hrdina >>>>>>>> --- >>>>>>>> +++ b/qapi-schema.json >>>>>>>> @@ -1169,6 +1169,21 @@ >>>>>>>> { 'command': 'block_resize', 'data': { 'device': 'str', 'size': >>>>>>>> 'int' }} >>>>>>>> >>>>>>>> ## >>>>>>>> +# @commit >>>>>>>> +# >>>>>>>> +# Commit changes to the disk images (if -snapshot is used) or >>>>>>>> backing files. >>>>>>>> +# >>>>>>>> +# @device: the name of the device or the "all" to commit all devices >>>>>>>> +# >>>>>>>> +# Returns: nothing on success >>>>>>>> +# If @device is not a valid block device, DeviceNotFound >>>>>>>> +# If a long-running operation is using the device, DeviceInUse >>>>>>>> +# >>>>>>>> +# Since: 1.2 >>>>>>>> +## >>>>>>>> +{ 'command': 'commit', 'data': { 'device': 'str' }} >>>>>>> Should we use this as an opportunity to make the command more powerful? >>>>>>> For example, integrating this with the 'transaction' command or a block >>>>>>> job queried by 'query-block-jobs' to track its progress would be useful. >>>>>>> Also, suppose I have A<- B<- C. Does 'commit' only do one layer (C >>>>>>> into B), or all layers (B and C into A)? That argues that we need an >>>>>>> optional parameter that says how deep to commit (committing C into B >>>>>>> only to repeat and commit B into A is more time-consuming than directly >>>>>>> committing both B and C into A to start with). When a commit is >>>>>>> complete, which file is backing the device - is it still C (which >>>>>>> continues to diverge, but now from the point of the commit) or does qemu >>>>>>> pivot things to have the device now backed by B (and C can be discarded, >>>>>>> particularly true if changes are now going into B which invalidate C). >>>>>> What i find out is that 'commit' will commit changes only from C to B >>>>>> and qemu continues with C from the new commit point. I couldn't find a >>>>>> way to commit changes and go back to backing file. This should be >>>>>> supported by parameter and also as you mention that commit all changes >>>>>> through all snapshots should be supported by another parameter. >>>>>> The 'transaction' feature would be nice to have too. >>>>> Which makes it sound like we're starting to overlap with Jeff's work on >>>>> 'block-commit'. >>>>> >>>>> If 'block-commit' proves to be better all around at doing what we want, >>>>> do we even need to keep 'commit' in QMP, or would it be okay for HMP only? >>>> If the 'block-commit' will be better I think that we could drop the >>>> 'commit' completely. And have only 'block-commit' for both QMP and HMP. >>> >>> I completely agree about the QMP part, but for HMP it's a good idea to >>> maintain the commit command. To achieve this, we can implement hmp_commit() >>> in terms of block-commit. >>> >>> Jeff, can you answer us here? Does block-commit supersedes the commit command >>> we have today? >> >> The block-commit will supercede in functionality the commit command in >> place today, but it is a live operation - as such, it will take longer >> to complete, but it won't pause the guest. > > This is very nice, is this being targeted for 1.2? Yes, I'd like to see this in 1.2, so that is my goal.