From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <f.ebner@proxmox.com>
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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; Mon, 17 Jul 2023 16:00:24 +0200 (CEST)
From: Fiona Ebner <f.ebner@proxmox.com>
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 <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=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 <f.ebner@proxmox.com>
---
 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