*** Discovery feature fix in nvme-cli ***

Since the only way to do the discovery feature of NVMe-over-Fabrics is through nvme-cli, I thought it will be appropriate to send a patch to this email list (if nothing more than to inform and educate).

I'll push this to Keith Busch (the nvme-cli owner).

Changes since v1:
patch formatting lint, no changed functionality.

Changes since v0:
changed short 'h' option to 'q'.

Jay Freyensee (1):
nvme-cli: user-defined hostnqn option for discover

 fabrics.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

2.4.3

The nvme-cli will always use the default hostnqn
in /dev/nvme-fabrics for the discovery query, even though both the NVMe Target and NVMe Host rdma implementations allow user-defined hostnqn naming.

For example, this is the current, somewhat broken behavior if you used your own hostnqn provision naming on the NVMe kernel target:

nvme discover /dev/nvme-fabrics -t rdma --traddr=192.168.1.3 --trsvcid=4420

in dmesg:

[591910.025779] nvme nvme0: Connect Invalid Data Parameter, hostnqn "nqn.2014-08.org.nvmexpress:NVMf:uuid:a2d7752c-a31b-477a-a003-31a5e1c424a9"

New, fixed behavior introduced by this patch:

[root at fedora23-fabrics-host1 nvme-cli]# nvme discover -t rdma --traddr=192.168.1.3 --trsvcid=4420 --hostnqn=host1-rogue-nqn

Discovery Log Number of Records 1, Generation counter 10 =====Discovery Log Entry 0======

trtype:  ipv4
adrfam:  rdma
nqntype: 2
treq:    0
portid:  1
trsvcid: 4420
subnqn:  nullside-nqn
traddr:  192.168.1.3
rdma_prtype: 0
rdma_qptype: 0
rdma_cms:    0
rdma_pkey: 0x0000

[root at fedora23-fabrics-host1 nvme-cli]#

---

changes since v1:
tags, patch formatting, no functionality change

changes since v0:
changed short 'h' option to 'q'

 fabrics.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

index 3666a01..41a80df 100644
@@ -49,6 +49,7 @@ struct config {
 	char *transport;
 	char *traddr;
 	char *trsvcid;
+	char *hostnqn;
 	char *raw;
 	char *device;
 } cfg = { 0 };

@@ -395,6 +396,14 @@ static int build_options(char *argstr, int max_len)
 		max_len -= len;
 	}
 
+	if (cfg.hostnqn) {
+		len = snprintf(argstr, max_len, ",hostnqn=%s", cfg.hostnqn);
+		if (len < 0)
+			return -EINVAL;
+		argstr += len;
+		max_len -= len;
+	}
+
 	return 0;
 }
 

@@ -525,6 +534,8 @@ int discover(const char *desc, int argc, char **argv, bool connect)
 			"transport address" },
 		{"trsvcid", 's', "LIST", CFG_STRING, &cfg.trsvcid, required_argument,
 			"transport service id (e.g. IP port)" },
+		{"hostnqn", 'q', "LIST", CFG_STRING, &cfg.hostnqn, required_argument,
+			"user-defined hostnqn (if default not used)" },
 		{"raw", 'r', "LIST", CFG_STRING, &cfg.raw, required_argument,
 			"raw output file" },
 		{0},

2.4.3

Maybe -n or -N would be a good choice for the short option flag?

Otherwise this looks fine to me:

Any chance you could also send a patch that reads /etc/nvme/hostnqn for a default hostnqn so that we can have a persistent one?

I thought Roy's suggestion for -q was fine.

Cool, thanks.

I'm a tad unclear what is the request? The default hostnqn is buried inside /dev/nvme-fabrics. You want nvme-cli to read out the default hostnqn from /dev/nvme-fabrics and place it in /etc/nvme/hostnqn?

I think Christoph is requesting that when the user doesn't pass a hostnqn, nvme-cli will try to read it from a file located in /etc/nvme/hostnqn (and if this doesn't exist then go ahead without it). This way, the host can have a persistent hostnqn across reboots (the driver generates one on module init time).

hmmm...the scenario I set up that found this issue, the host generates a default hostnqn in the nvme-fabrics driver at init(). And if there is no --hostnqn flag passed, the /dev/nvme-fabrics driver will use the default generated by the nvme-fabrics driver at init(). And no /etc/nvme/hostnqn file gets created or exists currently.

So is the request to have nvme-cli use whatever is in /etc/nvme/hostnqn
(if it exists) over the default in the nvme-fabrics driver? So
preference of hostnqn input would be:

1. --hostnqn flag
2. /etc/nvme/hostnqn
3. default hostnqn generated by nvme-fabrics driver (ex: nqn.2014 -08.org.nvmexpress:NVMf:uuid:a2d7752c-a31b-477a-a003-31a5e1c424a9)

(note 2. may contain a hostnqn different from the default)

??