[PATCH v5 4/7] qcow2: Deprecate use of qemu-img amend to change backing file

[Kevin Wolf]

Am 03.04.2020 um 19:58 hat Eric Blake geschrieben:
> The use of 'qemu-img amend' to change qcow2 backing files is not
> tested very well.  In particular, our implementation has a bug where
> if a new backing file is provided without a format, then the prior
> format is blindly reused, even if this results in data corruption, but
> this is not caught by iotests.
> 
> There are also situations where amending other options needs access to
> the original backing file (for example, on a downgrade to a v2 image,
> knowing whether a v3 zero cluster must be allocated or may be left
> unallocated depends on knowing whether the backing file already reads
> as zero), but the command line does not have a nice way to tell us
> both the backing file to use for opening the image as well as the
> backing file to install after the operation is complete.
> 
> Even if we do allow changing the backing file, it is redundant with
> the existing ability to change backing files via 'qemu-img rebase -u'.
> It is time to deprecate this support (leaving the existing behavior
> intact, even if it is buggy), and at a point in the future, require
> the use of only 'qemu-img rebase' for adjusting backing chain
> relations, saving 'qemu-img amend' for changes unrelated to the
> backing chain.
> 
> Signed-off-by: Eric Blake <eblake at redhat.com>

I think the original idea was that in BlockDriver, special interfaces
like the ones used by qemu-img rebase could eventually go away if we
have a single consistent interface to change image options, which is
amend. So ideally, bdrv_change_backing_file() should become a wrapper
around amend.

I'm not even sure if the behaviour you mention should be considered a
bug because amend is a low-level interface. But even if that's the case,
it would be a matter of simply adding a check.

Kevin