[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2] qapi: converted commit
Date: Thu, 14 Jun 2012 09:04:10 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

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<address@hidden>
>>> ---
>>> +++ 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

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?

Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]