[TUTORIAL] Windows 2025 Cluster - disk quorum and shared disk setup on PVE

[Urbanovits]

Chapter 1: The Windows Server 2025 Storage Revolution and the PVE Dilemma​

1. What Changed in Windows Server 2025?​

In previous Windows Server versions (2016/2019/2022), the Failover Cluster validation wizard was more forgiving regarding shared storage mechanics. If a shared block device did not fully support hardware-level SCSI-3 Persistent Reservation (PR) commands, administrators could bypass the restriction using well-known registry modifications:

• The Legacy Registry Bypasses: Keys like PlumbAllDisks or GenerateFailureOnBadPRs were commonly altered to force the cluster service to accept non-compliant storage despite validation warnings.

With the release of Windows Server 2025, Microsoft fundamentally re-engineered the communication layer between the Cluster Service and the storage subsystem. To ensure strict data integrity and prevent split-brain scenarios in High Availability (HA) environments, SCSI-3 Persistent Reservation (PR) compliance is now a hard, unbypassable requirement. The cluster engine no longer permits software overrides. If a storage backend cannot natively register and defend reservation keys across all cluster nodes, the disk will fail validation and cannot be added to the cluster resources. The legacy registry workarounds are entirely obsolete.

2. Why Traditional PVE Shared Disks Fail​

Within a Proxmox VE (PVE) environment, sharing virtual disks between multiple virtual machines typically relies on two methods, both of which fail under the strict requirements of Windows Server 2025:

• VirtIO-Block / VirtIO-SCSI with 'shareable' flag: When attaching a standard .qcow2 or raw file to multiple VMs using the shareable flag, the underlying QEMU emulation layer does not pass SCSI-3 PR transparently. When a Windows cluster node attempts to write a registration key, the virtualization layer rejects the command, leading to validation failures.
• Direct ZFS Volume (zvol) Sharing: While ZFS is a highly performant file system, a raw zvol (/dev/zvol/...) shared across VMs does not inherently possess the cluster-arbitration logic required by Windows. Attempting to mount a raw block device simultaneously without an intermediate SCSI-3 PR translation layer causes metadata corruption and immediate disk lockouts.

3. The Solution: Linux LIO iSCSI Target​

To bridge the gap between PVE storage and Windows Server 2025 requirements, the implementation must utilize the Linux kernel's native storage routing subsystem: the LIO (Linux Input/Output) Target.

The LIO subsystem converts the backing ZFS zvols into fully compliant, standard iSCSI LUNs exposed over the network. Crucially, LIO handles SCSI-3 Persistent Reservation (PR) commands at the kernel level. It is fully capable of processing the registration and reservation keys sent by the Windows Failover Cluster engine, saving this metadata (APTPL - Activate Persistence Across Power Loss) directly onto the Proxmox host filesystem. This native handling fulfills the strict validation criteria of Windows Server 2025.

There is no need for either Ceph or any other iSCSI VM, because PVE handles this itself.

Installing the Linux LIO Target on Proxmox VE​

By default, Proxmox VE contains the necessary kernel modules for LIO, but the user-space management utilities and the target service framework must be installed manually via the Debian package manager.

1. Package Installation​

Run the following command from the Proxmox host shell to install the core CLI management utility and the target subsystem daemon:

 apt-get update && apt-get install -y targetcli-fb target-manager

2. Ensuring Configuration Persistence
Instead of a traditional service, LIO relies on a configuration file located at /etc/rtslib-fb-target/saveconfig.json. The targetcli utility automatically saves changes here.

To ensure that Proxmox restores this architecture automatically when the system boots, verify that the targetcli-fb systemd service tool is enabled:

 systemctl enable targetcli-fb

Chapter 2: The Proxmox VE Storage & iSCSI Target Configuration ️​

In this section, we will prepare the backing storage on Proxmox VE (PVE) using ZFS Volumes (zvols) and configure the Linux LIO iSCSI target subsystem to share them with full SCSI-3 Persistent Reservation (PR) support.

1. Creating the ZFS Volumes (zvols)​

We need two distinct block devices: one 10 GB volume for the Cluster Quorum (Disk Witness) and one larger volume for the actual shared data cluster roles.

Run the following commands on the Proxmox host terminal:

# Create the 10 GB Quorum/Witness volume
zfs create -V 10G Your_Storage_Name(change)/vm-XXX-disk-X
*change X to appropriate number

# Create the 100 GB Data volume
zfs create -V 100G Your_Storage_Name(change)/vm-XXX-disk-X

2. Configuring the Linux LIO iSCSI Target via targetcli​

The Linux kernel target subsystem (LIO) maps the raw ZFS block devices to standard iSCSI LUNs. A dual-portal configuration is established to facilitate redundant network pathways for Multipath I/O (MPIO).

Enter the targetcli interactive shell or execute the commands directly from the host shell:

 # Define the Block Backstores using the ZFS zvols
/backstores/block create name=q_disk dev=/dev/zvol/Your_SSD/vm-XXX-disk-X
/backstores/block create name=d_disk dev=/dev/zvol/Your_SSD/vm-XXX-disk-X

# Create the unique iSCSI Target IQN (example)
/iscsi create iqn.2003-01.org.linux-iscsi.pve.x8664:sn.2855395b85bb

# Navigate to the Target Portal Group (TPG) context
cd /iscsi/iqn.2003-01.org.linux-iscsi.pve.x8664:sn.2855395b85bb/tpg1/

# Map the defined backstores to explicit LUN IDs
luns/ create /backstores/block/q_disk lun=0
luns/ create /backstores/block/d_disk lun=1

