[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/3] block: Keep auto_backing_file post-migration
From: |
Kevin Wolf |
Subject: |
Re: [PATCH 0/3] block: Keep auto_backing_file post-migration |
Date: |
Thu, 22 Sep 2022 18:26:01 +0200 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH 0/3] block: Keep auto_backing_file post-migration,
Kevin Wolf <=