Shared VM storage for a Proxmox cluster from an Unraid iSCSI target

Unraid makes a decent iSCSI target for a homelab, and Proxmox has supported LVM over iSCSI as shared storage for years. I assumed that meant there’d be a straightforward how-to for connecting the two. There isn’t, or at least I couldn’t find it. What I found was the Unraid plugin’s own docs, which stop at “the target is up”, and the Proxmox storage docs, which describe each storage type in isolation and assume you already know how they stack. The bit in between, where you take a target that’s exporting LUNs and turn it into something both Proxmox nodes can create VM disks on, I had to piece together from forum threads and trial and error.

So this is the page I wanted to find. It goes from three machines with nothing on them to a working shared storage, in order, with the commands that ran. The Unraid half is quick. The Proxmox half has a few pieces, a cluster, an iSCSI storage entry, a volume group, and an LVM storage entry, and each depends on the one before, so the sequence matters.

The starting point: a new Unraid install with an NVMe pool and a SATA pool, and two Proxmox nodes straight off the installer ISO.

How the pieces fit

Two design points shape everything below.

The nodes have to be in a Proxmox cluster. Shared block storage means two hosts writing to the same disk. Proxmox keeps that safe with a cluster-wide lock around LVM metadata changes, and it only exists inside a cluster. The cluster also gives you one storage configuration for all nodes, so the storage steps are done once.

The LUNs carry LVM, not a filesystem. iSCSI presents each host with a raw block device. Rather than formatting it, Proxmox creates one logical volume per VM disk inside a shared volume group. Each VM touches only its own volume. This is thick-provisioned raw storage, which is simple and fast; VM snapshots aren’t available on it by default, though Proxmox 9 has an option for qcow2-style snapshots on LVM if you want them.

Part 1: Unraid

Install the iSCSI GUI plugin from Apps. It wraps the Linux kernel’s LIO target and the targetcli tool, and adds an iSCSI section under Settings. Also enable SSH under Settings, Management Access; Unraid ships with it off, and the shell is the quickest way to check the target’s state.

In the iSCSI settings:

1. Create a fileio backstore for each LUN. This is a large sparse file on one of your pools. Choose a pool that stays spun up, and leave write-thru enabled so a VM disk stays consistent if Unraid loses power.
2. Create a target. Unraid generates an IQN such as iqn.2003-01.org.linux-iscsi.tower.x8664:sn.87c596b3eb59. You’ll paste this into Proxmox later.
3. Add each backstore to the target as a LUN.

Allow the Proxmox initiators

LIO controls access by initiator name. Each Proxmox node has one in /etc/iscsi/initiatorname.iscsi:

# on each proxmox node
cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1993-08.org.debian:01:2af56b614e43    # proxmox
InitiatorName=iqn.1993-08.org.debian:01:3b3d2dc6323     # pve-02

Add one ACL per node to the target. The plugin’s Initiators page can do this, or from the Unraid shell:

# on unraid
T=/iscsi/iqn.2003-01.org.linux-iscsi.tower.x8664:sn.87c596b3eb59/tpg1
targetcli $T/acls create iqn.1993-08.org.debian:01:2af56b614e43
targetcli $T/acls create iqn.1993-08.org.debian:01:3b3d2dc6323
targetcli saveconfig

Each create maps every existing LUN to the new initiator, and LUNs added later are mapped automatically. saveconfig persists the configuration to the boot flash. targetcli ls should now show the target with two ACLs, each carrying both LUNs.

That’s the Unraid side done. Until the ACLs exist, Proxmox can discover the target but every login is refused with authorization failure; once they exist, logins just work.

Part 2: The Proxmox cluster

With two fresh installs, either node can create the cluster and the other joins it. A node can only join while it has no VMs or containers, because joining replaces its /etc/pve with the cluster’s copy, so this is the right moment to do it. A few checks on both nodes first:

# on both nodes
hostname -i            # the node's real LAN IP, not 127.0.1.1
cat /etc/hosts         # hostname maps to that IP
timedatectl            # "System clock synchronized: yes"

Create the cluster on node 1:

# on proxmox (node 1)
pvecm create minirack
pvecm status           # one member, "Quorate: Yes"

Join from node 2. The interactive form is pvecm add 192.168.35.107, which asks for node 1’s root password. If you’d rather use SSH keys, append node 2’s /root/.ssh/id_rsa.pub to node 1’s authorized_keys and pass --use_ssh:

# on pve-02 (node 2)
ssh-keyscan -t rsa,ed25519 192.168.35.107 >> /root/.ssh/known_hosts
pvecm add 192.168.35.107 --use_ssh
successfully added node 'pve-02' to cluster.

pvecm status on either node now lists both members with expected votes 2.

Part 3: Tying the storage together on Proxmox

From here everything is done once, on any node. The storage configuration is cluster-wide, so both nodes pick it up.

