Re: [Qemu-block] [PATCH v4 0/6] dirty-bitmaps: fix QMP command permissions

[Eric Blake]

On 10/2/18 6:08 PM, John Snow wrote:

> > John Snow (6):
> >    block/dirty-bitmaps: add user_locked status checker
> >    block/dirty-bitmaps: fix merge permissions
> >    block/dirty-bitmaps: allow clear on disabled bitmaps
> >    block/dirty-bitmaps: prohibit enable/disable on locked/frozen bitmaps
> >    block/backup: prohibit backup from using in use bitmaps
> >    nbd: forbid use of frozen bitmaps

> Planning on submitting tests for 3.1, but with the merge queue opened up
> again I'm pretty keen on getting some stable commit IDs for these so far.

Food for thought when writing tests:
I've just noticed with my progress on libvirt code that for 
error-recovery purposes, if we decide to make 
x-block-dirty-bitmap-disable fail on a disabled bitmap (or enable on an 
enabled map) that it would be nice to have a distinct error code; or 
even better to just be a silent no-op.  That's because when libvirt has 
the situation:

bitmap1 (disabled), bitmap2 (enabled)

and wants to delete the point in time between those two, it will call:

enable bitmap1
merge bitmap2 into bitmap1
remove bitmap2

Removing a bitmap is not part of 'transaction', and there is no pressing 
reason for it to be (other than convenience) - which means this is at 
least 2 commands (if the first two are a transaction) or 3 (if all are 
done independently).

But because it is not a transaction, libvirt can conceivably succeed at 
reenabling bitmap1 but then fail because the guest shut down before 
merging bitmap2 into 1.  When the guest is restarted, there is no real 
data loss (bitmap1 and 2 are now both active, which is a little bit less 
efficient for guest writes than having just one active), so the user can 
attempt to have libvirt retry the deletion sequence.  If asking for 
bitmap1 to be enabled fails (because it is already enabled), then 
libvirt will have to add workaround code (either to detect that the 
error iss different than other failures, or to pre-probe whether the 
bitmap is already enabled); whereas if the request is a no-op, things 
are easier from libvirt's point of view.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org