[sheepdog] [PATCH v3 1/4] block: Add trivial backing_fmt support to qcow, sheepdog, vmdk

Eric Blake eblake at redhat.com
Mon Mar 9 16:50:02 CET 2020

On 3/9/20 10:36 AM, Daniel P. Berrangé wrote:
> On Mon, Mar 09, 2020 at 04:21:12PM +0100, Kevin Wolf wrote:
>> Am 06.03.2020 um 23:51 hat Eric Blake geschrieben:
>>> For qcow2 and qed, we want to encourage the use of -F always, as these
>>> formats can suffer from data corruption or security holes if backing
>>> format is probed.  But for other formats, the backing format cannot be
>>> recorded.  Making the user decide on a per-format basis whether to
>>> supply a backing format string is awkward, better is to just blindly
>>> accept a backing format argument even if it is ignored by the
>>> contraints of the format at hand.
>>> Signed-off-by: Eric Blake <eblake at redhat.com>
>> I'm not sure if I agree with this reasoning. Accepting and silently
>> ignoring -F could give users a false sense of security. If I specify a
>> -F raw and QEMU later probes qcow2, that would be very surprising.
> And if the user specifies "-F raw" and we probe qcow2, and the user
> does not realize this, they can become silently reliant on always
> probing qcow2. If we then honour the "-F raw" option in a later
> QEMU release, we'll break the behaviour they've relied on.
> IMHO, we must not accept "-F fmt" unless we're in a position to
> honour it.

So I'm thinking:

qemu-img create -f qcow -b backing.qcow -F qcow img.qcow   => okay

qemu-img create -f qcow -b backing.raw -F raw img.qcow   => okay, 
slightly risky (if backing.raw is ever changed to be non-raw), but then 
again, backing files tend to be read-only (do we even support commit on 
qcow images, or do we limit that to qcow2?)

qemu-img create -f qcow -b backing.qcow -F raw img.qcow   => fails, due 
to mismatch

qemu-img create -u -f qcow -b anything -F anything img.qcow $size  => 
fails: we can't write -F into the image, nor can we open anything to 
probe its type to check that -F was correct

qemu-img create -f qcow -b backing.qcow img.qcow   => warns, but okay 
(we did not get -F, but the probe works out)

qemu-img create -f qcow -b backing.raw img.qcow    => likewise warns

qemu-img create -f qcow -b backing.qcow2 img.qcow   => error; new qcow 
images (which you should avoid where possible anyways) must be backed by 
only raw or qcow, going forward

Other scenarios?  Do the above ideas look reasonable?

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

More information about the sheepdog mailing list