From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 2FE821FF0ED for ; Fri, 31 Jul 2026 12:22:02 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 8ACF62150C; Fri, 31 Jul 2026 12:22:01 +0200 (CEST) From: Dietmar Maurer To: pve-devel@lists.proxmox.com Subject: [RFC pve-storage/proxmox-widget-toolkit/pve-manager 00/27] add guided remote storage setup and SAN visibility Date: Fri, 31 Jul 2026 12:21:29 +0200 Message-ID: <20260731102156.3947857-1-dietmar@proxmox.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 1 AWL -0.875 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) KAM_LAZY_DOMAIN_SECURITY 1 Sending domain does not have any anti-forgery methods RDNS_NONE 1.274 Delivered to internal network by a host with no rDNS SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_NONE 0.001 SPF: sender does not publish an SPF Record Message-ID-Hash: SURASUSBRB6HZQILNORK3YP6Q7VQBJH6 X-Message-ID-Hash: SURASUSBRB6HZQILNORK3YP6Q7VQBJH6 X-MailFrom: dietmar@zilli.proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Adding remote storage currently starts with selecting a storage plugin from the Add menu. The type-specific dialogs then assume that the administrator already knows the Proxmox VE storage model and how the selected backend maps to it. This series adds a question-driven remote storage wizard. It first asks which kind of storage to add, then separates connection, resource selection, and common storage settings into focused steps. The existing type-specific Add entries stay available for administrators who prefer the direct workflow. The wizard supports NFS, SMB/CIFS, iSCSI, Fibre Channel shared LVM, and ZFS over iSCSI. The iSCSI shared LVM flow creates the connection storage before selecting a logical unit number (LUN) and creating the LVM storage. The Fibre Channel flow can initialize an unused SAN LUN or reuse an existing volume group. A dedicated NVMe over Fabrics wizard flow is not part of this RFC and will be added in a follow-up. The SAN view already reports existing NVMe-FC devices and native NVMe multipath state. Multi-step submissions keep completed steps when a later request fails. The wizard reports what it already created and how to finish the setup. It does not try to roll back storage or volume groups automatically, because doing so after a partial setup can be more destructive than leaving the completed resource in place. Device safety ------------- Generic disk selectors currently also see remotely attached devices. This makes it too easy to accidentally select a shared LUN for local storage. The storage API now hides transports that unambiguously denote remote attachment by default. Specialized callers can request them with the new include-remote parameter; the widget-toolkit patch exposes the corresponding includeRemoteDisks option. This transport check is deliberately a guard, not proof that a device is local or shared. It can diverge from that property in these cases: - An exclusively assigned FC, FCoE, iSCSI, or NVMe fabrics LUN is safe for local use but is hidden by default. Explicit opt-in handles this false positive. - SAS and missing or unknown transport information cannot distinguish a local disk from a shared attachment. They therefore remain visible to generic disk callers. - The Fibre Channel wizard offers only FC and NVMe-FC devices by default. Ambiguous SAS devices require enabling the local/unknown transport list. FCoE and software-managed initiator transports stay excluded. The SAN scan combines disk usage, multipath maps, LVM volume groups, configured storage entries, and iSCSI sessions. It rechecks an unused device under the disk lock before creating a volume group. It scans one selected node, however, and cannot prove that the same LUN is visible on every node selected for the shared storage. This is intentional: the wizard calls out the visibility requirement and leaves its verification to the administrator, like the existing shared storage workflows. SAN visibility -------------- The new node view lists SAN LUNs separately from local disks and shows transport, usage, storage ownership, and multipath health. It reports path state from multipathd and native NVMe multipath on a best-effort basis. The same view shows the iSCSI targets and sessions known to the node. It exposes the initiator identity, connection state, negotiated session parameters, rescan, logout, and stale node-record cleanup. The storage plugin remains responsible for session login and activation. Questions for this RFC ---------------------- 1. Is a guided workflow next to the existing expert dialogs the right UI boundary? 2. Is default filtering with explicit remote-device opt-in an acceptable safety model given the transport predicate limitations above? 3. Does the node SAN view provide the right boundary for LUN, multipath, and iSCSI initiator observability? Series order and dependencies ----------------------------- Patches 01-14 add the pve-storage APIs and disk handling. Patch 15 adds the widget-toolkit opt-in. Patches 16-27 add the pve-manager wizard and node views. Apply them in that order. pve-storage (01-14): diskmanage: collect disk transport type from lsblk diskmanage: add helper to list multipath devices diskmanage: qualify NVMe over fabrics transport disks: list: add include-remote parameter diskmanage: include iSCSI session devices in disk enumeration diskmanage: link multipath member disks to their map device iscsi: factor out session device map from device list api: scan: add san-luns method listing SAN LUN candidates disks: lvm: allow creating volume groups on multipath devices diskmanage: add helper querying multipath path state diskmanage: add helper querying NVMe native multipath path state api: scan: san-luns: report path state iscsi plugin: list sessions of all transports and capture transport api: add node-level iSCSI initiator target and session API proxmox-widget-toolkit (15): disk selectors: allow opting into remote devices pve-manager (16-27): ui: storage: allow switching the scan node of NFS/CIFS scan combos ui: storage: add guided remote storage wizard with NFS support ui: storage wizard: add SMB/CIFS support ui: storage wizard: add iSCSI support ui: storage wizard: add FC-attached SAN (shared LVM) support ui: storage wizard: add ZFS over iSCSI support ui: dc: storage: add remote storage wizard entry to the add menu ui: node: add SAN LUNs panel ui: san luns: show multipath path state api: nodes: add iSCSI initiator API endpoint pvenode: add iscsi commands ui: san luns: show iSCSI targets and sessions Diffstat -------- pve-storage: 97 files changed, 2157 insertions(+), 52 deletions(-) proxmox-widget-toolkit: 2 files changed, 16 insertions(+) pve-manager: 17 files changed, 2447 insertions(+), 1 deletion(-) -- 2.47.3