On 06/15/2012 10:02 AM, Luiz Capitulino wrote:
> On Thu, 14 Jun 2012 17:21:44 +0200
> Pavel Hrdina <phrd...@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<phrd...@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.
In general, I think it would be safe to say that it could supersede the
current commit command, unless others see a use case for a commit
operation that completes faster yet pauses the guest. I think being
able to rely on qemu-img to perform an offline commit would be
sufficient.
I agree on the HMP command matching the QMP command in the method used,
so that there is no confusion.
