Re: [Qemu-devel] [PATCH v2] qapi: converted commit

[Luiz Capitulino <lcapitulino@redhat.com>]

On Fri, 15 Jun 2012 10:11:46 -0400
Jeff Cody <jcody@redhat.com> wrote:

> On 06/15/2012 10:02 AM, Luiz Capitulino wrote:
> > On Thu, 14 Jun 2012 17:21:44 +0200
> > Pavel Hrdina <phrdina@redhat.com> 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<phrdina@redhat.com>
> >>>>>> ---
> >>>>>> +++ 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?