Fibre Channel Target Port Management

Revision as of 06:06, 5 September 2026 by Qadmin (talk | contribs) (Rework the FC assignment section to lead with the web interface and put the CLI after it, per the Administrator Guide convention. Adds the three numbered WUI steps with verified breadcrumbs - create the host with its FC WWPN, assign the volume, rescan on the client - including the Select Initiator picker and why it is empty in target-only mode. The CLI equivalents follow as a note, and the ALUA and multipath material is unchanged)

QuantaStor presents storage volumes as LUNs over Fibre Channel through the FC target ports on its QLogic host bus adapters. This page covers how those ports are discovered and read, how to switch a port between target and initiator mode, how initiators on the fabric appear as FC remote ports, and how a volume assignment reaches an FC client.

Section Purpose
How QuantaStor discovers FC target ports Where port objects come from, and why target mode is on by default
Where FC ports appear in the interface The FC Ports tab and the two grids on it
Reading port state, mode, speed and topology State, Link State, Status, Mode -- and the one value QuantaStor does not report
Target mode and initiator mode Enabling and disabling a port, and what happens to its LUNs
FC remote ports Initiators discovered on the fabric, and the mode they require
Issuing a LIP Forcing rediscovery, and when that is the right tool
Zoning is a prerequisite What you must configure on the switch, because QuantaStor cannot
Assigning a storage volume over FC What an assignment programs, and what the client sees
Troubleshooting A LUN that does not appear, a refused disable, poor throughput
CLI reference The seven FC commands

How QuantaStor discovers FC target ports

QuantaStor's fabric manager scans the Linux FC transport roughly once a minute and creates one FC target port object for every port it finds, reading the model, firmware and driver versions, PCI slot information, WWPN, WWNN, link state and fabric WWN from the adapter. You do not add, remove or configure FC ports -- they appear when the adapter is installed and the driver loads, and each port's object identity follows its physical WWPN.

Target mode is the mode QuantaStor puts a port into, not one you have to select. On every discovery pass, any port that is target-mode capable and does not carry an explicit initiator-mode marker is switched into target mode; when that happens outside of service startup, QuantaStor raises an alert saying so. The practical consequence is that a port disabled outside QuantaStor -- by writing to the driver's sysfs interface directly, for instance -- is turned back on within a minute. Use Enable FC Initiator Mode instead, which records the choice so it sticks.

Target mode capability comes from the SCST QLogic target driver, which exposes a control directory per port at /sys/kernel/scst_tgt/targets/qla2x00t/<WWPN>/. A port with no entry there is listed by QuantaStor but cannot be switched into target mode, and the enable operation fails with a message naming the missing path.

Where FC ports appear in the interface

 
The FC Ports tab, grouped by Storage System. The four ports on the upper appliance are in Target mode; the four on the lower one are in Target + Initiator mode.
Navigation: Storage Management → Storage Systems (section) → select a Storage System → FC Ports (tab)

The FC Ports tab carries two grids. The upper one lists FC target ports, grouped by Storage System; the lower one lists FC remote ports. Select the grid node to see every port in the grid, or a single Storage System to scope both grids to that appliance.

The target port grid shows Name, Model, State, Link State, Status, Mode, Port WWN and Storage System WWN. Name and Port WWN both render the WWPN in the colon-separated form the fabric uses, such as 50:01:43:80:18:6a:25:68; Storage System WWN is the adapter's node WWN (WWNN), which for a QLogic port is normally the WWPN plus one. Two further columns, State and Description, are hidden by default and can be turned on from the column menu -- Description carries the adapter's own product string, for example HPE SN1600Q 32Gb 2p FC HBA.

FC target ports also appear as children of their Storage System in the left tree, and in the FC Portals tab of the Portal Group dialogs.

For the full field list on one port, open the docked Properties panel from the strip on the far right edge, or run qs fcp-get --port=<WWPN>. Both add Firmware Version, Driver Version, PCI Info, Fabric WWN, Active Port WWN, Active Node WWN, the sysfs path and the device number.

Reading port state, mode, speed and topology

Four columns describe a port's health, and they mean different things:

