From: Friedrich Weber <f.weber@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] [PATCH qemu-server v2] clone disk: fix handling of snapshot-as-volume-chain for EFI disks
Date: Tue, 11 Nov 2025 13:09:30 +0100 [thread overview]
Message-ID: <20251111123222.73957-1-f.weber@proxmox.com> (raw)
Currently, cloning an EFI disk off a snapshot-as-volume-chain snapshot
fails with "qemu-img: Failed to load snapshot: Can't find snapshot".
The reason is that the special case for EFI disks calls `qemu-img dd`
with the additional `-l snapname` option, which is only valid for
qcow2-internal snapshots. For snapshot-as-volume-chain snapshots, the
source volume is already the volume corresponding to the snapshot.
Fix this by checking the snapshot method of the volume in question,
and only adding the `-l` option if the volume uses qcow2-internal
snapshots.
Reported in enterprise support.
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
---
Notes:
Reproducer (STORAGE having snapshot-as-volume-chain enabled):
qm create 100 --bios ovmf --efidisk0 STORAGE:1,format=qcow2
qm snapshot 100 mysnap
qm clone 100 101 --snap mysnap
The rfc used volume_snapshot_info, but this seems to be somewhat buggy
and the fix might be more involed (see rfc). I did not have time to
look into fixing volume_snapshot_info -- since using
volume_qemu_snapshot_method here also sounds appropriate and should
fix the bug, I'm sending this new version here.
changes since rfc:
- check PVE::Storage::volume_qemu_snapshot_method instead of
volume_snapshot_info
rfc: https://lore.proxmox.com/pve-devel/20251107171910.129794-1-f.weber@proxmox.com/
src/PVE/QemuServer.pm | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm
index cf195ccc..3ea3236c 100644
--- a/src/PVE/QemuServer.pm
+++ b/src/PVE/QemuServer.pm
@@ -7868,7 +7868,11 @@ sub clone_disk {
if ($src_format eq 'qcow2' && $snapname) {
die "cannot clone qcow2 EFI disk snapshot - requires QEMU >= 6.2\n"
if !min_version(kvm_user_version(), 6, 2);
- push $cmd->@*, '-l', $snapname;
+
+ my $method =
+ PVE::Storage::volume_qemu_snapshot_method($storecfg, $drive->{file});
+ # in case of snapshot-as-volume-chain, $src_path points to the snapshot volume
+ push $cmd->@*, '-l', $snapname if $method eq 'qemu';
}
push $cmd->@*, "bs=$bs", "osize=$size", "if=$src_path", "of=$dst_path";
run_command($cmd);
--
2.47.3
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next reply other threads:[~2025-11-11 12:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-11 12:09 Friedrich Weber [this message]
2025-11-12 14:23 ` [pve-devel] applied: " Thomas Lamprecht
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=20251111123222.73957-1-f.weber@proxmox.com \
--to=f.weber@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.