From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id E43E7DB08 for ; Mon, 17 Jul 2023 16:00:55 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C7B1AE21D for ; Mon, 17 Jul 2023 16:00:25 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 17 Jul 2023 16:00:25 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id F23F2428B6 for ; Mon, 17 Jul 2023 16:00:24 +0200 (CEST) From: Fiona Ebner To: pve-devel@lists.proxmox.com Date: Mon, 17 Jul 2023 16:00:19 +0200 Message-Id: <20230717140020.74568-2-f.ebner@proxmox.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230717140020.74568-1-f.ebner@proxmox.com> References: <20230717140020.74568-1-f.ebner@proxmox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.045 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 T_SCC_BODY_TEXT_LINE -0.01 - Subject: [pve-devel] [PATCH qemu-server 1/2] migration: alloc nbd disks: base format hint off source storage 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: , X-List-Received-Date: Mon, 17 Jul 2023 14:00:55 -0000 Previously, qemu_img_format() was called with the target storage's $scfg and the source storage's volume name. This mismatch should only be relevant for certain special kinds of storage plugins: - no path, but does support an additional QEMU image format besides 'raw', in short NPAF. - no path, volume name can match QEMU_FORMAT_RE, in short NPVM. Note that all integrated plugins are neither NPAF nor NPVM. Note that for NPAF plugins, qemu_img_format() already always returns 'raw' because there is no path. It's a bit unlikely such a plugin exists, because there were no bug reports about qemu_img_format() misbehaving there yet. Let's go through the cases: - If source and target storage both have or don't have a path, qemu_img_format($scfg, $volname) returns the same for both $scfg's. - If source storage has a path, but target storage does not, the format hint was previously 'raw', but can only be more correct now (being what the source image actually is): - For non-NPAF targets, since we know there is no path, it follows that 'raw' is the only supported QEMU image format. - For NPAF targets, the format will be preserved now (if actually supported). - If source storage does not have a path, but target storage does, the format hint will be 'raw' now. - For non-NPVM sources, QEMU_FORMAT_RE didn't match when qemu_img_format() was called with the target storage's $scfg, so the hint also was 'raw' before this commit. - For NPVM sources, qemu_img_format() might've guessed a format from the source volume name when called with the target's $scfg before this commit. If the target storage supports the previously guessed format, it was preserved before this commit, but will not be anymore. In theory, the guess might've also been wrong, and in this case, this commit avoids the wrong guess. To summarize, there is only one edge case with an exotic kind of third party storage plugin where format preservation would be lost and in another edge case, format preservation is gained. In preparation to simplify the format fallback logic implementation. Signed-off-by: Fiona Ebner --- PVE/QemuServer.pm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm index 430661a7..a692e32e 100644 --- a/PVE/QemuServer.pm +++ b/PVE/QemuServer.pm @@ -5583,12 +5583,12 @@ sub vm_migrate_alloc_nbd_disks { # 2. format of current volume # 3. default format of storage if (!$storagemap->{identity}) { + my $source_scfg = PVE::Storage::storage_config($storecfg, $storeid); $storeid = PVE::JSONSchema::map_id($storagemap, $storeid); my ($defFormat, $validFormats) = PVE::Storage::storage_default_format($storecfg, $storeid); if (!$format || !grep { $format eq $_ } @$validFormats) { if ($volname) { - my $scfg = PVE::Storage::storage_config($storecfg, $storeid); - my $fileFormat = qemu_img_format($scfg, $volname); + my $fileFormat = qemu_img_format($source_scfg, $volname); $format = $fileFormat if grep { $fileFormat eq $_ } @$validFormats; } -- 2.39.2