Dedicated block storage built around fabric discipline
Fibre Channel remains relevant where predictable storage connectivity, operational separation and mature host multipathing matter more than reusing the general-purpose IP network.
The fabric connects initiator ports to target ports—not users to folders
Fibre Channel transports block I/O. The server discovers presented LUNs and treats them as storage devices; access is controlled by the fabric and by the storage system.
HBA and WWPN
The host bus adapter provides one or more initiator ports. Each port has a World Wide Port Name used for zoning and storage access control.
Fabric and zoning
FC switches establish the fabric. Zoning limits which initiator and target ports are allowed to communicate.
Target port
The storage port operates as a target and presents one or more logical units through the selected fabric paths.
LUN and masking
The LUN is the block device. Storage-side host and group rules determine which authorised WWPNs may see it.
Zoning and LUN masking solve different problems. Zoning controls fabric communication; masking controls storage presentation. A production design normally uses both.
Fibre Channel is one block-storage transport—not a universal default
The right choice depends on the installed skills, host support, failure model and whether a dedicated SAN is an advantage or an unnecessary second network.
| Transport | Command model | Network | Operational character | Typical fit |
|---|---|---|---|---|
| Fibre Channel | SCSI over FCP | Dedicated FC fabric | Specialised, mature and physically separated | Established enterprise SAN and tier-one virtualisation |
| NVMe/FC | Native NVMe | Fibre Channel fabric | Retains the FC fabric while changing the storage command model | Qualified modern FC environments |
| iSCSI | SCSI over TCP/IP | Routable Ethernet | Broad compatibility using familiar IP operations | Mixed hosts and existing IP SANs |
| NVMe/TCP | Native NVMe over TCP | Routable Ethernet | Modern command model without a dedicated FC fabric | New shared block deployments on Ethernet |
Multipathing cannot compensate for two paths through one failure domain
A robust design normally uses separate HBA ports, separate switches and separate target ports. Host multipathing then combines the paths into one logical device and selects or fails over between them according to the supported policy.
Fibre Channel is strongest where shared block storage is already an operational discipline
VMware
VMFS datastores
Multiple ESXi hosts can use coordinated VMFS storage when zoning, LUN presentation and path visibility are consistent across the cluster.
Microsoft
Hyper-V
Windows Server hosts can use MPIO for resilient FC access. Virtual Fibre Channel additionally uses NPIV for selected guest-level SAN scenarios.
euroNAS
eEVOS
eEVOS can consume compatible shared FC storage for virtual machine workloads while retaining its integrated Backup & Disaster Recovery functions.
Linux
KVM and applications
DM Multipath can combine independent FC paths for virtualisation hosts, databases and other applications that require a remote block device.
Data services
Databases
Dedicated SAN connectivity can suit latency-sensitive database and transactional workloads when the complete system is correctly sized and tested.
Operations
Existing SAN estates
FC can remain the lower-risk choice when the organisation already has compatible fabrics, monitoring, procedures and experienced administrators.
A dedicated network still requires deliberate security boundaries
Physical separation does not prevent accidental presentation, stale zoning or an incorrect WWPN assignment.
Switch zoning
Limit initiator-to-target communication and keep zone membership clear, minimal and documented.
Storage masking
Map each LUN only to the required FC hosts or host groups by their initiator WWPNs.
Change control
Coordinate HBA replacement, zoning, LUN expansion and target failover across server, fabric and storage teams.
Pool ownership and the FC target must move as one service chain
In a euroNAS HA Cluster using shared ZFS storage, the target is dependent on the node that safely owns the pool. The system is designed to prevent both nodes from opening the same pool independently.
Safety takes precedence over blind automation. If exclusive ownership cannot be confirmed—for example after an isolated boot—the pool remains offline for administrative review even when automatic takeover was selected.
Choose the storage role before choosing the product
The platforms are not interchangeable. Fibre Channel target hardware and the required availability model should be qualified as part of the architecture.
| Platform | FC role | Availability model | Important limitation or decision | Typical fit |
|---|---|---|---|---|
| euroNAS Premium | FC target | Standalone storage server | Requires a qualified target-mode FC adapter; no automatic storage-node failover | Single enterprise storage appliance |
| euroNAS HA Cluster | Highly available FC target | Shared ZFS pool and dependent target failover between two controllers | Safe pool ownership, node isolation and client multipathing must be designed together | Dual-controller shared block storage |
| eEKAS | FC initiator / storage consumer | Scale-out storage system using external FC targets | eEKAS does not provide an FC target; it connects to compatible external FC storage through its initiator | Use external FC LUNs within an eEKAS storage architecture |
| eEVOS | FC initiator / storage consumer | Virtualisation host or cluster using external shared storage | Does not replace the external FC target or SAN fabric | VM workloads with integrated Backup & Disaster Recovery |
euroNAS Premium
Present qualified FC LUNs alongside other file and block services on enterprise hardware.
HA Cluster
Move a shared ZFS pool and its dependent FC target together while protecting exclusive ownership.
eEKAS
Connect compatible external FC targets through the integrated initiator and use their LUNs within the eEKAS storage architecture.
eEVOS
Use compatible shared FC storage for VMs while keeping Backup & Disaster Recovery inside eEVOS.
Adapter mode is an architectural choice, not a checkbox to try in production
Current euroNAS FC target workflows recognise selected QLogic and later QLogic/Cavium controller families, including OEM-labelled variants. Driver recognition is not the same as qualification of every adapter, firmware, optic and switch combination.
Qualification checklist
Exact adapter model and PCI identity
Matching firmware and adapter generations
Supported target-mode driver
Optics, cabling and switch compatibility
Identical design on both HA nodes
Host HBA and multipathing support
Tested zoning, masking and failover procedure
Configure target mode, status and WWPN access without routine command-line work
These current euroNAS examples show the operational workflow. They are configuration illustrations, not performance guarantees or a blanket hardware compatibility statement.
Coordinate FC target modeThe GUI identifies affected nodes, explains the initiator-mode impact and records the reboot requirement.
Verify target ownership and fabric stateThe overview shows the LUN, backing pool, active node, running state and link status.
Restrict LUN access by WWPNHosts and groups separate storage-side presentation from switch zoning.
Stop when ownership is uncertainThe warning identifies the last owner and requires deliberate review before a forced import.