[PATCH storage] plugin: rbd: pass data-pool when importing volumes

[PATCH storage] plugin: rbd: pass data-pool when importing volumes

[Kefu Chai]

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 <k.chai@proxmox.com>
---
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