From: Fiona Ebner <f.ebner@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>,
"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: [pve-devel] applied-series: [PATCH storage/qemu-server v2 0/5] avoid absolute qcow2 references
Date: Tue, 29 Jul 2025 14:51:57 +0200 [thread overview]
Message-ID: <4eb3b3fd-a488-4b0f-b57b-783b1ac76267@proxmox.com> (raw)
In-Reply-To: <20250729115320.579286-1-f.gruenbichler@proxmox.com>
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
prev parent reply other threads:[~2025-07-29 12:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-29 11:53 [pve-devel] " Fabian Grünbichler
2025-07-29 11:53 ` [pve-devel] [PATCH storage v2 1/5] plugin: fix typo in rebase log message Fabian Grünbichler
2025-07-29 12:04 ` Fiona Ebner
2025-07-29 12:15 ` Fabian Grünbichler
2025-07-29 11:53 ` [pve-devel] [PATCH storage v2 2/5] lvm " Fabian Grünbichler
2025-07-29 11:53 ` [pve-devel] [PATCH storage v2 3/5] plugin: use relative path for qcow2 rebase command Fabian Grünbichler
2025-07-29 11:53 ` [pve-devel] [PATCH storage v2 4/5] lvm " Fabian Grünbichler
2025-07-29 11:53 ` [pve-devel] [PATCH qemu-server v2 5/5] blockdev-stream/-commit: make backing file relative Fabian Grünbichler
2025-07-29 12:51 ` Fiona Ebner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4eb3b3fd-a488-4b0f-b57b-783b1ac76267@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=f.gruenbichler@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox