[Top][All Lists]

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

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

From: Pavel Hrdina
Subject: Re: [Qemu-devel] [PATCH v2] qapi: converted commit
Date: Thu, 14 Jun 2012 17:21:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

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<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?
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.


reply via email to

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