Am 29.07.25 um 1:53 PM schrieb Fabian Grünbichler: > we don't want qcow2 files to reference their backing chains via > absolute paths, as that makes renaming the base dir or VG of the storage > impossible. in most places, qemu already allows simply passing a > filename as backing-file reference, which will be interpreted as a > reference relative to the backed image. > > I haven't found any further code paths that trigger absolute references, > but I might have missed some. the full backing chain should show > relative backing-file members when queried via > > qemu-img info --output json --format qcow2 --backing-chain > /path/to/main/image.qcow2 > > such, as: > > "full-backing-filename": > "/var/lib/extsnap/images/210/snap-test2-vm-210-disk-0.qcow2", > "backing-filename": "snap-test2-vm-210-disk-0.qcow2", > > note that full-backing-filename will always contain the resolved, > absolute path and that is okay. we could warn about both members > containing full paths in `volume_snapshot_info`. > > for existing "broken" images, an "unsafe" rebase with > > qemu-img rebase -u -f qcow2 -F qcow2 -b <relative backing file path> > <absolute backed filed path> > > should just rewrite the qcow2 header to replace the backing file > reference - this should of course not be run while the image is being > written by other process or QEMU.
Applied series, with the discussed fix-up squashed in, thanks! _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
