[libvirt] [PATCH v3 01/10] block/dirty-bitmap: add recording and busy properties
eblake at redhat.com
Mon Feb 25 15:08:48 UTC 2019
On 2/25/19 9:01 AM, Vladimir Sementsov-Ogievskiy wrote:
> 23.02.2019 3:06, John Snow wrote:
>> The current API allows us to report a single status, which we've defined as:
>> Frozen: has a successor, treated as qmp_locked, may or may not be enabled.
>> Locked: no successor, qmp_locked. may or may not be enabled.
>> Disabled: Not frozen or locked, disabled.
>> Active: Not frozen, locked, or disabled.
>> The problem is that both "Frozen" and "Locked" mean nearly the same thing,
>> and that both of them do not intuit whether they are recording guest writes
>> or not.
>> This patch deprecates that status field and introduces two orthogonal
>> properties instead to replace it.
>> Signed-off-by: John Snow <jsnow at redhat.com>
>> +++ b/qapi/block-core.json
>> @@ -458,7 +458,14 @@
>> # @granularity: granularity of the dirty bitmap in bytes (since 1.4)
>> -# @status: current status of the dirty bitmap (since 2.4)
>> +# @status: Deprecated in favor of @recording and @locked. (since 2.4)
>> +# @recording: true if the bitmap is recording new writes from the guest.
>> +# Replaces `active` and `disabled` statuses. (since 4.0)
>> +# @busy: true if the bitmap is in-use by some operation (NBD or jobs)
>> +# and cannot be modified via QMP or used by another operation.
>> +# Replaces `locked` and `frozen` statuses. (since 4.0)
> Don't we want instead an array of flags? Which will include also persistent and
No, I don't think an array of flags is worth the extra complications in
generation and parsing of the JSON.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
More information about the libvir-list