On 3/26/21 9:55 AM, Max Reitz wrote: > Three test cases: > (1) Adding a qcow2 (metadata) file to an existing data file, see whether > we can read the existing data through the qcow2 image. > (2) Append data to the data file, grow the qcow2 image accordingly, see > whether we can read the new data through the qcow2 image. > (3) At runtime, add a backing image to a freshly created qcow2 image > with an external data file (with data-file-raw). Reading data from > the qcow2 image must return the same result as reading data from the > data file, so everything in the backing image must be ignored. > (This did not use to be the case, because without the L2 tables > preallocated, all clusters would appear as unallocated, and so the > qcow2 driver would fall through to the backing file.) > > Signed-off-by: Max Reitz <mre...@redhat.com> > --- > tests/qemu-iotests/244 | 104 +++++++++++++++++++++++++++++++++++++ > tests/qemu-iotests/244.out | 59 +++++++++++++++++++++ > 2 files changed, 163 insertions(+) >
> + > +# We cannot use qemu-img to create the qcow2 image, because it would > +# clear the data file. Use the blockdev-create job instead, which will > +# only format the qcow2 image file. Well, perhaps we could use qemu-img to create a qcow2 pointing to a temporary file, then rewrite it to point to the real data file, but that feels hackish, and your approach worked. And besides, while we have qemu-img rebase -u to rewrite the backing file, I don't know if we have a similar qemu-img command for rewriting the data file. Reviewed-by: Eric Blake <ebl...@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
