From: John Snow <jsnow@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
Qemu-block <qemu-block@nongnu.org>
Cc: Nir Soffer <nsoffer@redhat.com>, Denis Lunev <den@virtuozzo.com>,
qemu-devel <qemu-devel@nongnu.org>,
"libvirt-list@redhat.com" <libvirt-list@redhat.com>
Subject: Re: Offline manipulation of Dirty Bitmaps by qemu-img
Date: Fri, 6 Dec 2019 14:07:51 -0500 [thread overview]
Message-ID: <2400b74d-2d63-676f-03f3-eb69e1622fee@redhat.com> (raw)
In-Reply-To: <d6f89557-d4e5-02f4-3082-37e61447bf87@virtuozzo.com>
On 12/6/19 5:37 AM, Vladimir Sementsov-Ogievskiy wrote:
> 06.12.2019 1:37, 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."
>>
>> 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.
>
> I think, all guys, who don't want to use Qemu directly for image manipulations,
> should hope for Kevin's "[RFC PATCH 00/18] Add qemu-storage-daemon", which is
> the correct solution of their problem. Still, I'm not one of these guys.
>
>>
>> (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.
>>
>
> Improving "check" is a correct thing, because it's done inside qcow2 driver
> itself. We just don't have corresponding qmp command or command line option
> for Qemu to use this thing (or I missed it).
>
OK, I agree. I made a redhat BZ to track that we want this: 1780416 -
RFE: qemu-img check --repair should optionally remove any
corrupted bitmaps
I'll work on a patch and we can debate the details there.
--js
prev parent reply other threads:[~2019-12-06 19:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-05 22:37 Offline manipulation of Dirty Bitmaps by qemu-img John Snow
2019-12-06 9:49 ` [libvirt] " Peter Krempa
2019-12-06 10:37 ` Vladimir Sementsov-Ogievskiy
2019-12-06 19:07 ` John Snow [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2400b74d-2d63-676f-03f3-eb69e1622fee@redhat.com \
--to=jsnow@redhat.com \
--cc=den@virtuozzo.com \
--cc=libvirt-list@redhat.com \
--cc=nsoffer@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).