all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Dietmar Maurer <dietmar@proxmox.com>
Cc: pve-devel@lists.proxmox.com
Subject: Re: superseded: [PATCH storage,cluster,manager 0/13] multipath: cluster-wide config, storage and health overview
Date: Fri, 3 Jul 2026 19:29:09 +0200	[thread overview]
Message-ID: <fac94fd0-5f02-4bc5-ae4a-a0828e970f2f@proxmox.com> (raw)
In-Reply-To: <mr54faau.1c8sbwbkoq0w0@proxmox.com>

Am 03.07.26 um 18:13 schrieb Dietmar Maurer:
> I just want to mention that NVMeOF has internal multipathing, so adding
> a new storage plugin for multipathing may adds some confusion (iSCSI
> need it, NVMe don't).

Yeah, I agree. That is a big part of why the type is marked as provisional.
I actually started to plan out the layered variant already before
submitting the v1: basically the transport plugins get a multipath option
(iSCSI  first) and the path handling then lives behind the transport,
dm-multipath for SCSI and native ANA for (future) NVMe-oF, so users never
have to pick a separate multipath storage at all.
But as that is quite a bit more work I basically just sent out v1 with
the simple standalone type to get early feedback on the whole direction,
and v2 to address the most grave feedback v1 got.
The cluster config and the health matrix could stay as they currently
are either way, they do not really care about the transport.
A small standalone provider might only be needed for FC, as IIRC there
the LUNs just show up on their own without any transport plugin involved.

> And I guess bad things happens if you add such nvme drive to the
> multipath storage plugin?

Nothing bad will really happen as far as I can tell, it would be just
confusing:

With native NVMe multipathing (the kernel default, ours has it built-in)
multipathd never even sees the single paths, so no dm map can get
assembled for such a WWID. One then "just" gets a 'missing' row in the
health matrix view I add here, and the storage never shows a volume for
it as it only lists actually assembled maps.
>From some basic research it seems like dm-multipath for NVMe would only
do something when explicitly booting with the nvme_core.multipath=0 on
purpose, and not sure if that's worth catering for.

I'll see if I can pick up the other approach on the weekend, but I
still think it makes sense to rebase anything from my series here,
if we actually want something from it, then on top of your work then
in any case.




      reply	other threads:[~2026-07-03 17:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26 12:07 [PATCH storage,cluster,manager 0/13] multipath: cluster-wide config, storage and health overview Thomas Lamprecht
2026-06-26 12:07 ` [PATCH storage 01/13] multipath: add helper library and managed configuration Thomas Lamprecht
2026-06-26 14:43   ` Maximiliano Sandoval
2026-06-26 12:07 ` [PATCH storage 02/13] api: disks: add read-only multipath status endpoint Thomas Lamprecht
2026-06-26 12:07 ` [PATCH storage 03/13] api: multipath: add cluster-wide configuration endpoints Thomas Lamprecht
2026-06-26 12:07 ` [PATCH storage 04/13] multipath: add storage plugin for multipath LUNs Thomas Lamprecht
2026-06-26 12:07 ` [PATCH storage 05/13] lvm: allow a multipath storage as the base device Thomas Lamprecht
2026-06-26 12:07 ` [PATCH storage 06/13] multipath: broadcast per-node map health to the cluster KV store Thomas Lamprecht
2026-06-26 12:07 ` [PATCH storage 07/13] api: multipath: add cluster-wide health status endpoint Thomas Lamprecht
2026-06-26 12:07 ` [PATCH cluster 08/13] pmxcfs: track cluster-wide multipath configuration Thomas Lamprecht
2026-06-26 12:07 ` [PATCH manager 09/13] pvestatd: apply the cluster-wide multipath config on each node Thomas Lamprecht
2026-06-26 12:07 ` [PATCH manager 10/13] api: cluster: mount the multipath configuration endpoint Thomas Lamprecht
2026-06-26 12:07 ` [PATCH manager 11/13] pvestatd: broadcast multipath map health to the cluster Thomas Lamprecht
2026-06-26 12:07 ` [PATCH manager 12/13] ui: dc: add multipath health matrix and config editor Thomas Lamprecht
2026-06-26 14:05   ` Maximiliano Sandoval
2026-06-26 12:07 ` [PATCH manager 13/13] ui: node: show multipath maps and their paths under Disks Thomas Lamprecht
2026-06-29 13:20 ` [PATCH storage,cluster,manager 0/13] multipath: cluster-wide config, storage and health overview Maximiliano Sandoval
2026-07-03 15:41 ` superseded: " Thomas Lamprecht
2026-07-03 16:12   ` Dietmar Maurer
2026-07-03 17:29     ` Thomas Lamprecht [this message]

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=fac94fd0-5f02-4bc5-ae4a-a0828e970f2f@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=dietmar@proxmox.com \
    --cc=pve-devel@lists.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 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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal