nvme-cli connect command incorrectly passes hostnqn value as hostid instead of actual host identifier

[sukhi61166]

Description

nvme-cli connect command incorrectly passes hostnqn value as hostid instead of actual host identifier

Steps to Reproduce

Connect the drive to host - “nvme connect -t rdma -a -s 4420 -i 15 -n nqn.2015-09.com.wdc:nvme.1”

Observations

nvme-cli connect command incorrectly passes hostnqn value as hostid instead of actual host identifier

When connecting the drive using the -I value, the input is accepted correctly and displayed properly.

The issue not seen with 1.16 nvme cli version

Reservation report showing hostnqn value under hostid field

root@blr-r14-s40u:~# date;nvme connect -t rdma -a 10.10.8.47 -s 4420 -i 15 -n nqn.2015-09.com.wdc:nvme.1
Wed Mar 25 05:33:42 AM UTC 2026
connecting to device: nvme1

root@blr-r14-s40u:~# date;nvme resv-report -e /dev/nvme1n1
Wed Mar 25 06:11:49 AM UTC 2026
NVME Reservation status:
gen       : 5
rtype     : 0
regctl    : 0
ptpls     : 0

root@blr-r14-s40u:~# date;nvme resv-register /dev/nvme1n1 -k 111
Wed Mar 25 06:11:57 AM UTC 2026
NVME Reservation  success
root@blr-r14-s40u:~# date;nvme resv-report -e /dev/nvme1n1
Wed Mar 25 06:12:00 AM UTC 2026
NVME Reservation status:
gen       : 6
rtype     : 0
regctl    : 1
ptpls     : 0
regctlext[0] :
  cntlid     : 1
  rcsts      : 0
  rkey       : 6f
  hostid     : 30111000e18411ec80003cecefcf7a58

root@blr-r14-s40u:~# cat /etc/nvme/hostid
21518b3a-f04b-4b9f-9e11-23a9601dfcc6
root@blr-r14-s40u:~#
root@blr-r14-s40u:~# cat /etc/nvme/hostnqn
nqn.2014-08.org.nvmexpress:uuid:30111000-e184-11ec-8000-3cecefcf7a58
root@blr-r14-s40u:~#

**nvme version**

root@blr-r14-s40u:~# nvme version
nvme version 2.16 (git 2.16)
libnvme version 1.16 (git 1.16)
root@blr-r14-s40u:~#

Dmesg Log at time of connection

[Wed Mar 25 02:37:01 2026] nvme nvme1: QID 0x0: qp_num 0x128; remote_qp_num 0x203b
[Wed Mar 25 02:37:01 2026] subsysnqn nqn.2015-09.com.wdc:nvme.1 iopolicy changed from numa to round-robin
[Wed Mar 25 02:37:02 2026] nvme nvme1: queue_size 128 > ctrl sqsize 17, clamping down
[Wed Mar 25 02:37:02 2026] nvme nvme1: creating 15 I/O queues.
[Wed Mar 25 02:37:03 2026] nvme nvme1: mapped 15/0/0 default/read/poll queues.
[Wed Mar 25 02:37:03 2026] nvme nvme1: QID 0x1: qp_num 0x129; remote_qp_num 0x203c
[Wed Mar 25 02:37:03 2026] nvme nvme1: QID 0x2: qp_num 0x12a; remote_qp_num 0x203d
[Wed Mar 25 02:37:03 2026] nvme nvme1: QID 0x3: qp_num 0x12b; remote_qp_num 0x203e
[Wed Mar 25 02:37:03 2026] nvme nvme1: QID 0x4: qp_num 0x12c; remote_qp_num 0x203f
[Wed Mar 25 02:37:04 2026] nvme nvme1: QID 0x5: qp_num 0x12d; remote_qp_num 0x3000
[Wed Mar 25 02:37:04 2026] nvme nvme1: QID 0x6: qp_num 0x12e; remote_qp_num 0x3001
[Wed Mar 25 02:37:04 2026] nvme nvme1: QID 0x7: qp_num 0x12f; remote_qp_num 0x3002
[Wed Mar 25 02:37:04 2026] nvme nvme1: QID 0x8: qp_num 0x130; remote_qp_num 0x3003
[Wed Mar 25 02:37:04 2026] nvme nvme1: QID 0x9: qp_num 0x131; remote_qp_num 0x2004
[Wed Mar 25 02:37:04 2026] nvme nvme1: QID 0xa: qp_num 0x132; remote_qp_num 0x3005
[Wed Mar 25 02:37:04 2026] nvme nvme1: QID 0xb: qp_num 0x133; remote_qp_num 0x2006
[Wed Mar 25 02:37:04 2026] nvme nvme1: QID 0xc: qp_num 0x134; remote_qp_num 0x2007
[Wed Mar 25 02:37:04 2026] nvme nvme1: QID 0xd: qp_num 0x135; remote_qp_num 0x2008
[Wed Mar 25 02:37:04 2026] nvme nvme1: QID 0xe: qp_num 0x136; remote_qp_num 0x2009
[Wed Mar 25 02:37:04 2026] nvme nvme1: QID 0xf: qp_num 0x137; remote_qp_num 0x200a
[Wed Mar 25 02:37:04 2026] nvme nvme1: new ctrl: NQN "nqn.2015-09.com.wdc:nvme.1", addr 10.10.8.47:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:30111000-e184-11ec-8000-3cecefcf7a58