Column Source Reading it
State QuantaStor's own object state Normal in ordinary operation. QuantaStor sets it to Offline with the detail FC Port is reporting 'Link Down' status, please check cable connections when the link goes down.
Link State the target driver Link Up - F_Port on a switched fabric. The suffix is the topology the port negotiated: F_Port means it is attached point-to-point to a fabric switch port, which is what you want.
Status the FC transport's port state Online when the port has logged in to the fabric.
Mode the driver's active role Target, Initiator or Target + Initiator. See below.

Which modes a port can hold is an appliance-wide driver setting, not a per-port one. The QLogic target driver takes a qlini_mode parameter that decides when the initiator role exists at all, and QuantaStor runs the driver's own default, exclusive: the initiator role is active on load, is given up when target mode is enabled on a port, and comes back on that port when target mode is disabled again. That is what makes each port either Target or Initiator but never both, and it is what lets Enable FC Initiator Mode repurpose a port at all.

Target + Initiator requires the driver to be loaded with qlini_mode=dual instead, which makes every port on the appliance a target and an initiator at once. Set it with qs-util enabledualmode and reverse it with qs-util disabledualmode, which write dual and exclusive respectively and need a reboot to take effect; Dual-mode FC configuration covers the procedure and the driver reload. Dual mode is what you want when the appliance must also consume FC storage from another array, and it is also the only way to populate the FC Remote Ports view. Target-only is the right setting for a pure storage appliance.

