[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
'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?
--
Eric Blake address@hidden +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [PATCH] qapi: converted commit, Pavel Hrdina, 2012/06/14
- Re: [Qemu-devel] [PATCH v2] qapi: converted commit, Eric Blake, 2012/06/14
- Re: [Qemu-devel] [PATCH v2] qapi: converted commit, Pavel Hrdina, 2012/06/14
- Re: [Qemu-devel] [PATCH v2] qapi: converted commit,
Eric Blake <=
- Re: [Qemu-devel] [PATCH v2] qapi: converted commit, Pavel Hrdina, 2012/06/14
- Re: [Qemu-devel] [PATCH v2] qapi: converted commit, Luiz Capitulino, 2012/06/15
- Re: [Qemu-devel] [PATCH v2] qapi: converted commit, Jeff Cody, 2012/06/15
- Re: [Qemu-devel] [PATCH v2] qapi: converted commit, Luiz Capitulino, 2012/06/15
- Re: [Qemu-devel] [PATCH v2] qapi: converted commit, Jeff Cody, 2012/06/15
Re: [Qemu-devel] [PATCH v2] qapi: converted commit, Luiz Capitulino, 2012/06/15