[pve-devel] [PATCH storage 1/2] fix #5779: rbd: allow to pass custom krbd map options

[Fabian Grünbichler]

> Thomas Lamprecht <t.lamprecht at proxmox.com> hat am 30.10.2024 09:41 CET geschrieben:
> 
>  
> Am 25/10/2024 um 13:13 schrieb Friedrich Weber:
> > When KRBD is enabled for an RBD storage, the storage plugin calls out
> > to `rbd map` to map an RBD image as a block device on the host.
> > Sometimes it might be necessary to pass custom options to `rbd map`.
> > For instance, in some setups with Windows VMs, KRBD logs `bad
> > crc/signature` and VMs performance is degraded unless the `rxbounce`
> > option is enabled, as reported in the forum [1].
> > 
> > To allow users to specify custom options for KRBD, introduce a
> > corresponding `krbd-map-options` property to the RBD plugin. The
> > property is designed to only accept a supported set of map options.
> > For now, this is only the `rxbounce` map option, but the supported set
> > can be extended in the future.
> > 
> > The reasoning for constraining the supported set of map options
> > instead of allowing to pass a free-form option string is as follows:
> > If `rxbounce` turns out to be a sensible default, accepting a
> > free-form option string now will make it hard to switch over the
> > default to `rxbounce` while still allowing users to disable `rxbounce`
> > if needed. This would require scanning the free-form string for a
> > `norxbounce` or similar, which is cumbersome.
> 
> Reading the Ceph KRBD option docs [0] it seems a bit like it might
> be valid to always enable this for OS type Windows? Which could safe
> us an option here and avoid doing this storage wide.
> 
> [0]: https://docs.ceph.com/en/reef/man/8/rbd/#kernel-rbd-krbd-options
> 
> > If users need to set a map option that `krbd-map-options` does not
> > support (yet), they can alternatively set the RBD config option
> > `rbd_default_map_options` [2].
> 
> But that would work now already? So this is basically just to expose it
> directly in the PVE (UI) stack?
> 
> One reason I'm not totally happy with such stuff is that storage wide is
> quite a big scope; users might then tend to configure the same Ceph pool as
> multiple PVE storages, something that can have bad side effects.
> We basically had this issue for when the krbd flag was added first, then
> it was an "always use krbd or never user krbd" flag, now it's rather an
> "always use krbd or else use what works (librbd for VMs and krbd for CTs)"
> flag, and a big reason was that otherwise one would need two pools or,
> worse, exposing the same pool twice to PVE. This patch feels a bit like
> going slightly back to that direction, albeit it's not 1:1 the same and
> it might be fine, but I'd also like to have the alternatives evaluated a
> bit more closely before going this route.

that would require a way to pass this information through via PVE::Storage::activate_volumes, which currently doesn't exist.. and of course, in a way this would increase coupling of (in this case) qemu-server and pve-storage. maybe it would make sense to evaluate whether we have other use cases for such a mechanism, and decide based on that?

in any case, if the option stays in pve-storage like proposed in this series, it seems its format should be an enum-string(-list), instead of a manual verify sub?