(Note: qlini_mode also accepts enabled and disabled, which are not the values to use here. enabled keeps the initiator role up permanently rather than giving QuantaStor the dual-role behaviour, and disabled means the initiator role is never created, which leaves a port switched out of target mode with no role at all. Check the parameter's own description with modinfo qla2xxx_scst before setting it by hand.)

QuantaStor does not report the negotiated link speed. There is no speed field on the FC target port object, in the grid or in fcp-get. Read it on the appliance from the FC transport, along with what the adapter is capable of:

cat /sys/class/fc_host/host7/speed              # 8 Gbit
cat /sys/class/fc_host/host7/supported_speeds   # 8 Gbit, 16 Gbit, 32 Gbit
cat /sys/class/fc_host/host7/port_type          # NPort (fabric via point-to-point)
cat /sys/class/fc_host/host7/fabric_name        # 0x10000027f86e85cd

Take the host number from the port's Sysfs Path field, which reads /sys/class/fc_host/host7 and so on.

A 16/32 Gb adapter that reports 8 Gbit is almost always being limited by the fabric rather than by itself: FC negotiates down to the lower of the two ends, so an adapter whose supported_speeds starts at 8 Gbit and which lands on 8 Gbit is talking to an 8 Gb switch port. Compare fabric_name across the ports -- ports reporting the same fabric WWN are on the same fabric, so if a slower adapter on that fabric is also running at its own maximum, the switch is the ceiling. Replacing the adapter will not help; the switch port, its SFP or the cable will.

Target mode and initiator mode

 
The context menu on an FC target port that is currently in target mode. The mode item swaps to Enable FC Target Mode... on a port that is in initiator mode.
Navigation: Storage Management → Storage Systems (section) → select a Storage System → FC Ports (tab) → FC target port (select + right-click)

There is no toolbar button for these operations; they are on the context menu of a port in the FC Ports grid, and the menu offers only the mode you are not already in. A port in target mode shows Enable FC Initiator Mode...; a port in initiator mode shows Enable FC Target Mode.... Issue FC LIP and Properties... are always present.

Both dialogs are built the same way: an FC Port combo box listing every FC target port in the grid, a read-only Port Information group showing the selected port's State and Port WWN, and OK/Cancel. The combo is pre-selected to the port you right-clicked, and changing it repoints the operation, so check it before clicking OK.

Enable FC Target Mode

 
The Enable Fibre Channel Target Mode dialog. There is no Force option -- enabling target mode has nothing to override.

Enabling target mode registers the port with the SCST target driver so it starts presenting the LUNs assigned to it, and removes the initiator-mode marker that was keeping automatic re-enable away from the port. QuantaStor then re-runs fabric discovery and queues a LIP so clients notice the port.

This dialog has no Force option, because there is nothing to force: a port with no LUNs mapped and no sessions has no state to lose by becoming a target.

Enable FC Initiator Mode

 
The Enable Fibre Channel Initiator Mode dialog. Force skips the active-session check.

Enabling initiator mode is how you disable target mode. It writes 0 to the driver's per-port enable flag, so the port stops presenting its LUNs and every initiator logged in to it loses that path. It also writes a marker file for the port, which is what stops automatic re-enable from putting the port straight back into target mode -- so the choice survives a service restart and a reboot.

QuantaStor refuses this while the port has active sessions. You get an error naming the count:

There are 2 active sessions on Fiber Channel port '50:01:43:80:21:e0:e5:fc'.
Remove active sessions before switching to initiator mode.

Tick Force to skip that check and disable the port anyway. Do that only when you have already stopped I/O on the clients using it, or when you are deliberately removing a path from a multipathed client that has other healthy paths. On a port carrying the only path to a LUN, forcing this drops the client's storage.

Before disabling a port, check what is mapped to it and what is logged in to it. The following lists both on the appliance:

ls /sys/kernel/scst_tgt/targets/qla2x00t/51:40:2e:c0:01:7c:b8:ea/ini_groups/
ls /sys/kernel/scst_tgt/targets/qla2x00t/51:40:2e:c0:01:7c:b8:ea/sessions/

An initiator group under ini_groups whose luns directory contains numbered entries means that port is serving storage to that WWPN. qs volume-sn-list gives the same session view from the management interface, with the FC WWPNs shown in its Target IQN and Initiator IQN columns.

FC remote ports

 
The FC Remote Ports grid, grouped by the target port each remote WWPN was discovered through.

An FC remote port is a WWPN that the appliance's own FC transport has discovered on the fabric -- typically a client's HBA port, but also the FC ports of other appliances and arrays in the same zone. QuantaStor builds the list by walking the remote-port entries the driver creates under each of its ports, so a single client WWPN discovered through four target ports produces four rows, one per path.

A port in target-only mode has no remote ports at all. This is the single most surprising thing about this view and it is not a fault. The Linux FC transport only creates remote-port entries for a port that has an initiator role, so on an appliance whose ports all read Mode Target, qs fcrp-list returns nothing and the FC Remote Ports grid is empty -- even while initiators are logged in and using LUNs. Put the appliance into dual mode with qs-util enabledualmode if you want this view populated -- see Dual-mode FC configuration. To see who is logged in to a target-only port, read its SCST sessions instead, as shown above.

Two further points about the list:

  • Rows are not aged out. When a port leaves initiator mode, or a client is unzoned, the driver keeps its remote-port entry and marks it not present, and QuantaStor keeps reporting it. Treat the list as a superset of what is currently reachable, and confirm anything you are relying on against the port's sessions.
  • This list is what Add Host searches. The Select Initiator... button in Hosts and Host Groups' Add Host dialog is populated from the FC remote ports, de-duplicated by WWPN. That is the join between this page and host records: a WWPN has to be discoverable here for the picker to offer it, which is another reason the picker finds nothing on a target-only appliance. Type the WWPN in by hand in that case -- the host record does not care how it got there.

For one remote port's detail, use qs fcrp-get --remote-port=<WWPN>.

Issuing a LIP

 
The Fibre Channel Issue LIP dialog. Force widens the operation to every FC port on the appliance.
Navigation: Storage Management → Storage Systems (section) → select a Storage System → FC Ports (tab) → FC target port (select + right-click) → Issue FC LIP

A Loop Initialization Protocol reset makes the port re-initialize its fabric login, which prompts the switch and the initiators in the zone to rediscover what is behind it. The dialog describes it as forcing clients to discover presented FC target storage volumes, and that is its main use: reach for it when a client is not seeing a LUN you have just assigned, or when a newly zoned initiator is not turning up.

Force means "all ports", not "harder". This is the one field on the dialog worth reading twice. Left unticked, the operation issues a LIP on the single port named in the FC Port combo. Ticked, it ignores the combo and issues a LIP on every FC port on that appliance, one after another with a short pause between them -- the task description changes to say so. On an appliance serving live LUNs from several ports, that briefly disturbs all of them rather than one. qs-util issuelip on the appliance does the same all-ports operation.

A LIP is comparatively safe -- it re-initializes a link that is already working rather than tearing down a configuration -- but it is not free. Initiators lose their login to that port and have to re-establish it, which they do on their own schedule; on a port with several clients logged in, some take longer than others to come back. Confirm afterwards that the port still reads Status Online and Link State Link Up - F_Port, and that the sessions you expect have returned.

If a LIP appears to have no effect at all, check the port's Vendor field. QuantaStor only issues LIPs when it recognises at least one ALUA-capable adapter model in the system, and an adapter with an empty Vendor field has not been recognised. On such a system, issue the LIP from the appliance instead:

echo 1 > /sys/class/fc_host/host7/issue_lip

Zoning is a prerequisite

QuantaStor cannot configure FC switch zoning, and has no command that attempts to. Zoning is done on the fabric, with the switch vendor's own management tools, and it has to be in place before anything on this page will work: the initiator's WWPN and the target port's WWPN must be members of the same zone before the initiator can log in, before it will appear as an FC remote port, and before an assigned volume can reach it.

Zone the WWPN shown in the port's Active Port WWN field. That is the WWPN the port actually presents to the fabric, and it is normally identical to Port WWN -- the two differ only where a WWN emulation mode has been configured to make the appliance present a different identity, which is a support-assisted setup. Where they differ, Port WWN is the adapter's burned-in identity and Active Port WWN is what the switch sees.

Assigning a storage volume over FC

Assignment over FC is the same operation as over iSCSI: create a host record carrying the client's FC WWPN, then assign the volume to that host. What differs is only where the WWPN comes from.

1. Create the host with its FC WWPN

Navigation: Storage Management → Hosts & Portal Groups (section) → Host (toolbar group) → Add

In Add Host, give the host a name, then select the FC Initiator WWPN radio in the Initiator group -- the field beside it is enabled only while that radio is selected.

Either type the client's WWPN, or click Select Initiator... to pick it from the initiators the appliance can already see on the fabric. That picker is the reason FC target ports need dual mode: it lists FC remote ports, and an appliance in target-only mode sees none. If the list is empty, see FC remote ports and Dual-mode FC configuration.

The WWPN is normalised on entry, so colons, dashes, bare hex or an 0x prefix are all accepted.

A dual-port HBA has a WWPN per port. Add both to the same host --

Navigation: Storage Management → Hosts & Portal Groups (section) → Host (toolbar group) → Add Initiator

-- so the client keeps access through either port. Hosts and Host Groups covers host records, initiators and host groups in full.

2. Assign the volume

Navigation: Storage Management → Storage Volumes → Storage Volume (toolbar group) → Assign

Select the volume, tick the host, and apply. To assign several volumes to one host in a single operation, start from the host instead:

Navigation: Storage Management → Hosts & Portal Groups → Host (toolbar group) → Assign

. Storage Volumes owns assignment, access modes and CHAP.

3. Rescan on the client

The client will not see the LUN until its HBA rescans. On a Linux client:

echo "- - -" > /sys/class/scsi_host/host10/scan
lsblk -d -o NAME,SIZE,VENDOR,MODEL | grep OSNEXUS

From the command line

The same two steps, for scripted provisioning:

qs host-add --hostname=<name> --iqn=<WWPN>

qs volume-assign --volume=<volume> --host-list=<host>

--iqn is the initiator argument for all three initiator types -- pass it a WWPN and the service classifies the value by its format. Note there is no --lun argument; LUN numbering is assigned by the appliance.

What the assignment programs, and what the client sees

What the assignment programs on the appliance is worth knowing, because it explains what the client then sees. QuantaStor creates an initiator group named after the host's WWPN under every FC target port on the appliance, and maps two LUNs into each: LUN 0 is a QuantaStor control device, and the volume lands at LUN 1 and upwards. When the volume's pool belongs to an HA group, the same groups and LUNs are programmed on every appliance in that group, so the client gets paths to the standby appliances as well as the active one.

The client therefore sees one SCSI device per path, not one per volume. One initiator port against seven enabled target ports across two appliances yields seven block devices for a single volume. They identify themselves with vendor OSNEXUS and model QUANTASTOR, which is a quick way to pick QuantaStor LUNs out of a client's device list:

echo "- - -" > /sys/class/scsi_host/host10/scan
lsblk -d -o NAME,SIZE,VENDOR,MODEL | grep OSNEXUS

Coalescing those paths into one device is the client's job -- see Multipath Configuration. Do not skip it: the paths are not interchangeable. QuantaStor advertises ALUA, marking the paths through the appliance that currently owns the pool as active and the paths through the others as standby. A read issued to a standby path returns no data, so a client that has picked one without a multipath layer above it looks like it has an empty disk rather than a wrong path. On a forced failover the active and standby roles swap, and clients see the session on the old owner drop -- HA Cluster Setup (JBODs) covers that behaviour.

Troubleshooting

A LUN does not appear on an FC client

Work down the path, from the fabric inwards:

  1. Zoning. Confirm the client's WWPN and the target port's Active Port WWN are in the same zone on the switch. Nothing else on this list matters until they are.
  2. Port mode and link. In the FC Ports grid, confirm the target port reads Mode Target, Status Online and Link State Link Up - F_Port.
  3. The WWPN on the host record. Confirm the WWPN in Hosts and Host Groups matches the client's HBA exactly. A single wrong digit produces exactly this symptom and nothing anywhere reports an error, because a host record with a WWPN that no initiator uses is perfectly valid.
  4. The assignment. Confirm the volume is assigned to that host with qs va-list.
  5. The mapping on the appliance. Confirm the initiator group and LUN exist under the target port. An empty or missing group here means the assignment did not reach the driver:
    ls /sys/kernel/scst_tgt/targets/qla2x00t/<target WWPN>/ini_groups/<client WWPN>/luns/
  6. Rescan on the client. The client will not notice a new LUN until its HBA rescans. On Linux, write - - - to the adapter's scan node as shown above; on other platforms use that platform's storage adapter rescan.
  7. Issue a LIP on the target port, which prompts the client to rediscover rather than waiting for it to.

If a device does appear but reads as empty or zero-length, it is a standby ALUA path rather than a broken one. Check which appliance currently owns the pool, and configure multipath on the client.

An initiator is not listed as an FC remote port

If every port on the appliance reads Mode Target, this is expected and not a fault -- see FC remote ports. Check the target port's SCST sessions instead; an initiator that is logged in appears there whatever mode the port is in. If it is absent from the sessions too, the problem is upstream: zoning, the link, or the client's own HBA.

Enable FC Initiator Mode is refused

The port has active sessions. Stop I/O on the clients using it and let their sessions drop, or tick Force if you accept dropping them. As a last resort a single session can be closed from the appliance:

echo 1 > /sys/kernel/scst_tgt/targets/qla2x00t/<target WWPN>/sessions/<initiator WWPN>/force_close

Throughput is lower than the adapter's rating

Start with the negotiated speed rather than the adapter's label -- see Reading port state, mode, speed and topology for how to read it and why a 32 Gb adapter can legitimately run at 8 Gbit. If the negotiated speed is what you expect, the per-port frame and error counters under /sys/class/fc_host/host7/statistics/ distinguish a throughput problem from a physical-layer one: error_frames, dumped_frames and the CRC counters climbing under load point at the cable, the SFP or the switch port rather than at the appliance. QuantaStor also ships a per-port metric collector, qs-fcportmon, which publishes transmit and receive IOPS and byte rates for the dashboards; it is a systemd service and has to be running for those metrics to exist.

Note the FC HBA is not one of the devices the hw-controller-list view covers -- Hardware Controllers & Enclosures documents SAS and RAID controllers, and FC adapters do not appear there. The FC Ports tab is the only place the adapter's model, firmware and driver versions are reported.

CLI reference

Command Short form Purpose
fiber-channel-port-list fcp-list List FC target ports. Optionally scope with --storage-system.
fiber-channel-port-get fcp-get Full detail for one port, by --port=<WWPN> or ID.
fiber-channel-port-enable fcp-enable Switch a port into target mode.
fiber-channel-port-disable fcp-disable Switch a port into initiator mode. Add --flags=force to skip the active-session check.
fiber-channel-port-issuelip fcp-issuelip Issue a LIP on one port, or on all ports on the appliance with --flags=force.
fc-remote-port-list fcrp-list List remote FC WWPNs discovered on the fabric.
fc-remote-port-get fcrp-get Detail for one remote port, by --remote-port=<WWPN>.

Every one of these takes the port as --port, not as a port-specific argument name, and every one accepts either the WWPN or the object's UUID. There is no fc-port-list or fc-target-port-list; the target port commands are all spelled fiber-channel-port-* and only the remote port commands use the fc- prefix.

Related pages


Verified against QuantaStor 6.9.0.