From: Fiona Ebner <f.ebner@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
vitalif@yourcmc.ru
Subject: Re: [pve-devel] Vitastor block driver plugin
Date: Mon, 1 Sep 2025 11:42:17 +0200 [thread overview]
Message-ID: <f6975055-991a-432c-a0f9-f95183a45d4d@proxmox.com> (raw)
In-Reply-To: <1ff9fa45-752d-4935-a8b7-993096413749@proxmox.com>
Hi,
Am 27.08.25 um 11:13 AM schrieb Thomas Lamprecht:
> Hello,
>
> On 26/08/2025 16:42, vitalif@yourcmc.ru wrote:
>> You've added a block device driver whitelist in Proxmox 9.0.
> It's more intended for specific driver options, but as it die's if a
> QEMU block device driver is not in the list it indeed also acts as
> allow list for those.
>> Could you please add Vitastor there?
>>
>> I mean this place: https://git.proxmox.com/?p=pve-storage.git;a=blob;f=src/PVE/Storage.pm;h=1dde2b751a766a28af8d40df7149936691cca772;hb=HEAD#l145
>>
>> $allowed_qemu_blockdev_options in PVE/Storage.pm.
>>
>> For Vitastor to work correctly, it needs to contain:
>>
>> vitastor => { image => 1, 'config-path' => 1, 'etcd-host' => 1, 'etcd-prefix' => 1 }
>
> Hmm, we could add that, but would prefer only doing so if the plugin
> is directly in QEMU already. That said, this is rather internal, so
> maintenance cost would be low, so could be still fine...
> I would like some other opinion on it though (CC @Fiona).
I think it would also be nicer if it were an upstream QEMU block driver.
Personally, I wouldn't mind including it in the allow-list, with a
comment describing the situation, because the chances that another
driver also using 'vitastor' as its name lands upstream first are very low.
Am 28.08.25 um 12:58 AM schrieb vitalif@yourcmc.ru:
> By the way, why did you add it in the first place? I thought these
> options could only contain "trusted" values coming from PVE code
> anyway? Or do some drivers really require filtering?
It can also be third-party plugins. Some settings are handled via the VM
configuration file and should not be set by the plugins, like cache
mode, read-only, etc.. Many of the possible block drivers like
job-related drivers also don't really make sense for the basic building
block that qemu_blockdev_options() is supposed to return.
Best Regards,
Fiona
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-09-01 9:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 14:33 vitalif
2025-08-27 9:13 ` Thomas Lamprecht
2025-09-01 9:42 ` Fiona Ebner [this message]
2025-08-27 22:58 ` vitalif
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f6975055-991a-432c-a0f9-f95183a45d4d@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
--cc=vitalif@yourcmc.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox