HPE Nimble Storage + Proxmox VE — custom storage plugin (iSCSI, multipath)

brngates

New Member
Mar 15, 2026
5
7
3

Hi Proxmox enthusiasts!


Plain iSCSI in Proxmox is still mostly manual: you either keep creating LUNs on the SAN for every VM disk, or you present one big shared LUN and put LVM or LVM-thin on top—fewer LUNs, but shared VG pain, snapshot/migration quirks, and extra moving parts.

This plugin is for HPE Nimble: it drives the REST API so Proxmox creates each VM disk as its own Nimble volumeand handles ACLs, snapshots, resize, and (optionally) multipath for you—no parallel “array admin” workflow for every disk. Code + .deb: links below. We’ve been exercising it on a lab cluster at work and have recently moved it into light production testing on Proxmox VE 9.1.1 with Nimble.

What this plugin can do:

Live migration – move VMs between cluster nodes without storage getting in the way.

Snapshots – create, delete, and roll back disks from Proxmox; handy for backups and quick recovery.

Each VM disk is its own Nimble volume – that opens up what Nimble does best: per-disk snapshot schedules, protection policies, collections, and thin provisioning—instead of hiding everything behind one giant LUN with LVM on top.

Clones – new disks from a snapshot when you need a copy or a new VM, without manual work on the array.

Resize and rename – grow or rename disks from the Proxmox UI like a normal storage type.

Optional multipath – if you use it, paths to the SAN can stay resilient the way you’d expect in a serious setup.

Technical details

  • Storage: HPE Nimble (REST v1, default HTTPS port 5392)
  • Proxmox: 8.2+ documented minimum; 9.1.1 (lab validation, now production)
  • Cluster: install the .deb on every node; storage config syncs, the plugin must be present everywhere
Where to find it and how to install

Minimal pvesm add (the plugin can create the initiator group for this host):

Bash:
pvesm add nimble <storage_id> --address https://<nimble>:5392 \
  --username <user> --password '<password>' --content images

How to Help?

I’m open to feedback, issues, and PRs on GitHub. Field reports (Nimble OS / model, multipath on/off, cluster size) help a lot.

Hope this is useful to others running Nimble with Proxmox.
 
Last edited:
First of all, thank you for your work on this Plugin!

I've been trying this plugin out this week and do have a VM currently running on it, but I am experiencing a few issues:
  1. Snapshots without RAM can successfully be created and rolled back, however Debug Log (Level 1) would show "command '/usr/sbin/iscsiadm -m node --login' failed: exit code 15"
    • Is this intentional behaviour?
  2. Snapshots including RAM keep failing with the message "VM 105 qmp command 'savevm-start' failed - failed to open '' "
    • After this all future Snapshots attempts end with the message "VM 105 qmp command 'savevm-start' failed - VM snapshot already started". To fix this the VM needs to be restarted.
  3. I tried adding the created VM Volumes to an existing Volume Collection to apply the Protection Settings. One of these settings (I'm guessing the Synchronous Replication type) caused some more issues with the snapshots.
    • Creating another Snapshot at this point would create additional volumes named "vm-105-disk-0-<Snapshot-Title>
    • These new volumes would stay at 0 Volume Usage
    • The Nimble would send an Alarm that atleast one volume collection was out of sync, and start resyncing it
    • The Snapshot creation log in PVE would end in a Timeout message and no Snapshot was created
Does the Plugin not Support Synchronous Replication or should I expect issues in my setup?

Here's some Information about my setup:

Nimble:
Nimble Array consists of 2 Hosts
Both HF20-2T-42T-2880F
OS Version 6.1.2.800-1084673-opt
Multipath is active

Proxmox
2 Host Cluster with Witness Server
PVE 9.2.3
Additionally connected to Nimble Array using LVM over iSCSI
Plugin Connection uses the same Multipath Configuration
 
  • Like
Reactions: brngates
First of all, thank you for your work on this Plugin!

I've been trying this plugin out this week and do have a VM currently running on it, but I am experiencing a few issues:
  1. Snapshots without RAM can successfully be created and rolled back, however Debug Log (Level 1) would show "command '/usr/sbin/iscsiadm -m node --login' failed: exit code 15"
    • Is this intentional behaviour?
  2. Snapshots including RAM keep failing with the message "VM 105 qmp command 'savevm-start' failed - failed to open '' "
    • After this all future Snapshots attempts end with the message "VM 105 qmp command 'savevm-start' failed - VM snapshot already started". To fix this the VM needs to be restarted.
  3. I tried adding the created VM Volumes to an existing Volume Collection to apply the Protection Settings. One of these settings (I'm guessing the Synchronous Replication type) caused some more issues with the snapshots.
    • Creating another Snapshot at this point would create additional volumes named "vm-105-disk-0-<Snapshot-Title>
    • These new volumes would stay at 0 Volume Usage
    • The Nimble would send an Alarm that atleast one volume collection was out of sync, and start resyncing it
    • The Snapshot creation log in PVE would end in a Timeout message and no Snapshot was created
Does the Plugin not Support Synchronous Replication or should I expect issues in my setup?

Here's some Information about my setup:

Nimble:
Nimble Array consists of 2 Hosts
Both HF20-2T-42T-2880F
OS Version 6.1.2.800-1084673-opt
Multipath is active

Proxmox
2 Host Cluster with Witness Server
PVE 9.2.3
Additionally connected to Nimble Array using LVM over iSCSI
Plugin Connection uses the same Multipath Configuration
Hi LG-ITI,

Thanks for testing the plugin and for the clear report — it helps a lot.

1. iscsiadm exit code 15 in the log

That is normal in many setups (multipath, or the same Nimble array also used for LVM-iSCSI). It usually means iSCSI was already logged in. If snapshots without RAM work, you can ignore that debug message. I will investigate a way to check if the target is already logged in to possibly avoid these extra calls.

2. Snapshots with RAM

Snapshots without RAM working is what we expect today. With RAM is a known problem we are working on — sorry for the hassle.

If a RAM snapshot fails:

  • Restart the VM, then try again (or use snapshots without RAM).
  • If it keeps saying “snapshot already started”, a restart usually clears that too.
We are planning a fix for RAM snapshots. If you can, please open a GitHub issue with the task log from one failed attempt — that makes it easier to track.

3. Volume collection and synchronous replication

We have not tested synchronous replication; I did not have the extra hardware for that. So I cannot promise it works with PVE snapshots yet.

For now, I would not put plugin-managed VM disks in a volume collection that uses sync replication, especially if you also take snapshots from Proxmox. Your timeouts and extra volumes sound like a bad mix of PVE snapshots and Nimble protection — worth separating those (e.g. snapshots in PVE, replication on another collection or schedule).

If you are willing to help test sync replication with this plugin, please open an issue or discussion on GitHub with a short description of your protection setup and what went wrong. I would like to figure out what we need to support (or document) with your two-host Nimble lab.

Please use GitHub for follow-ups so we do not lose details in the forum thread:

Thanks again.
 
Why are you still using iSCSI?
The Nimble supports NVMe over TCP, after all.
It's much easier to configure and offers significantly better performance.
 
Why are you still using iSCSI?
The Nimble supports NVMe over TCP, after all.
It's much easier to configure and offers significantly better performance.
My nimbles personally only support iSCSI and FC, I think only the Alletra's support NVMe over TCP.