This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2128030 - RFE: Add support for NVMeoF initiator
Summary: RFE: Add support for NVMeoF initiator
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: pykickstart
Version: 9.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Brian Lane
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-09-19 16:34 UTC by Tomáš Bžatek
Modified: 2023-09-18 16:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-09-18 16:00:36 UTC
Type: Story
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker   RHEL-4751 0 None Migrated None 2023-09-18 16:00:26 UTC
Red Hat Issue Tracker RHELPLAN-134343 0 None None None 2022-09-19 16:38:11 UTC

Description Tomáš Bžatek 2022-09-19 16:34:31 UTC
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/

Comment 2 Brian Lane 2022-09-19 21:55:32 UTC
Changes like this need to be done upstream first, and Anaconda will require most of the work for this. Please file an RFE with Anaconda as well.

Also, I'm increasingly reluctant to add so many arguments to commands, linking in every last option from the underlying tools makes things harder to use. Where possible we should use some kind of option passthru for things like timeouts, delays, etc.

Comment 4 Tomáš Bžatek 2022-09-20 12:33:32 UTC
(In reply to Brian Lane from comment #2)
> Where possible we should use some kind of option passthru for things like timeouts, delays, etc.

Ah, right, good idea! In fact, the lower layers (libblockdev) already work this way: http://storaged.org/libblockdev/3.0/libblockdev-NVMe.html#bd-nvme-connect

So this kickstart support would only be a pass-through to blivet which itself will work as a pass-through to down to libblockdev. Also, the NVMe standard is ever evolving and we'll be gradually adding new options as new standard additions emerge.


In that case, I think we could strip down the kickstart command to the following primary options:

> nvme --subsysnqn SUBSYSNQN --transport TRANSPORT [--transport_addr ADDRESS] [--iface IFACE] [extra_options...]

and the rest of the options would just be a pass through further down. We can copy&paste the optional arguments from blivet/libblockdev, to have them documented.


(technically it would be nice to have some checks here, e.g. that the IFACE specified is present and up or that the ADDRESS passes syntax check for the given TRANSPORT family (e.g. ipv4/ipv6 address validation or DNS resolve test)..)

Comment 5 Brian Lane 2022-09-20 15:35:02 UTC
(In reply to Tomáš Bžatek from comment #4)
> 
> (technically it would be nice to have some checks here, e.g. that the IFACE
> specified is present and up or that the ADDRESS passes syntax check for the
> given TRANSPORT family (e.g. ipv4/ipv6 address validation or DNS resolve
> test)..)

That would be handled by Anaconda, and is probably a good dividing line for what to pass via --extra and what to make a specific argument. eg. Assume no checking until the bottom layer for --extra options, and some level of checking for named arguments like IFACE.

Comment 6 RHEL Program Management 2023-09-18 15:58:44 UTC
Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 7 RHEL Program Management 2023-09-18 16:00:36 UTC
This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.


Note You need to log in before you can comment on or make changes to this bug.