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: Eric Blake
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 01/17] docs: incremental backup documentation
Date: Wed, 11 Mar 2015 08:43:03 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 03/11/2015 08:19 AM, John Snow wrote:
> 
> 
> 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.

With a back-compat perspective, it's easier to hide the field now and
add it later if we discover that it would have been useful to expose,
than it is to expose it now and then have to support it forever even
though no one uses it.  I'm not yet sure if libvirt can make use of
knowing whether a bitmap is frozen/disabled.

-- 
Eric Blake   eblake redhat com    +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]