nvme‐discoverd

nvme-discoverd

nvme-discoverd is a systemd daemon. It is built from the nvme-cli source tree. It keeps a host's NVMe-oF fabric connections up. It connects the Discovery Controllers it is told about. Those come from static configuration, NBFT, or Fibre Channel discovery. Once a Discovery Controller is connected, discoverd reads its Discovery Log Page (DLP). It then discovers and connects the I/O Controllers and any referred Discovery Controllers that DLP lists. It retries automatically when a connection fails or drops. It has no role on a host with only local (PCIe) NVMe. It is needed only for NVMe over Fabrics. It is currently a technology preview. It is disabled by default. Build with -Dnvme-discoverd=enabled to try it. It requires the fabrics build option and libsystemd 253 or later.

Why does it exist?

nvme-cli already autoconnects NVMe-oF targets. It uses a collection of udev rules and one-shot systemd services (see How to set up NVMe-oF autoconnect). That mechanism accreted over several years, one rule at a time. It has two structural gaps. A persistent daemon can close both. A set of udev rules cannot.

• No retry. Each rule fires once per event. Events are a Discovery Log Page Change AEN, a rediscover, or an FC discovery uevent. Each one starts nvme connect-all for that one target. If the target is momentarily unreachable, that attempt fails. Nothing tries again until the next unrelated event happens to fire. That may be never.
• The late-NBFT path only works under NetworkManager. A host may boot from a network-attached namespace. One of its interfaces may come up after the initramfs stage. The retry for that case depends on a NetworkManager dispatcher script. systemd-networkd has no equivalent hook. It is common on servers and minimal images. On those hosts the late connection silently never happens.

nvme-discoverd is a long-lived process instead of a chain of one-shot rules. So it can just keep trying. It owns a "desired set" of connections. The set comes from static config, the NBFT table, and Discovery Log Pages already read. It retries anything in that set that isn't currently connected. It does this on its own schedule. It does not wait for any particular event to fire. That retry loop is manager-agnostic by construction. It doesn't care whether NetworkManager, systemd-networkd, or nothing at all is running. So it also fixes the late-NBFT gap above as a side effect. No interface-name matching is involved.

How is it different from nvme-stas?

nvme-discoverd is connect-only. Once it connects something, it never disconnects it in response to DLP changes. There is no logic that decides a subsystem dropped out of the Discovery Log Page and should be torn down. The only disconnects it causes are a systemctl stop and cleanup of a controller the kernel already removed. systemctl stop covers shutdown and a manual stop. This is a deliberate simplification. It avoids the whole class of connect/disconnect ordering bugs. The cost is that it does not implement TP8010 Fabric Zoning. That is where a Centralized Discovery Controller tells the host a subsystem should be disconnected.

nvme-stas is a separate project. It does implement that stateful reconciliation. It also implements TP8009 zeroconf (mDNS) discovery. It does this through its own daemons, stafd and stacd. nvme-discoverd and nvme-stas can both run on the same host. They coordinate through the NVMe-oF ownership registry and the system-wide exclusion list. Neither one touches a connection the other one owns.

Current limits

• No mDNS/DNS-SD discovery yet. Only static configuration, NBFT, Discovery Log Page referrals, and Fibre Channel discovery are supported.
• Not built by default. It can be installed side by side with the legacy udev/systemd autoconnect mechanism. The two are not meant to be relied on together. They overlap. Both react to the same events. Both may try to connect the same target at once. It is not established which one reacts faster and wins that race.

Optional today is not permanent. The legacy udev/systemd autoconnect mechanism will eventually be deprecated and removed. Once that happens, nvme-discoverd (or a successor covering the same job) becomes the only way to autoconnect NVMe-oF targets on Linux. It stops being optional. No date is set for that.

See also

• How to set up NVMe-oF autoconnect
• NVMe-oF Persistent Discovery Controllers (PDC)
• nvme-stas
• nvme-discoverd's own README, for source layout and design detail beyond this page