From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Thomas Lamprecht <t.lamprecht@proxmox.com>,
Friedrich Weber <f.weber@proxmox.com>
Subject: Re: [pve-devel] [PATCH storage 1/2] fix #5779: rbd: allow to pass custom krbd map options
Date: Wed, 30 Oct 2024 14:29:47 +0100 (CET) [thread overview]
Message-ID: <1234079298.5156.1730294987348@webmail.proxmox.com> (raw)
In-Reply-To: <9ffcd2a7-54c6-43b4-8e11-3a8f7bdbdfeb@proxmox.com>
> Thomas Lamprecht <t.lamprecht@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?
_______________________________________________
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:[~2024-10-30 13:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 11:13 [pve-devel] [PATCH storage/docs 0/2] fix #5779: storage: rbd: allow setting custom KRBD map option(s) Friedrich Weber
2024-10-25 11:13 ` [pve-devel] [PATCH storage 1/2] fix #5779: rbd: allow to pass custom krbd map options Friedrich Weber
2024-10-29 13:58 ` Aaron Lauterer
2024-10-29 17:01 ` Friedrich Weber
2024-10-30 8:41 ` Thomas Lamprecht
2024-10-30 13:29 ` Fabian Grünbichler [this message]
2024-10-30 16:49 ` Friedrich Weber
2024-10-25 11:13 ` [pve-devel] [PATCH docs 2/2] storage: rbd: document KRBD map options property Friedrich Weber
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=1234079298.5156.1730294987348@webmail.proxmox.com \
--to=f.gruenbichler@proxmox.com \
--cc=f.weber@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/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