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

From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>,
	"Proxmox VE development discussion" <pve-devel@lists.proxmox.com>,
	"Fiona Ebner" <f.ebner@proxmox.com>
Subject: Re: [pve-devel] [PATCH v3 storage 1/9] plugin: add method to get qemu blockdevice options for volume
Date: Wed, 2 Jul 2025 10:27:46 +0200	[thread overview]
Message-ID: <3579475c-b0d6-4ccd-8f39-9d669231726f@proxmox.com> (raw)
In-Reply-To: <510878923.207.1751368148105@webmail.proxmox.com>

Am 01.07.25 um 13:09 schrieb Fabian Grünbichler:
>> Am 01.07.25 um 11:28 schrieb Thomas Lamprecht:
>>> might make sense to pass some versioning information here, as otherwise this
>>> is a bit to tight coupling for my taste and might cause long term maintenance
>>> headache.
> 
> we discussed this in the past - this coupling is already there (see below), and
> either qemu-server needs to hard-code storage things (which excludes third party
> plugins), or pve-storage needs to encode some qemu things (the option we chose,
> since there was already precedent and QEMU does provide a somewhat stable
> interface there).

> this is also how plugins already work:
> - path returns arbitrary drive options (if it's not an actual file path)

Which means my assumption that external plugins could not pass options
in my other reply was wrong, so we would at least need to grandfather
limitations in (like checking if api-version > current-version), not ideal
but would be a way forward.

> - plugins are 100% trusted and executed in root context already, so there isn't
>   much we can safeguard against..
So, we do lots of work here and got the chance to quite probably make
the future target of having a more contained plugin and QEMU a little
bit easier just to argue moving laterally because the status quo is
like that? I'd care much if this would be internal only, but as it's a
versioned public API that I do not want to break if not necessary I'd like
to have this explored more, not just (to exaggerate, I know you both
are quite thorough) hand waved away.

I mean, OTOH, once actual works towards plugin/VM containment starts we
probably want to have a feature for that storage plugins need to signal
support for, maybe combined with some other mechanisms, and that again
would be grandfathered in for one major version (and/or configurable by
the user) so we probably can still move towards more limitations also here
in the future without a hard break. So, the option limitations don't need
to necessarily happen now, but I'd really add the machine version now already,
as that should at least allows plugin authors to better navigate the coupling
we got here.

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