From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 328A31FF0C0 for ; Wed, 21 Oct 2026 13:40:05 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 01048215E6; Wed, 21 Oct 2026 13:40:03 +0200 (CEST) From: Kefu Chai To: pve-devel@lists.proxmox.com Subject: [PATCH storage] plugin: rbd: pass data-pool when importing volumes Date: Wed, 21 Oct 2026 19:39:56 +0800 Message-ID: <20261021113956.4111478-1-k.chai@proxmox.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1792582799355 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.292 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: OF4A73X3HOECXQYGR7WQ3JWX7FQGT7WO X-Message-ID-Hash: OF4A73X3HOECXQYGR7WQ3JWX7FQGT7WO X-MailFrom: k.chai@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: volume_import() creates the image with 'rbd import' but does not pass the storage's 'data-pool', unlike alloc_image() and clone_image(). On an RBD storage with an erasure-coded data pool, imported images therefore keep their data in the replicated metadata pool. Offline remote migrations copy disks this way. Nobody noticed because the migrated VMs run fine; only the pool usage is off. Pass the option the same way alloc_image() does. Images imported before this fix stay in the metadata pool. Since status() only reports the data pool's usage, the space they use does not show up for the storage. Moving such a disk to another storage and back puts it in the data pool. Fixes: b6f4b89 Signed-off-by: Kefu Chai --- This shows up with offline remote migrations; running VMs are fine, since their disks go through alloc_image(). I've only tried it on a vstart cluster so far, so any feedback is welcome. src/PVE/Storage/RBDPlugin.pm | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/PVE/Storage/RBDPlugin.pm b/src/PVE/Storage/RBDPlugin.pm index 2d1d7a6..f493d35 100644 --- a/src/PVE/Storage/RBDPlugin.pm +++ b/src/PVE/Storage/RBDPlugin.pm @@ -1066,8 +1066,11 @@ sub volume_import { my ($size) = PVE::Storage::Plugin::read_common_header($fh); $size = PVE::Storage::Common::align_size_up($size, 1024) / 1024; + my @options = ('--export-format', '1'); + push @options, ('--data-pool', $scfg->{'data-pool'}) if $scfg->{'data-pool'}; + eval { - my $cmd = $rbd_cmd->($scfg, $storeid, 'import', '--export-format', '1', '-', $volname); + my $cmd = $rbd_cmd->($scfg, $storeid, 'import', @options, '-', $volname); run_rbd_command( $cmd, errmsg => 'could not import image', -- 2.47.3