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.ping...@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
signature.asc
Description: OpenPGP digital signature