Bug 2128030

Similar to iSCSI initiator support, we'd like to have support for NVMe over Fabrics initiator. The API could be roughly similar to https://pykickstart.readthedocs.io/en/latest/commands.html#iscsi

First sketch of the 'nvme' kickstart command:

nvme --subsysnqn SUBSYSNQN --transport TRANSPORT [--transport_addr ADDRESS]
     [--transport_svcid SVCID] [--iface IFACE] [--keep_alive_tmo TIMEOUT]
     [--reconnect_delay DELAY] [--ctrl_loss_tmo TIMEOUT] [--fast_io_fail_tmo TIMEOUT]

Create a transport connection to a remote system and create a NVMe over Fabrics controller for the NVMe subsystem specified by the SUBSYSNQN option.

--subsysnqn SUBSYSNQN
  The name for the NVMe subsystem to connect to.

--transport TRANSPORT
  The network fabric used for a NVMe-over-Fabrics network. Typical values include 'fc', 'rdma' and 'tcp'.

--transport_addr ADDRESS
  The network address of the Controller. For transports using IP addressing (e.g. 'tcp') this is an IP-based address.

--transport_svcid SVCID
  The transport service ID. For transports using IP addressing (e.g. 'tcp') this field is the port number. By default, the IP port number for the 'rdma' transport is 4420.

--iface IFACE
  The network interface used on the host to connect to the Controller. This forces the connection to be made on a specific interface instead of letting the system decide.


The following optional arguments would be great to have to ensure a degree of link stability:

--keep_alive_tmo TIMEOUT
  The keep alive timeout (in seconds).

--reconnect_delay DELAY
  The delay (in seconds) before reconnect is attempted after a connect loss.

--ctrl_loss_tmo TIMEOUT
  The controller loss timeout period (in seconds). A special value of -1 will cause reconnecting forever.

--fast_io_fail_tmo TIMEOUT
  Fast I/O Fail timeout (in seconds).


The following options might be possibly needed for 9.3+:

--dhchap_key KEY
  NVMe In-band authentication secret in ASCII format as described in the NVMe 2.0 specification.

--dhchap_ctrl_key KEY
  NVMe In-band authentication controller secret for bi-directional authentication.

--tls BOOL
  Enable TLS encryption (TCP). Boolean value.

--hostsymname NAME
  TP8010: NVMe host symbolic name.


And for the sake of completeness, these are the options that might be supported by lower layers but may or may not be particularly interesting to kickstart, suggesting to skip these for the moment:

 * nr_io_queues: The number of I/O queues.
 * nr_write_queues: Number of additional queues that will be used for write I/O.
 * nr_poll_queues: Number of additional queues that will be used for polling latency sensitive I/O.
 * queue_size: Number of elements in the I/O queues.
 * tos: Type of service.
 * disable_sqflow: Disables SQ flow control to omit head doorbell update for submission queues when sending nvme completions. Boolean value.
 * hdr_digest: Generates/verifies header digest (TCP). Boolean value.
 * data_digest: Generates/verifies data digest (TCP). Boolean value.



Similar to https://pykickstart.readthedocs.io/en/latest/commands.html#iscsiname there's also a need to define HostNQN and HostID:

* hostnqn <nqn>

The Host NQN (NVM Qualified Name) that uniquely identifies the NVMe Host. When not specified, a default stable identifier computed from various system identifiers (DMI, device tree) is used instead.

As defined by the NVM Express Base Specification 2.0b [1], Section 4.5: NVMe Qualified Names

Example:
  nqn.2014-08.com.example:nvme:nvm-subsystem-sn-d78432
  nqn.2014-08.com.example:nvme.host.sys.xyz
  nqn.2014-08.org.nvmexpress:uuid:baaaaaa9-4a67-1234-9370-53aee90d8168

(see also `nvme gen-hostnqn`)


* hostid <id>

The Host ID value that identifies the host (in addition to HostNQN) in form of UUID (Universally Unique Identifier), e.g. as returned by `uuidgen`.

Example: 8f5849aa-513e-4b43-b449-0d79689bfb13



[1] https://nvmexpress.org/developers/nvme-specification/