qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-block] [PATCH v2 01/17] docs: incremental backup


From: John Snow
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 01/17] docs: incremental backup documentation
Date: Wed, 11 Mar 2015 10:19:21 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0



On 03/11/2015 09:43 AM, Stefan Hajnoczi wrote:
On Mon, Mar 02, 2015 at 06:19:47PM -0500, John Snow wrote:
+## Bitmap Modes
+
+* A Bitmap can be "enabled" (tracking writes, the default) or "disabled"
+(read-only, I/O is ignored.) This state is currently only changed internally
+for the purposes of migration, and otherwise remains enabled.

 From a QMP API perspective this information is not relevant.  The
documentation is clearer without the concept of enabled/disabled.


Hm ... I suppose; If you want all mention of this gone from user view, I should actually remove this status field from the query, too. It is entirely possible to have a state where the bitmap is not frozen, but it is disabled (migration, perhaps others in the future?) so I left the status visible to the user for now.

libvirt et al could likely rely on the migration status to know not to manipulate bitmaps, but having that status information directly in the bitmap didn't bother me.

+## Errors
+
+* In the event of an error that occurs after a backup job is successfully
+  launched, either by a direct QMP command or a QMP transaction, the user
+  will receive a BLOCK_JOB_COMPLETE event with a failure message.

I would add BLOCK_JOB_CANCELLED just in case.  When aborting a QMP
transaction it's likely that the job will be cancelled and the user will
not get a BLOCK_JOB_COMPLETE event.


I can elaborate, sure.



reply via email to

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