On 3/10/20 5:57 AM, Kashyap Chamarthy wrote:
On Mon, Mar 09, 2020 at 10:42:25AM -0500, Eric Blake wrote:
[...]
+qemu-img backing file without format (since 5.0.0)
+''''''''''''''''''''''''''''''''''''''''''''''''''
+
+The use of ``qemu-img create``, ``qemu-img rebase``, ``qemu-img
+convert``, or ``qemu-img amend`` to create or modify an image that
+depends on a backing file now recommends that an explicit backing
+format be provided.
Also for the `qemu-img amend` case, I'm not clear if the following scenario
ought to throw the warning:
$> ~/build/qemu/qemu-img info --backing-chain overlay1.qcow2
image: overlay1.qcow2
file format: qcow2
virtual size: 4 GiB (4294967296 bytes)
disk size: 196 KiB
cluster_size: 65536
backing file: base.raw
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
image: base.raw
file format: raw
virtual size: 4 GiB (4294967296 bytes)
disk size: 778 MiB
$> ~/build/qemu/qemu-img amend -o compat=v3 overlay1.qcow2
This particular amend is not changing the backing file, and since I did
not add warnings on the opening of an existing unsafe image, it is
silent. Instead, you need to test a case where amend provokes a path
that would change the backing file (perhaps as simple as '-o
backing_file=./base.raw'), while omitting a format for the new backing
file string.
$> echo $?
0
I'm just trying to work out the scenarios where the warnings ought to
show up (for all the four cases: create, rebase, convert, amend).
Look at patch 2/4 - that patch was written AFTER this patch in order to
silence every warning that was introduced because of this patch, then
rebased to occur first. My experience in writing 2/4 was that I indeed
hit warnings through all four sub-commands.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
