Re: [Qemu-devel] [PATCH] Block layer core: Fix qemu-img 'amend' subcommand failure of adjusting backing file in different path

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

On 22.04.2017 00:34, Ping Li wrote:
> Currently, qemu-img 'amend' subcommand would fail to adjust image's backing file
> which was moved into different path.
> For example, parent.qcow2, the backing file of leaf.qcow2, first is at /home/a/,
> then moved into /home/b/. Originally this command,
>  "qemu-img amend -f qcow2 -o backing_fmt=qcow2,backing_file=/home/b/parent.qcow2 leaf.qcow2",
>  would fail because qemu-img failed to open the old backing file of leaf.qcow2.
> Give the 'amend' subcommand a '-u' option to not open the old backing file
>  while openning leaf.qcow2.
> 
> Signed-off-by: Li Ping<li.ping288@zte.com.cn>
> ---
>  qemu-img.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)

So why can't you just use rebase -u?

I'm not completely opposed to adding this functionality to amend, but
I'd actually rather remove the ability to change the backing file from
amend than to add functionality that may turn out to be rather
complicated to implement...

As Eric has proposed, I also think we could turn on BDRV_O_NO_BACKING
automatically if the option list consists of nothing but backing_file
and backing_fmt. But then we'd have to think about the case where the
user gives both backing_file and some other option at the same time; it
may be unexpected that we do open the backing file in that case. The
best might actually to error out so the user is forced to do both
changes separately -- but at that point the logic gets so complicated
that I think we should at most add a note to qemu-img's man page that
qemu-img amend will open the backing file and that users should use
rebase -u if that is not desired...

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 512 bytes --]