[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 0/6] dirty-bitmaps: fix QMP command permissio
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH v4 0/6] dirty-bitmaps: fix QMP command permissions |
Date: |
Wed, 17 Oct 2018 15:29:08 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 |
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
- [Qemu-devel] [PATCH v4 0/6] dirty-bitmaps: fix QMP command permissions, John Snow, 2018/10/02
- [Qemu-devel] [PATCH v4 6/6] nbd: forbid use of frozen bitmaps, John Snow, 2018/10/02
- Re: [Qemu-devel] [PATCH v4 0/6] dirty-bitmaps: fix QMP command permissions, John Snow, 2018/10/02
- Re: [Qemu-devel] [PATCH v4 0/6] dirty-bitmaps: fix QMP command permissions,
Eric Blake <=
- [Qemu-devel] [PATCH v4 4/6] block/dirty-bitmaps: prohibit enable/disable on locked/frozen bitmaps, John Snow, 2018/10/02
- [Qemu-devel] [PATCH v4 2/6] block/dirty-bitmaps: fix merge permissions, John Snow, 2018/10/02
- [Qemu-devel] [PATCH v4 3/6] block/dirty-bitmaps: allow clear on disabled bitmaps, John Snow, 2018/10/02
- [Qemu-devel] [PATCH v4 5/6] block/backup: prohibit backup from using in use bitmaps, John Snow, 2018/10/02