qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Offline manipulation of Dirty Bitmaps by qemu-img


From: John Snow
Subject: Offline manipulation of Dirty Bitmaps by qemu-img
Date: Thu, 5 Dec 2019 17:37:11 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0

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."

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.

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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]