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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.