Re: [libvirt] Offline manipulation of Dirty Bitmaps by qemu-img
On Thu, Dec 05, 2019 at 17:37:11 -0500, John Snow wrote:
This has come up in the past, and I believe we discussed this at KVM
Forum, too:
There have been requests from oVirt (via Nir Soffer) to add some offline
bitmap manipulation functionality. In the past, our stance has generally
been "Use QEMU without an accelerator, and use QMP to manipulate the
images."
This is a thing I wanted to do for a long time but never had time for.
I'm not sure whether that will change though.
We have a workaround for this tough: you can start the VM with CPUs
stopped:
virsh start --pause $VMNAME
(That translates to VIR_DOMAIN_START_PAUSED flag for
virDomainCreateWithFlags).
You can then use any libvirt API which requires a running VM including
blockjobs checkpoints etc.
The VM then can be destroyed. Since the CPUs didn't run the guest
visible image content was nott modified.
Alternatively to make this slightly more official we could introduce a
new flag for the VM starting API which will actually start the VM in the
no-machine mode, will interlock certain operations such as resuming of
the execution or migration perhaps and the official purpose will be to
allow complex blockjobs without starting the actual VM.
Since starting an actual VM will be impossible anyways until such a VM
is gone it might be a sane thing to do here.
We like this for a few reasons:
1. It keeps bitmap management code tightly centralized
2. It allows for the full suite of bitmap manipulations in either
offline or online mode with one tool
3. We wouldn't have to write new code.
4. Or design new CLIs and duplicate our existing work.
5. Or write even more tests.
In libvirt we'd like to use it because qemu-img has no reasonable
progress reporting and we could reuse the code we have for interacting
with the jobs when the VM is running.
However, tools like oVirt may or may not be fully equipped to launch
QEMU in this context, and there is always a desire for qemu-img to be
able to "do more", so existing management suites could extend
functionality more easily.
(Or so I am imagining.)
I am still leaning heavily against adding any more CLI commands or
options to qemu-img right now. Even if we do add some of the fundamental
ones like "add" or "remove", it seems only a matter of time before
we
have to add "clear", "merge", etc. Is this just a race to code
duplication?
On the other hand, one of the other suggestions is to have qemu-img
check --repair optionally delete corrupted bitmaps. I kind of like this
idea: it's a buyer beware operation that might make management layers
unhappy, but then again ... repair is always something that could make
things worse.
Well, dealing with corrupted bitmaps will be possible. I plan to expose
in the checkpoint XML whether a ckeckpoint is invalid (if it contains at
least one corrupted bitmap) and the user will have the option to delete
all previous checkpoints including the corrupted one to clear any
problem.
Note that deleting only the corrupted checkpoint will not be possible
until it's the oldest one as we attempt to merge them into the previous
ones. We could alternatively add a flag to skip merging of the invalid
checkpoint.
Plus, if you manage to corrupt bitmaps badly enough that they
can't even
be parsed, you might need a heavyweight repair operation.
Nir, do you think that'd be sufficient for your needs for now, or would
you still like to see more granular offline management?
--js
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list