[ANNOUNCE] nvme-stas 3.0
Belanger, Martin
Martin.Belanger at dell.com
Tue Sep 8 03:20:23 PDT 2026
nvme-stas 3.0 is out. It requires libnvme 3.0 and nvme-cli 3.0, it is
a non-backward-compatible release, and it is worth a few words on why
it looks the way it does.
For anyone who has not run into it: nvme-stas is a pair of systemd
daemons for NVMe-oF hosts. stafd (STorage Appliance Finder) finds
Discovery Controllers, over mDNS or from configuration, and reads
their discovery log pages. stacd (STorage Appliance Connector) takes
what stafd found and manages the I/O controller connections. It
implements TP8009 and TP8010 -- the parts of NVMe-oF discovery that
need a host to hold state and react to events over time, which a
one-shot command cannot do.
nvme-stas started life as the only fully automated -- zeroconf --
connection manager on an NVMe-oF host. Connections could always be
made by hand with the CLI, and udev rules could automate part of it,
but nothing else went out, found controllers, and connected to them on
its own. stas did try hard to tell its own connections from everybody
else's by keeping a state table under /run and consulted it before
disconnecting anything. That was fine while nothing else was running.
It stopped being fine as soon as somebody ran nvme connect by hand,
or booted from an NBFT or now ran nvme-discoverd.
A good part of this cycle went into fixing that, on both sides of the
fence. We also spent a lot of it trying to keep policy out of libnvme
and leave it with the tools that actually have an opinion: the CLI
and nvme-discoverd. That job is not finished. There is still policy
in there. And functions that quietly do a great deal on the caller's
behalf. However, the mechanism that came out of it is what matters
here. libnvme now has an ownership registry and a host-wide
exclusion list, and every NVMe-oF tool on the host shares both.
The upshot is that orchestrator coexistence is genuinely possible
now. Every connection record who made it. nvme-stas consults the
registry before adopting anything and leaves alone what belongs to
somebody else; nvme connect-all does the same. The exclusion list
(/etc/nvme/exclusions.conf, managed with nvme exclusion) is
honored by all of them, so an administrator says "not this one" once
and it holds everywhere. nvme-stas no longer has to shadow
nvme-cli's udev rules to stay out of their way, and that override is gone.
Configuration moved to /etc/nvme, and which controllers to connect to
moved out of stafd.conf/stacd.conf into /etc/nvme/nvme-stas.conf, in
libnvme's INI format, read by libnvme's own parser. Same format and
same parser as nvme-fabrics.conf, but a separate file, because a host
must be able to run nvme-stas and nvme-discoverd side by side
without either acting on the other's configuration. /etc/stas,
sys.conf and the stasadm tool are gone; the host identity comes from
/etc/nvme/hostnqn and /etc/nvme/hostid, like everything else.
To be blunt about the compatibility break: nothing from 2.x is
aliased. Configuration keys that moved or were renamed are not
accepted under their old names, and the D-Bus data format shared by
stafd, stacd, stafctl and stacctl is not compatible with 2.x. A stale
value is meant to fail rather than silently change behavior. Anyone
upgrading should read NEWS.md before restarting the daemons.
The numbers are modest next to nvme-cli's: 165 commits since v2.4.1
(2025-04-03), 120 files changed, +7,866 / -5,882 lines. Test coverage
is the part I am happiest with. The automated coverage run now stands
at around 95%, and runs the daemons against an /etc/nvme the script
writes itself, so a run no longer depends on whatever the machine
happens to have lying around.
Like Daniel, I leaned on AI heavily this cycle. Most of the above
would not have fit in the time otherwise.
Thanks to Daniel Wagner for the libnvme and nvme-cli side of all of
this, and for absorbing a steady stream of requests from the
nvme-stas end. Thanks also to everyone who filed a bug or tested
against nvme-stas without ending up in git log.
See https://github.com/linux-nvme/nvme-stas/blob/main/NEWS.md
for the full list of changes.
--
Martin
More information about the Linux-nvme
mailing list