Comment 17 for bug 1867366

Oops there is something else.. hostnqn *could* come from kernel (from nvme-connect Documentation):

--hostnqn=<hostnqn>::
    Overrides the default Host NQN that identifies the NVMe Host.
    If this option is not specified, the default is read from
    /etc/nvme/hostnqn first. If that does not exist, the autogenerated
    NQN value from the NVMe Host kernel module is used next.
    The Host NQN uniquely identifies the NVMe Host.

the documentation for nvme-discover.txt does not contain the kernel part.

But I could not find any code reading hostnqn from sysfs or ioctls or anything like it .. (weird). There is a function to automatically generate a hostnqn with libuuid ... but nothing else as it seems.. so the documentation seems wrong.

So I think that for both, Bionic and Focal, we should concentrate in hard coded:

#define PATH_NVME_FABRICS "/dev/nvme-fabrics"
#define PATH_NVMF_DISC "/etc/nvme/discovery.conf"
#define PATH_NVMF_HOSTNQN "/etc/nvme/hostnqn"
#define PATH_NVMF_HOSTID "/etc/nvme/hostid"

(from fabric.c)

Assumption:
- If no hostnqn is given, then there is no way a fabric was configured, and you're safe to delete both files.

Logic:
- check if hostnqn is set in /etc/nvme/hostnqn, if yes warn user hostid can be duplicated
  - if not, check if hostid was changed.. if yes, keep it... if no change it to correct one, create hostnqn

Make Sure:
- both files /etc/nvme/hostnqn and /etc/nvme/hostid are kept on purge (just because they are related to host identification, user can delete later if really wanted).