# Configure Dual Portals to establish redundant network paths
portals/ delete 0.0.0.0 3260
portals/ create xxx.xxx.xxx.xxx_Your_IP1_here(change) 3260
portals/ create xxx.xxx.xxx.xxx_Your_IP1_here(change) 3260

# Adjust ACL attributes to allow cluster node registration
set attribute generate_node_acls=1
set attribute auth_attr_enforcing=0

IMPORTANT!

The two IP addresses must be added to the appropriate PVE bridge, otherwise the VM will not see it and there will be no iSCSI connection. Edit your /etc/network/interfaces and add

example:

iface vmbr1 inet static (change your bridge)
        address 10.10.10.40/24
        bridge-ports enp6s0f1(change_to_your_nic)
        bridge-stp off
        bridge-fd 0
# Storage Network - First Portal

auto vmbr1:0
iface vmbr1:0 inet static
        address 10.10.10.41/24
# Storage Network - Second Portal (Alias)

3. Critical Directory Fix for SCSI-3 PR Registrations​

The Linux kernel LIO subsystem manages SCSI-3 Persistent Reservation (PR) APTPL (Activate Persistence Across Power Loss) metadata by writing state files to a specific directory path. Windows Server 2025 enforces registration tracking immediately upon discovery. If the target directory is missing on the Proxmox host, iSCSI write commands fail, resulting in connection timeouts and a status of "The device is not ready".

To resolve this issue, create the required directory structure on the Proxmox host file system:

IMPORTANT NOTE!
Path would be different depend on your config. Check before create (or check your logs where this process want write to)

mkdir -p /etc/rtslib-fb-target/pr

The kernel recognizes the directory dynamically; no service restarts are necessary.

---

Chapter 3: Windows Server 2025 Node Network and MPIO Configuration​

1. Connecting the iSCSI Targets​

The iSCSI Initiator must be configured on both Windows Server 2025 nodes (node1 and node2). To utilize the dual portals established on the Proxmox host, connections must be explicitly bound to the dedicated storage network adapters.

Execute these steps within the Windows graphical user interface (GUI) on both nodes:

• Open the iSCSI Initiator from Administrative Tools.
• In the Discovery tab, click Discover Portal and add both Proxmox storage IP addresses (xxx.xxx.xxx.xxx_Your_IP1 and xxx.xxx.xxx.xxx_your:IP2).
• In the Targets tab, select the discovered IQN (exaple: iqn.2003-01.org.linux-iscsi.pve.x8664:sn.2855395b85bb) and click Connect.
• Enable the checkbox for Enable multi-path to ensure the operating system prepares for multiple network routes.
• Click Advancedand manually configure the underlying connection pairs:
  • Route 1: Select the first local storage NIC as the Initiator IP and target it to xxx.xxx.xxx.xxx(Your_ip1).
  • Route 2: Repeat the connection process, selecting the second local storage NIC as the Initiator IP and targeting it to xxx.xxx.xxx.xxx(Your_IP2).

2. Enabling Multipath I/O (MPIO) for Windows Server 2025​

Without explicit system-level claims, Windows treats the dual-portal paths as separate physical disks. This causes immediate drive access timeouts and SCSI-3 reservation blockages during cluster validation. Windows Server 2025 requires precise driver claims to aggregate these paths into a single logical device.

Open an Administrative PowerShell console on both nodes and execute the following commands to configure the Microsoft Device Specific Module (MSDSM):

# Enable the MSDSM to automatically claim all iSCSI devices
Enable-MSDSMAutomaticClaim -Name "iSCSI"

# Enforce the global bus-type claim specifically for the iSCSI architecture
Enable-MSDSMBusTypeClaim -BusType iSCSI

A system restart is strictly required after running these commands to commit the multipath driver changes into the Windows kernel storage stack.

Chapter 4: Disk Initialization and Cluster Quorum Provisioning​

1. Initializing and Formatting the Shared Disks via GUI​

Before the cluster can utilize the iSCSI LUNs, the drives must be initialized and formatted with a file system. This procedure must be performed on Node 1 only while Node 2 monitors the shared storage.

Execute these steps within the Windows Disk Management GUI on Node 1:

• Open Disk Management (diskmgmt.msc).
• Locate the newly attached iSCSI disks, which will display a blue information icon indicating a Reserved status enforced by the cluster architecture.
• Open Failover Cluster Manager (isclautils.msc) and navigate to Storage -> Disks.
• In the right-hand Actions pane, click Add Disk. Select both discovered disks to bring them under explicit cluster management control.
• In the central pane, select the "exaple"10 GB disk (designated for the Quorum), right-click it, and select Bring Online.
• Right-click the online 10 GB disk again and select Format.
  • Set the File System to NTFS.
  • Set the Volume Label to Quorum.
• Repeat the online and formatting process for the 100 GB disk (designated for data roles), labeling it appropriately.

2. Configuring the Disk Witness (Quorum)​

With the 10 GB volume formatted and recognized as healthy, the Failover Cluster can assign it to act as the tie-breaking vote for node majority arbitrations.

Execute these steps within the Failover Cluster Manager GUI:

• Right-click the cluster name at the top of the left navigation tree .
• Select More Actions -> Configure Cluster Quorum Settings... to launch the configuration wizard.
• Click Next on the introduction screen.
• On the Select Quorum Configuration Option screen, choose Select the quorum witness.
• On the Select Quorum Witness screen, choose Configure a disk witness.
• On the Configure Storage Witness screen, select the checkbox next to the megabyte volume corresponding to your formatted 10 GB "Quorum" disk.
• Click Next, confirm the selection on the summary page, and click Finish.

The core Summary page of the Failover Cluster Manager will update its Quorum Configuration status to Node and Disk Majority, confirming that the cluster has reached optimal high-availability redundancy.

Have fun
George