Choices are ipv4, ipv6, or ipv4+ipv6.

Defaults to ipv4+ipv6.

There is no guarantee that there will be a route to reach that IOC. However, we can use the socket option SO_BINDTODEVICE to force the connection to be made on a specific interface instead of letting the routing tables decide where to make the connection.

This option determines whether stacd will use SO_BINDTODEVICE to force connections on an interface or just rely on the routing tables. The default is to use SO_BINDTODEVICE, in other words, stacd does not ignore the interface.

BACKGROUND: By default, stacd will connect to IOCs on the same interface that was used to retrieve the discovery log pages. If stafd discovers a DC on an interface using mDNS, and stafd connects to that DC and retrieves the log pages, it is expected that the storage subsystems listed in the log pages are reachable on the same interface where the DC was discovered.

For example, let's say a DC is discovered on interface ens102. Then all the subsystems listed in the log pages retrieved from that DC must be reachable on interface ens102. If this doesn't work, for example you cannot "ping -I ens102 [storage-ip]", then the most likely explanation is that proxy arp is not enabled on the switch that the host is connected to on interface ens102. Whatever you do, resist the temptation to manually set up the routing tables or to add alternate routes going over a different interface than the one where the DC is located. That simply won't work. Make sure proxy arp is enabled on the switch first.

Setting routes won't work because, by default, stacd uses the SO_BINDTODEVICE socket option when it connects to IOCs. This option is used to force a socket connection to be made on a specific interface instead of letting the routing tables decide where to connect the socket. Even if you were to manually configure an alternate route on a different interface, the connections (i.e. host to IOC) will still be made on the interface where the DC was discovered by stafd.

Defaults to false.

With yes, the removal of a DLPE means the subsystem is no longer zoned for this host, and stacd disconnects the I/O controllers it had connected for it. With no, zoning is disregarded entirely and every connection stacd has made is kept, whatever the CDC says. Connections can then only be removed with the nvme-cli command "nvme disconnect", by adding an exclude= entry, or by rebooting.

This only ever applies to connections stacd made itself. A connection that belongs to another orchestrator, or one made at boot from the NBFT, is never disconnected by stacd: that is decided by libnvme's ownership registry and by the NBFT, not by this parameter.

Defaults to yes.

If a host is currently failing to connect to an I/O controller and if the NCC bit associated with that I/O controller is asserted, the host can decide to stop trying to connect to that subsystem until connectivity is restored. This will be indicated by the CDC when it clears the NCC bit.

The parameter connect-attempts-on-ncc= controls whether stacd will take the NCC bit into account when attempting to connect to an I/O Controller. Setting connect-attempts-on-ncc= to 0 means that stacd will ignore the NCC bit and will keep trying to connect. Setting connect-attempts-on-ncc= to a non-zero value indicates the number of connection attempts that will be made before stacd gives up trying. Note that this value should be set to a value greater than 1. In fact, when set to 1, stacd will automatically use 2 instead. The reason for this is simple. It is possible that a first connect attempt may fail.

Defaults to 0.

The controller= keyword no longer belongs here. Which controllers to connect to, and with what parameters, is stated in /etc/nvme/nvme-stas.conf as of nvme-stas 3.0 — a Discovery Controller as a [Discovery Controller] section, an I/O subsystem as a [Subsystem] section. See nvme-stas.conf(5). A controller= entry left behind in this file is reported in the log, not silently ignored.

Deprecated. Use libnvme's host-wide exclusion list instead: /etc/nvme/exclusions.conf and /etc/nvme/exclusions.conf.d/, which are managed with nvme exclusion. That list is honored by every NVMe-oF tool on the host, not just stafd and stacd, and it is read live: an entry added there takes effect on the next connection attempt, without reloading stafd or stacd.

exclude= still works and is honored in addition to libnvme's list — a controller is excluded if it matches either — but it will be removed in a future release.

An entry is a series of fields separated by semi-colons:

exclude=transport=[trtype];traddr=[traddr];trsvcid=[trsvcid];host-iface=[iface];nqn=[nqn]


                    

Every field is optional. Multiple exclude= keywords may appear in the config file to specify more than 1 excluded controller.

Note 1: A minimal match approach is used to eliminate unwanted controllers. That is, you do not need to specify all the parameters to identify a controller. Just specifying the host-iface, for example, can be used to exclude all controllers on an interface.

Note 2: an exclusion takes precedence over the connectivity configuration. A controller configured in /etc/nvme/nvme-stas.conf can be eliminated by the exclude= keyword.

Examples:

exclude = transport=tcp;traddr=fe80::2c6e:dee7:857:26bb # Eliminate a specific address
exclude = host-iface=enp0s8                             # Eliminate everything on this interface