Re: [pve-devel] [RFC storage 1/3] plugin: add method to get qemu blockdevice options for volume

["DERUMIER, Alexandre via pve-devel" <pve-devel@lists.proxmox.com>]

[-- Attachment #1: Type: message/rfc822, Size: 19258 bytes --]

From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>, "f.ebner@proxmox.com" <f.ebner@proxmox.com>
Subject: Re: [pve-devel] [RFC storage 1/3] plugin: add method to get qemu blockdevice options for volume
Date: Fri, 23 May 2025 08:19:22 +0000
Message-ID: <eeb11ec08d36c3a6f5290134158e91ad7be8b432.camel@groupe-cyllene.com>

Hi Fiona,

do we still support glusterfs for pve9 (as it's deprecated)?

-------- Message initial --------
De: Fiona Ebner <f.ebner@proxmox.com>
Répondre à: Proxmox VE development discussion <pve-
devel@lists.proxmox.com>
À: pve-devel@lists.proxmox.com
Objet: [pve-devel] [RFC storage 1/3] plugin: add method to get qemu
blockdevice options for volume
Date: 09/05/2025 16:15:30

There intentionally is only handling for absolute paths in the default
plugin implementation. Any plugin requiring more needs to implement
the method itself.

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---

I discussed this with Fabian off-list. With PVE 9 being a major
release and most popular plugins not using special protocols like
'rbd://', this seems acceptable. He'll also give a heads-up to known
plugin developers with other changes for PVE 9 in time.

For NBD, etc. qemu-server should construct the blockdev object.

Still missing API bump + Changelog

Did not test snapshots yet.

 src/PVE/Storage.pm        | 19 ++++++++++++
 src/PVE/Storage/Plugin.pm | 64 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 83 insertions(+)

diff --git a/src/PVE/Storage.pm b/src/PVE/Storage.pm
index d0a696a..5915395 100755
--- a/src/PVE/Storage.pm
+++ b/src/PVE/Storage.pm
@@ -710,6 +710,25 @@ sub abs_filesystem_path {
     return $path;
 }
 
+sub qemu_blockdev_options {
+    my ($cfg, $volid, $snapname) = @_;
+
+    my ($storeid, $volname) = parse_volume_id($volid);
+
+    my $scfg = storage_config($cfg, $storeid);
+
+    my $plugin = PVE::Storage::Plugin->lookup($scfg->{type});
+
+    my ($vtype) = $plugin->parse_volname($volname);
+    die "cannot use volume of type '$vtype' as a QEMU blockdevice\n"
+	if $vtype ne 'images' && $vtype ne 'iso' && $vtype ne
'import';
+
+    die "QEMU blockdevice - 'snapname' argument is not supported for
vtype '$vtype'"
+	if $snapname && $vtype ne 'images';
+
+    return $plugin->qemu_blockdev_options($scfg, $storeid, $volname,
$snapname);
+}
+
 # used as last resort to adapt volnames when migrating
 my $volname_for_storage = sub {
     my ($cfg, $storeid, $name, $vmid, $format) = @_;
diff --git a/src/PVE/Storage/Plugin.pm b/src/PVE/Storage/Plugin.pm
index 4e16420..dc3c6df 100644
--- a/src/PVE/Storage/Plugin.pm
+++ b/src/PVE/Storage/Plugin.pm
@@ -1880,6 +1880,70 @@ sub rename_volume {
     return "${storeid}:${base}${target_vmid}/${target_volname}";
 }
 
+=pod
+
+=head3 qemu_blockdev_options
+
+    $blockdev = $plugin->qemu_blockdev_options($scfg, $storeid,
$volname, $snapname)
+
+Returns a hash reference with the basic options needed to open the
volume via QEMU's C<-blockdev>
+API. This at least requires a C<< $blockdev->{driver} >> and a
reference to the image, e.g.
+C<< $blockdev->{filename} >> for the C<file> driver. For files, the
C<file> driver can be used. For
+host block devices, the C<host_device> driver can be used. The plugin
must not set options like
+C<cache> or C<aio>. Those are managed by qemu-server and will be
overwritten. For other available
+drivers and the exact specification of the options, see
+L<https://antiphishing.vadesecure.com/v4?f=UU1XcHkxazJBTmIySlBBMWR_zLc
v5a0_cIOSeWbIK2KapikXx8zXaPqWjlzjA2kV1Dznkr2dclNPHmvBavMw9A&i=RTNLd2NGe
E1RTDFrR25iaOm2xB-
k3c1aAk9xq9J3vLE&k=ywmE&r=ZnVkMm1UMHFmWHNzejI1TlffqTgRgYngUnr3SAFiUmsWi
qzGK6dBlW9tfep801MY&s=7964585ab390894467d9e21a57498f84ada52f1951c00b01c
c9facbdff1f8b32&u=https%3A%2F%2Fqemu.readthedocs.io%2Fen%2Fmaster%2Fint
erop%2Fqemu-qmp-ref.html%23object-QMP-block-core.BlockdevOptions>
+
+While Perl does not have explicit types, the result will need to be
converted to JSON later and
+match the QMP specification (see link above), so implicit types are
important. In the return value,
+use C<JSON::true> and C<JSON::false> for booleans, C<"$value"> for
strings, and C<int($value)> for
+integers.
+
+Arguments:
+
+=over
+
+=item C<$scfg>
+
+The hash reference with the storage configuration.
+
+=item C<$storeid>
+
+The storage ID.
+
+=item C<$volume>
+
+The volume name.
+
+=item C<$snapname>
+
+(optional) The snapshot name. Set when the associated snapshot should
be opened
+rather than the volume itself.
+
+=back
+
+=cut
+sub qemu_blockdev_options {
+    my ($class, $scfg, $storeid, $volname, $snapname) = @_;
+
+    my $blockdev = {};
+
+    my ($path) = $class->path($scfg, $volname, $storeid, $snapname);
+
+    if ($path =~ m|^/|) {
+	# The 'file' driver only works for regular files. The check
below is taken from
+	# block/file-posix.c:hdev_probe_device() in QEMU. Do not
bother with detecting 'host_cdrom'
+	# devices here, those are not managed by the storage layer.
+	my $st = File::stat::stat($path);
+	my $driver = (S_ISCHR($st->mode) || S_ISBLK($st->mode)) ?
'host_device' : 'file';
+	$blockdev = { driver => $driver, filename => $path };
+    } else {
+	die "storage plugin doesn't implement qemu_blockdev_options()
method\n";
+    }
+
+    return $blockdev;
+}
+
 # Used by storage plugins for external backup providers. See
PVE::BackupProvider::Plugin for the API
 # the provider needs to implement.
 #

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel