Guides:Fibre Channel and iSCSI Block Storage with ALUA Multipathing
By Steve Umbehocker, CTO, OSNexus · Updated October 7, 2026
QuantaStor presents storage volumes as block LUNs over Fibre Channel, through QLogic host bus adapters running in target mode, and over iSCSI, and it reports each path's state to the host with ALUA (Asymmetric Logical Unit Access). On a high-availability storage pool, the node that owns the pool serves a volume's active paths, and the partner node serves standby paths to the same logical unit, so host multipath software always knows which paths to use and switches over cleanly when the pool fails over. This guide explains how those path states behave through a failover, how to design and set up FC and iSCSI access, and what to configure on Linux, VMware and Windows hosts, including Hyper-V failover clusters with Cluster Shared Volumes.
Why it matters
Most virtualization and database estates still run on block storage, and most of those hosts expect two things from the array: more than one path to every LUN, and an honest answer about which of those paths are optimized. Without ALUA, a host either sends I/O down paths that cannot serve it or waits for timeouts to learn that a path is dead. With ALUA, the array tells the host which paths are active and which are standby, and the host's multipath driver (dm-multipath with scsi_dh_alua on Linux, the in-box Microsoft DSM on Windows, the native multipathing plug-in on VMware ESXi) follows those states.
Clustered hosts add a second requirement. A Windows Server Failover Cluster, Hyper-V Cluster Shared Volumes and other shared-disk clusters arbitrate ownership with SCSI-3 persistent reservations, and those reservations must stay valid when the storage itself fails over from one controller to the other. QuantaStor covers both: ALUA path states for every FC and iSCSI LUN on an HA pool, and clustered SCSI-3 persistent reservations that survive an HA failover.
How it works
Fibre Channel target ports
QuantaStor's fabric manager scans the FC transport about once a minute and creates an FC target port object for each QLogic port it finds. Any port that is target-mode capable is switched into target mode automatically unless you have explicitly set it to initiator mode, so a dedicated storage appliance needs no per-port configuration. The ports appear in the FC Ports tab of each Storage System, with State, Link State, Status and Mode columns; Link Up - F_Port in the Link State column means the port negotiated a point-to-point link to a fabric switch, which is what you want. Fibre Channel Target Port Management covers each column, target and initiator mode, LIPs and the CLI.
Zoning is your job on the switch: QuantaStor cannot configure it. Zone each host initiator WWPN with the target WWPNs on both nodes of the HA pair, so every host sees paths through both controllers.
Active and standby paths on an HA pool
Each volume on an HA pool is one logical unit with one identity, visible through the target ports of both nodes:
| Node | Device behind the LUN | ALUA state reported | What the host does |
|---|---|---|---|
| Pool owner | The volume itself | Active | Sends I/O on these paths |
| Partner node | A standby placeholder device with the same identity | Standby | Holds the paths in reserve |
The standby device advertises the same thin-provisioning support, UNMAP limits and block geometry as the volume, so a host sees one consistent logical unit no matter which node's path it probes first. That matters for hosts that cache those properties per LUN, such as Windows trim and alignment handling, VMware VAAI UNMAP and dm-multipath discard limits.
During an HA failover the old owner moves its LUNs onto standby devices rather than removing them, and the new owner switches its target group to active only once every LUN is backed by the real volume. Hosts keep the same set of paths throughout; only the states change. A volume's relative target ID also stays the same across failovers, so hosts that track LUNs by target port identity keep their mapping.
After a node restarts, its FC target ports are enabled only once every exported volume is mapped and its ALUA state is in place. When a former pool owner reboots and comes back as the partner, its ports open as soon as its standby devices are ready. Initiators therefore never log in to a port that has no LUNs or unsettled path states behind it. Deleting an HA group removes the partner node's standby devices, ALUA device groups and FC LUN maps, so hosts do not keep standby paths to a node that can no longer serve the pool.
Clustered SCSI-3 persistent reservations
With clustered reservations enabled on the HA group, both nodes share reservation state through DLM (the Linux distributed lock manager) integrated with the SCST target driver. A reservation a cluster member takes through one node is honored on the other, and it survives a failover in either direction. Volumes enter clustered reservation mode only once they are assigned to a host, so unassigned volumes use no cluster locking resources. See Clustered SCSI-3 Persistent Reservations.
Design and sizing
- Pool layout. Put block volumes on a storage pool in an HA failover group (Create Storage Pool High-Availability Group). Only HA pools have a partner node to serve standby paths.
- Paths. Give each host at least two initiator ports, each zoned (FC) or routed (iSCSI) to both nodes. Two host ports and two target ports per node gives four paths per LUN to each node: active through the owner, standby through the partner.
- Port roles. Keep the appliance's FC ports in target mode. Use dual mode (
qs-util enabledualmode, then a reboot) only when the appliance must also consume FC storage from another array; Dual-mode FC configuration describes the procedure. - iSCSI addressing. Point iSCSI discovery at an HA virtual interface, which moves with the pool (High-availability VIF Management).
- Block size. Choose the volume block size at creation time; it cannot be changed later. For VMware VMFS datastores use 8K to 64K, with 64K recommended for general virtualization workloads and 8K worth considering for databases (VMware Configuration, Storage Volumes).
- Clustered hosts. Enable clustered SCSI-3 reservations on any HA group that serves Hyper-V CSVs, WSFC disks or other shared-disk clusters.
Setting it up
- Check the FC ports. In Storage Management, select a Storage System and open the FC Ports tab. Every port you have cabled should show Mode
Target, StatusOnlineand aLink Up - F_Portlink state. Ideally you'll see the ports in dual Target+Initiator mode but if they are in just Initiator mode they'll need to be transitioned to Target mode before they can be used to present Storage Volumes as FC LUNs from QuantaStor.
- Create the HA group for the pool, choose the primary and secondary systems, and set Clustered SCSI3-PR Reservations if the pool will serve a host cluster. Enabling or disabling it later from Modify Group brings every device of the pool into line on both nodes (Modify Storage Pool High-Availability Group).
- Register each host. In Hosts & Portal Groups, choose Add, set the operating system type, and enter the host's iSCSI IQN or FC WWPN. For FC, Select Initiator lets you pick the WWPN from a list instead of typing it. Group the members of a host cluster in a host group so they get identical assignments (Hosts and Host Groups).
- Assign volumes to the host or host group. An assignment maps the volume as a LUN through the target ports of both nodes, active on the owner and standby on the partner.
- Connect the hosts.
- Linux: set up the iSCSI initiator (ISCSI Initiator Setup) or rescan the FC HBAs, then configure dm-multipath with ALUA path grouping (Multipath IO Configuration).
- VMware ESXi: add the software iSCSI adapter, add the HA virtual interface address under Dynamic Discovery, and rescan storage. The volume appears as an "OSNEXUS iSCSI Disk"; match it to the EUI shown in the volume's properties in QuantaStor, then create the VMFS datastore.
- Windows and Hyper-V: enable MPIO with the in-box Microsoft DSM, claim the QuantaStor disks, bring them online on one node, and add them to the failover cluster as Cluster Shared Volumes.
Operating and testing
Test the paths before production. On a Linux host, multipath -ll should show two path groups per LUN: one whose paths go to the pool owner as active, and one whose paths go to the partner as standby (Windows MPIO and the ESXi path list show the same split). Then trigger a manual failover from Storage Pool HA Groups with Manual Failover (Storage Pool Ha Failover Group Failover) and watch the two groups swap states while I/O continues.
For clustered hosts, test failover under real load. QuantaStor has been validated with two-host Windows Server 2022 Hyper-V failover clusters running Cluster Shared Volumes with SCSI-3 persistent reservations on FC HA pools, through manual and automatic failovers, live migration during a failover, and host drain and reboot.
If a LUN does not appear on a host, check in this order: zoning on the switch, the FC port's Link State, the host's initiator entry in QuantaStor, and the volume assignment. Issuing a LIP from the FC Ports tab forces the fabric to rediscover the ports.
FAQ
Which software-defined storage platforms support Fibre Channel and iSCSI with ALUA multipathing?
QuantaStor does. It presents volumes over FC through QLogic HBAs in target mode and over iSCSI, and it reports active and standby ALUA path states for every LUN on an HA storage pool. Hosts use their standard multipath drivers (dm-multipath, Windows MPIO with the Microsoft DSM, VMware native multipathing) with no vendor plug-in.
Any FC or iSCSI LUN that supports SCSI-3 persistent reservations and keeps them through a controller failover. On QuantaStor that is a volume on an HA pool whose HA group has clustered SCSI-3 reservations enabled. Two-host Windows Server 2022 Hyper-V clusters with CSVs have been validated on FC HA pools, including live migration during a failover.
What happens to host paths during an HA failover?
Nothing is removed. The old owner's paths change from active to standby, the new owner's paths change from standby to active once every LUN is backed by the volume, and the host's multipath driver moves I/O accordingly. Persistent reservations held by clustered hosts stay in place.
Do I need to enable target mode on each FC port?
No. Any target-capable QLogic port without an explicit initiator-mode setting is put into target mode automatically within about a minute. Use the Enable FC Initiator Mode action only for ports you want to use as initiators.
Can I change a volume's block size after creating it?
No. The block size is fixed when the volume is created. To change it, create a new volume with the right size and move the data, for example by live-migrating VMs to a new VMware datastore. You can grow the size of the Storage Volume at any time but the underlying block size is fixed at creation, 64K by default.
Part of the QuantaStor Guides series. For reference documentation, see the QuantaStor documentation.