[igaw]

Could you try if the current master works? Just did some changes how hostid is handled.

[ikegami-t]

Seems since the hostid parameter not specified by the connect command then the hostnqn string value after the "uuid:" used for the hostid as below then looks you can resolve this issue by using the hostid parameter for the connect command.

static const char *hostid_from_hostnqn(const char *hostnqn)
{
	const char *match;

	if (!hostnqn)
		return NULL;

	match = strstr(hostnqn, "uuid:");
	if (!match)
		return NULL;

	return match + strlen("uuid:");
}

__public int nvmf_context_set_hostnqn(struct nvmf_context *fctx,
		const char *hostnqn, const char *hostid)
{
	fctx->hostnqn = hostnqn;
	if (!hostid)
		hostid = hostid_from_hostnqn(hostnqn);

[ikegami-t]

1. Before the hostid file value used on v1.16 if the hostid parameter not specified for the connect command as below.

#define PATH_NVMF_HOSTID	"/etc/nvme/hostid"
...
static int nvmf_hostid_file(void)
{
	FILE *f;
	char hostid[NVMF_HOSTID_SIZE + 1];
	int ret = false;

	f = fopen(PATH_NVMF_HOSTID, "r");
	if (f == NULL)
		return false;

	if (fgets(hostid, sizeof(hostid), f) == NULL)
		goto out;

	fabrics_cfg.hostid = strdup(hostid);
	if (!fabrics_cfg.hostid)
		goto out;

	ret = true;
out:
	fclose(f);
	return ret;
}

2. 34ff78d changed to use the hostnqn string value after the "uuid:".
3. But still not sure why changed to not use the hostid file when the hostid parameter not supecified for the connect command.

[ikegami-t]

Sorry still there is a function to read the hostid file below so my comments above may be not correct.

#define NVMF_HOSTID_FILE	SYSCONFDIR "/nvme/hostid"
...
__public char *libnvme_read_hostid(void)
{
	char *hostid = getenv("LIBNVME_HOSTID");

	if (hostid) {
		if (!strcmp(hostid, ""))
			return NULL;
		return strdup(hostid);
	}

	return nvmf_read_file(NVMF_HOSTID_FILE, NVMF_HOSTID_SIZE);
}

But the hostid file path was changed as below and also on my local environment the path is handled as /usr/local/etc/nvme/hostid but not /etc/nvme/hostid.

- #define PATH_NVMF_HOSTID	"/etc/nvme/hostid"
+ #define NVMF_HOSTID_FILE	SYSCONFDIR "/nvme/hostid"

Then it is not able to read the host ID information actually.

tokunori@tokunori-X570-Taichi:~/nvme-cli-2$ cat /usr/local/etc/nvme/hostid
cat: /usr/local/etc/nvme/hostid: No such file or directory (os error 2)
tokunori@tokunori-X570-Taichi:~/nvme-cli-2$ cat /etc/nvme/hostid
849efe32-3ff8-4a22-9683-af0086ea70f5

[ikegami-t]

It was changed by the commit: f356ab0 to change the hostid file path to use SYSCONFDIR.

But it is actually the SYSCONFDIR set as /usr/local/etc so seems the prefix path should be fixed as / but not /usr/local for the hostid file but the definition looks used for other file etc, and seems better to not change the prefix path for other files.

roject(
...
    default_options: [
...
        'prefix=/usr/local',
...
        'sysconfdir=etc',
...
    ],
)
...
prefixdir      = get_option('prefix')
...
sysconfdir     = join_paths(prefixdir, get_option('sysconfdir'))
...
conf.set('SYSCONFDIR', '"@0@"'.format(sysconfdir))

[igaw]

The default prefix is /usr/local. You can change it by meson setup --prefix=/.

[martin-belanger]

@ikegami-t - I see the following definitions in the commit f356ab0:

#define NVMF_HOSTNQN_FILE	"SYSCONFDIR/nvme/hostnqn"
#define NVMF_HOSTID_FILE	"SYSCONFDIR/nvme/hostid"

Shouldn't it be defined as:

#define NVMF_HOSTNQN_FILE	SYSCONFDIR "/nvme/hostnqn"
#define NVMF_HOSTID_FILE	SYSCONFDIR "/nvme/hostid"

[igaw]

Could be but that's not failing. This stuff is tested.

@sukhi61166 did you compile your own nvme-cli? What --prefix did you use?

[ikegami-t]

The default prefix is /usr/local. You can change it by meson setup --prefix=/.

I see but the default hostid file path on my PC is /etc/nvme/hostid. To make sure could you please let me know why the default prefix is /usr/local but not /etc? Is the default prefix used on almost linux environment?

@ikegami-t - I see the following definitions in the commit f356ab0:

#define NVMF_HOSTNQN_FILE	"SYSCONFDIR/nvme/hostnqn"
#define NVMF_HOSTID_FILE	"SYSCONFDIR/nvme/hostid"

Shouldn't it be defined as:

#define NVMF_HOSTNQN_FILE	SYSCONFDIR "/nvme/hostnqn"
#define NVMF_HOSTID_FILE	SYSCONFDIR "/nvme/hostid"

Yes this was fixed by the commit 0e5e1e3.

[martin-belanger]

@ikegami-t - try this:

rm -rf .build
meson setup .build --prefix /usr --sysconfdir /etc --buildtype release
meson compile -C .build

Note that --buildtype is optional. You can set it to debug instead of release is you need the debug symbols.

[martin-belanger]

FWIW, I just submitted a PR for the README.md file that describes the default install location and how to change it.
#3246

[ikegami-t]

Yes by the build setup mentioned the NVMF_HOSTID_FILE definition is set as /etc/nvme/hostid for now. But still I am not sure why the default hostid file path was changed to /usr/local/etc/nvme/hostid from /etc/nvme/hostid. Thanks for the PR change.

[martin-belanger]

The /usr/local default is intentional — it's assumed that anyone building nvme-cli from source is a developer, not an end user. The distro-approved way to get nvme-cli is through your package manager (apt-get, zypper, dnf, etc.).

By defaulting to /usr/local, development builds stay out of the way of the distro-installed version. This matters because meson uninstall cleanly removes what was built from source, and your original package-manager install under /usr is left untouched — so you automatically fall back to the distro version once you're done testing.

If you actually want to replace the system install (e.g. you're packaging for a distro or doing a production deployment), you can override it explicitly with --prefix /usr --sysconfdir /etc.

[igaw]

Yes, that's the exact reason the default is /usr/local. This is how autotools/autoconf works as well, it's a 20+ year default.

[ikegami-t]

Understood as the previous hostid file path /etc/nvme/hostid implemented in nvme-cli was not correct or good. Thank you.