Add the iSCSI storage

This entry is the transport. It tells every node to log in to the target and keep the session up.

# on any node
pvesm add iscsi MinirackUnraid \
  --portal 192.168.35.2 \
  --target iqn.2003-01.org.linux-iscsi.tower.x8664:sn.87c596b3eb59 \
  --content none

content none is intentional. VM disks won’t live directly on the LUNs; they’ll live in the LVM layer created next. In the web UI this is Datacenter, Storage, Add, iSCSI, with “Use LUNs directly” left unchecked.

Confirm both nodes are logged in and see the LUNs:

# on both nodes
pvesm status                    # MinirackUnraid: active
iscsiadm -m session             # one session to 192.168.35.2:3260
pvesm list MinirackUnraid
Volid                                                       Format  Type            Size
MinirackUnraid:0.0.0.scsi-360014054dab8741b0d64944ad4ad53d2 raw     images 1717986918400
MinirackUnraid:0.0.1.scsi-36001405e4ff3ddf8641428cb3a53a16a raw     images 1610612736000

Keep those volume IDs handy. The scsi-3600… portion is each LUN’s WWN, which is the same on every node. The device also appears under /dev/disk/by-id/ with that name, which is what you’ll use for the LVM commands. Plain /dev/sdX letters differ between nodes and can change on reboot.

Create a volume group on each LUN

One physical volume and one volume group per LUN, on one node only. LVM stores its metadata on the disk, so the other node sees the groups as soon as it rescans.

# on one node only
pvcreate /dev/disk/by-id/scsi-360014054dab8741b0d64944ad4ad53d2
vgcreate unraid_nvme /dev/disk/by-id/scsi-360014054dab8741b0d64944ad4ad53d2

pvcreate /dev/disk/by-id/scsi-36001405e4ff3ddf8641428cb3a53a16a
vgcreate unraid_sata /dev/disk/by-id/scsi-36001405e4ff3ddf8641428cb3a53a16a

On new backstores the LUNs are blank. If you’re reusing ones that have been used before, wipefs -n on the device first shows any existing signatures.

Add the volume groups as shared LVM storage

This is the entry the VMs actually use.

# on any node
pvesm add lvm unraid-nvme --vgname unraid_nvme \
  --base MinirackUnraid:0.0.0.scsi-360014054dab8741b0d64944ad4ad53d2 \
  --shared 1 --content images,rootdir

pvesm add lvm unraid-sata --vgname unraid_sata \
  --base MinirackUnraid:0.0.1.scsi-36001405e4ff3ddf8641428cb3a53a16a \
  --shared 1 --content images,rootdir

1. —base links the volume group to the iSCSI volume it sits on, so at boot Proxmox brings up the iSCSI session before it activates the LVM storage.
2. —shared 1 marks the storage as available on every node. This is what lets a VM migrate between nodes without its disk being copied.
3. —content images,rootdir allows both VM disks and container root filesystems.

In the web UI the equivalent is Datacenter, Storage, Add, LVM, with “Existing volume groups” as the base storage, the iSCSI storage and LUN chosen from the dropdowns, and the Shared box ticked. On the other node, pvscan --cache then vgs shows the new groups, and pvesm status shows both storages active.

Part 4: Confirming it works

Create a small volume on one node, list it from the other, then remove it.

# on proxmox (node 1)
pvesm alloc unraid-nvme 999 vm-999-disk-0 1G
Logical volume "vm-999-disk-0" created.

# on pve-02 (node 2)
pvesm list unraid-nvme
unraid-nvme:vm-999-disk-0   raw   images   1073741824   999
lvs unraid_nvme
vm-999-disk-0   unraid_nvme   -wi-------   1.00g

# on proxmox (node 1)
pvesm free unraid-nvme:vm-999-disk-0

A volume created on one node is immediately visible on the other, with no rescan or sync step. From here, both unraid-nvme and unraid-sata appear as storage choices when creating a VM on either node, and a VM whose disks live there can be migrated between nodes.

The resulting configuration

This is what /etc/pve/storage.cfg gained, shared across the cluster:

iscsi: MinirackUnraid
	portal 192.168.35.2
	target iqn.2003-01.org.linux-iscsi.tower.x8664:sn.87c596b3eb59
	content none

lvm: unraid-nvme
	vgname unraid_nvme
	base MinirackUnraid:0.0.0.scsi-360014054dab8741b0d64944ad4ad53d2
	content images,rootdir
	shared 1

lvm: unraid-sata
	vgname unraid_sata
	base MinirackUnraid:0.0.1.scsi-36001405e4ff3ddf8641428cb3a53a16a
	content rootdir,images
	shared 1

Checking on things later

Adding another LUN later is the same sequence in miniature: create the backstore and LUN on Unraid, where the existing ACLs pick it up automatically, then pvcreate, vgcreate, and pvesm add lvm with the new volume ID as its base.