Re: [PATCH 0/3] block: Keep auto_backing_file post-migration

[Kevin Wolf]

Am 03.08.2022 um 16:44 hat Hanna Reitz geschrieben:
> Hi,
> 
> https://gitlab.com/qemu-project/qemu/-/issues/1117 reports the following
> issue:
> 
> Say you have a VM with a backing chain of images where the image
> metadata contains json:{} backing file strings, which however will be
> resolved to simple plain filenames when opened[1].
> 
> So when these images are opened, bs->auto_backing_file is first read
> directly from the image header, and will thus contain a json:{}
> filename.  The backing image is opened based off of this filename, and
> bdrv_refresh_filename() simplfies the filename as shown[1].  We then
> update bs->auto_backing_file from bs->backing->bs->filename, so both are
> equal.
> 
> It is quite important that both are equal, because
> bdrv_backing_overridden() checks whether the backing file has been
> changed from the default by comparing bs->auto_backing_file to
> bs->backing->bs->filename.
> 
> Because we did set bs->auto_backing_file from bs->backing->bs->filename,
> both are equal, the backing file is not considered overridden, and
> bdrv_refresh_filename(bs) will not consider it necessary to generate a
> json:{} filename for the overlay.
> 
> Then the VM is migrated.
> 
> The destination side invokes bdrv_invalidate_cache(), which by qcow2 and
> qed is implemented by closing the image and opening it.  This re-reads
> the backing file string from disk, resetting bs->auto_backing_file.
> Now, it will contains the json:{} filename again and thus differ from
> bs->backing->bs->filename.
> 
> Consequentially, a subsequent bdrv_refresh_filename(bs) will find that
> the overlay’s backing file has been overridden and generate a json:{}
> filename, which isn’t great.
> 
> This series fixes that by having qcow2’s and qed’s image-open operations
> not overwrite bs->auto_backing_file unless something has changed since
> the last time we read the backing filename from the metadata.
> 
> 
> Now, generating a json:{} filename can be a nuisance but shouldn’t be a
> real problem.  The actual problem reported in 1117 comes later, namely
> when creating a snapshot overlay post-migration.  This overlay image
> will have a json:{} backing filename in its image metadata, which
> contains a 'backing' key[2].
> 
> 'qemu-img info' uses the BDRV_O_NO_BACKING flag to open images, which
> conflicts with those backing options: With that flag, nobody processes
> those options, and that’s an error.  Therefore, you can’t run 'qemu-img
> info --backing-chain' on that overlay image.
> 
> That part of the issue is not fixed in this series, however.  I’ll send
> a separate RFC series for it, because I’m honstly not quite certain how
> it should be fixed.
> 
> 
> [1] Example:
>         json:{"driver": "qcow2",
>               "file": {"driver": "file", "filename": "img.qcow2"}}
>     Will generally be “resolved” by bdrv_refresh_filename() to
>         "img.qcow2"
> 
> [2] That it contains a 'backing' key is only natural, because the reason
>     why bdrv_refresh_filename() decided to generate a json:{} filename
>     for the image is because it considered the backing file overridden.
>     Hence it must put the actual backing file options into a 'backing'
>     object in the json:{} filename.
> 
> 
> Hanna Reitz (3):
>   block/qcow2: Keep auto_backing_file if possible
>   block/qed: Keep auto_backing_file if possible
>   iotests/backing-file-invalidation: Add new test

Thanks, applied to the block branch.

Kevin