From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id D94191FF17A for ; Tue, 11 Nov 2025 13:32:16 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 380719778; Tue, 11 Nov 2025 13:33:02 +0100 (CET) From: Friedrich Weber To: pve-devel@lists.proxmox.com Date: Tue, 11 Nov 2025 13:09:30 +0100 Message-ID: <20251111123222.73957-1-f.weber@proxmox.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1762864325790 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.013 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: [pve-devel] [PATCH qemu-server v2] clone disk: fix handling of snapshot-as-volume-chain for EFI disks X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" 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 --- 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