public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Mira Limbeck <m.limbeck@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] Further development of iSCSI functionalities in Proxmox VE
Date: Wed, 19 Nov 2025 13:44:21 +0100	[thread overview]
Message-ID: <56cf532c-b268-463b-a60b-f49c8e9cfcdb@proxmox.com> (raw)
In-Reply-To: <mailman.656.1759584202.390.pve-devel@lists.proxmox.com>

Hi Felix,

Sorry for the late reply. I missed the mail.

Before we start implementing we'd like to know if there are any related
ongoing/past developments and if such changes fit the project.

These are changes we plan to contribute:

    1. Improvements to the GUI:
        a) Better Disk Image names, when configuring a VM with iSCSI
(Multipath) Storage:
            Currently, Disk Images have Names such as "CH 00 ID 0 LUN
0", which are hard to correlate to Disks on the iSCSI System. Instead,
additional Information such as WWID should be visible.
That sounds like a good idea! So far I'm not aware of anyone working on
that.
It might be useful as well to show which multipath they are a part of.

        b) Addition of Multipath path healthiness to the GUI (as can be
seen with multipath -ll)
That's probably going to be difficult. We don't show the multipath
devices anywhere separately. But for this we would probably need an
overview over all configured multipath devices.

This could be something for when we make multipath configurable via our
tooling and GUI.


    2. Changes to iSCSI Configuration:
        a) Addition of optional CHAP Authentication
        b) Configuration of multiple Discovery Portals for iSCSI
storage’s, in case iSCSI systems do not announce all Portals
I'm currently working on a storage mapping series [0]. In there we could
probably add support for CHAP authentication as well, once we have it in
the current plugin for the simple case.
So feel free to work on CHAP authentication for now. There will be lots
of changes coming to the ISCSIPlugin though.

Regarding multiple discovery portals, we don't currently support
separate discovery portals. The portal that is configured as part of the
storage, is one we expect to be reachable all the time, as otherwise the
storage will not be shown as `active`.

But adding discovery portals to the storage mapping series does make sense.
I'll see if I can add it to the v2 of the series.

I'm not sure it makes sense to add discovery portals to the current
plugin. I'd rather prefer using the mapping way instead.


    3. Resize/Re-scan & other Life-cycle features
The issue with those is, that it always depends on the SAN if it works
by default or not.

        a) Addition of a refresh button or something similar to fetch
LUN Information again
That should already be done by default on every pvestatd update loop
iteration, no?

        b) Online resize of LUNs (visible on Hypervisor as well as in
VM); Either automatically or with a manual refresh button
Having a button to run `rescan-scsi-bus.sh -s` or whichever command is
required, could make sense.
Since we don't install sg3-utils by default, that button would have to
be optionally enabled when it is available.
Or maybe we could start depending on it in the future.

        c) deletion and cleanup of unused LUNs
A colleague tested this previously, and it's not easily doable.
AFAIK you would have to manually remove the SCSI devices via
/sys/devices/.../remove?

Or are you aware of a simple way to remove LUNs?


    4. LVM Support for Multipath Devices
        a) Creation of LVM-PVs on Multipath Devices using the GUI/CLI
It uses the multipath devices if those are available. Even if you only
create the multipath after the LVM.
But maybe the selection list could be extended with the wwid and
multipath device? That way you would see if any multipath device is
configured.


We'd appreciate feedback if any/all of these changes or of interest and
if we can move forward with implementing them.

Regards,

Felix Drießler


[0]
https://lore.proxmox.com/pve-devel/63f8a09b-20a2-4282-a3f1-30aa7887e3c5@proxmox.com/T/#t


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

      reply	other threads:[~2025-11-19 12:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f53ca227-2275-443f-84f8-48b2785269b2.2bc2ceb6-a3a3-4c49-9566-519c7d2ab20e.bc79f8c9-009c-47a0-8987-9e43cd7308aa@emailsignatures365.codetwo.com>
2025-10-01 12:54 ` Felix Driessler - inett GmbH via pve-devel
2025-11-19 12:44   ` Mira Limbeck [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=56cf532c-b268-463b-a60b-f49c8e9cfcdb@proxmox.com \
    --to=m.limbeck@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal