Enterprise iSCSI support in PVE

[ogrimia]

When will iSCSI be ready for use in PVE? Are there any plans for iSCSI and networking development in PVE?


I see that PVE already has a 9.x release, and ISCSI is the biggest pain to describe it gently. I am the only person in the company who understands the iSCSI SAN concept with multi-pathing over separate networks, failover logic and flow, portals/targets and initiators, the process of adding and removing paths and new LUNs, and growing existing volumes. I want to cry when I see that PVE GUI for iSCSI management has not existed for decades compared to the first thing that was really mature in XEN and VMware, right after networking. The latter is still in the kindergarten stage GUI-wise. (Try installing PVE into a failover bond of four interfaces over a specific VLAN using the GUI, or just over a VLAN alone) In ESXi installation TUI, you just select the bunch of NICs with the spacebar, set the VLAN ID and IP/GW, and your ESXi is fully manageable from the GUI right away. You never need to touch the console (unless you're doing something unusual).

The iSCSI workflow in PVE involves opening multiple Linux shells (one for each host) within a single keyboard broadcast domain. Otherwise, you would have to perform this task manually on each host or develop your own automation scripts (do not forget this is enterprise production, one nasty typo, and the whole cluster can lay down). Next, you need to locate the iSCSI iqn, as it is not possible to find it via the GUI. Then, add each iqn to the SAN access list and share the LUN from the SAN. Return to the PVE GUI, add the iSCSI portal at the DataCenter->Storage and then return back to your broadcast shell. Now, carefully log in to each of the advertised portals individually to create a multi-path device, ensuring you add the specific WWID to the multipath whitelist. After restarting multipath -r, you can go back to the GUI one more time and finish creating the LVM over iSCSI block via the DataCenter > Storage GUI again. This process of repeatedly switching between the shell and GUI is like doing push-ups and scissor-jacks. Now, as another simple exercise, try growing the volume and count how many times you have to reach to the hosts Linux shell.

Just so you know, my 'smartass' friend: I'm not complaining about the free product. Our company is paying for licences for every single Proxmox server in our infrastructure, as well as for support. OK, not for all deployments – there are a bunch of small non-production or semi-production cases, such as proofs of concept or cruise ship deployments on a single board server with three VMs.

 

[Cutthroat]

I agree, iSCSI configuration is way over complicated in PVE. I have had to create step by step instructions for myself just to make sure I don't forget anything and do things in the right sequence. I did see in the roadmap though there is a mention of trying to improve this process.

• Improve multipath integration and setup experience for Fibre Channel and iSCSI deployments.

So hopefully we see the fruits of this sooner than later.

 

[LnxBil]

I can understand your frustration and I can see that this could be improved. Although, the multipath configuration itself is very vendor-specific and every vendor needs its own defaults, therefore editing the multipath.conf manually is often required, so it cannot be done easily via the UI, at least without providing proper error handling.

I've setup a lot of setups with FC and iSCSI MP in PVE and RHEL, so I just know the manual way. It's not that complicated, just create the multipath config on one host, copy to others and you're fine but can be errorprone if you're completely new to this. In the end, we switched from LVM-based configuration to proper storage integration, where you don't need the TUI, just UI and setup the storage once and don't have to fiddle around with all the complication. Yet, you will need proper storage support for that.

e.g. ZFS-over-iSCSI is one of those technologies, but AFAIK, there is still no proper MP support. Please correct me if I'm wrong here.

You will have a better setup with NVMe-over-fabrics, as it already integrates multipath.

 

[alexskysilk]

When will iSCSI be ready for use in PVE?

It has been ready for years. A high-friction CLI/UX workflow is not the same thing as a system being "unusable" or "not production-grade." Thousands of enterprise nodes run multipath iSCSI in production every day—it just requires Linux systems engineering rather than clicking through a guided wizard.

I see that PVE already has a 9.x release, and ISCSI is the biggest pain to describe it gently.

Having a poor UX # not ready for use.

I am the only person in the company who understands the iSCSI SAN concept with multi-pathing over separate networks, failover logic and flow, portals/targets and initiators, the process of adding and removing paths and new LUNs, and growing existing volumes.

That bus factor is your primary operational risk, not the PVE GUI. I get the desire for a slick UI so you can delegate LUN provisioning and multipathing to tier-1 staff without sweating every typo. But a simple UI can also create a false sense of security for junior admins who don't understand target portals, path failover, or SCSI rescans. The real fix here is automation and documentation for your team, not relying on a hypervisor GUI to guardrail complex SAN logic.

I want to cry when I see that PVE GUI for iSCSI management has not existed for decades compared to the first thing that was really mature in XEN and VMware, right after networking.

This comes down to architecture and community demand. Proxmox explicitly prioritized Ceph as its native, deeply-integrated software-defined storage solution. Because Ceph provides native high availability, self-healing, and seamless UI integration across the cluster, that is where PVE developers invest their GUI bandwidth.

Standard iSCSI + DM-Multipath relies heavily on underlying Debian Linux subsystems (multipathd, open-iscsi, lvm2). Proxmox intentionally leaves standard Linux storage stack configuration to standard Linux administration tools rather than building a heavy, abstraction layer over standard Debian config files that could break enterprise custom setups.

Just so you know, my 'smartass' friend: I'm not complaining about the free product. Our company is paying for licences for every single Proxmox server in our infrastructure, as well as for support. OK, not for all deployments – there are a bunch of small non-production or semi-production cases, such as proofs of concept or cruise ship deployments on a single board server with three VMs.

Fair point, and as a paying customer, you have every right to submit feature requests and feedback to the Proxmox team. But architecturally, PVE isn't trying to be a 1:1 clone of vCenter or XenCenter.

Where does that leave you today? Realistically, with three options:

1. Automate the toil: Stop manual multi-shell execution ("push-ups and scissor-jacks"). Write Ansible roles or shell scripts to automate initiator node setup, multipath whitelist updates, IQN registration, and target rescans across hosts.
2. Align with the ecosystem: Shift storage strategy toward native Ceph or block/file protocols that integrate better with PVE's UI out of the box.
3. Accept the status quo: Continue relying on underlying Debian tooling to maintain the SAN infrastructure manually.

The beauty (and occasional curse) of Proxmox is that it doesn't hide the underlying Linux OS under a proprietary abstraction layer. You get standard Linux flexibility, but that means you occasionally have to use standard Linux tools to manage it.