[Top][All Lists]

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

Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/3] block: Warn about usage of

From: Max Reitz
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/3] block: Warn about usage of growing formats over non-growable protocols
Date: Wed, 06 May 2015 18:12:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 06.05.2015 17:30, Paolo Bonzini wrote:

On 06/05/2015 15:04, Max Reitz wrote:
Introducing a warning for a normal QEMU invocation is a bit weird.

What is the point of this series?  Were users confused that they hit
Users were confused when exporting a qcow2 image using nbd-server
instead of qemu-img, and then accessing that NBD export with qemu
(subsequently getting I/O errors on guest writes, if the image is not
yet fully allocated): http://bugzilla.redhat.com/show_bug.cgi?id=1090713
I think NBD exports of non-raw images falls within the case of "user
should know what they're doing".  In particular, you don't even need
metadata preallocation, you just need a "truncate -s10G file.qcow2"
before invoking nbd-server.

Well, actually, you need to export it with qemu-nbd instead of nbd-server; which this series is trying to tell the users.

So I think it's not worth fixing this, even though I see how it can be a
minor UI/UX issue.

I very much think it would be worth fixing, if there wasn't the problem with legitimate use cases throwing unnecessary warnings.

I remember having a discussion with Kevin about this series (v1) regarding qcow2 on LVM; I think my point was that the warning is basically still correct, or only needs rewording (oops, I guess I did forget that in v2). If you are using qcow2 on LVM, you need to know exactly what you are doing, so a warning about this is indeed appropriate (in my opinion, that is).

So I think if we can word the warning in a way to make it clear that there are legitimate use cases, but you need to know what you are doing, I think it's worth having this warning. Users who know what they're doing won't be surprised or at least will know what it means, while users who don't know what it means most probably don't know what they're doing and thus the warning is appropriate for them.

And if you're using management software (which hopefully does know what it's doing), the warning shouldn't be prominently visible anyway (in case of using libvirt, stderr is written to a log file, right?).


reply via email to

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