StarWind NVMe-oF Initiator (free) connecting but hanging

[fleymi]

Hello everyone! I am a recent comp sci graduate interested in setting up a homelab at my house. I'm using the StarWind NVMe-oF Initiator GUI (v2.0.0.729) and am having problems accessing a namespace after connecting successfully over NVMe/TCP.

My initiator is Windows 10 Pro and my target is Debian 13 using the linux kernel 7.1.3 nvmet. I setup the linux NVMe-oF target manually with Bash and the kernel's nvmet / nvmet-tcp modules without using nvme-cli.

The initiator successfully discovers the target and connects over TCP with StarWind reporting the target status as "has connections".

However once I connect windows explorer freezes, disk management freezes when enumerating disks and task manager shows the exported NTFS disk, but remains at 100% active time with 0 KB/s read, 0KB/s write and 0 ms latency.

When I try disconnecting from the target in StarWind it remains on "Disconnecting..." indefinitely until the initiator is restarted.

On the linux target I made sure the namespace exists and is enabled, the subsystem is linked under ports/1/subsystems and the Host NQNs have been configured and linked correctly. I have allow_any_host disabled. Discovery and connection both succeed.

To make it work I have tried both StarWind available I/O presets and verified connectivity using onboard Intel l225-V NICs through an unmanaged 2.5GbE switch. I plan to migrate to a managed L2 switch later, but I would expect this test configuration to function first.

Has anyone seen this behavior with recent StarWind NVMe-oF initiator releases? I found a few older posts suggesting that v1.9.0.596 (rev 597) may avoid similar hangs. Is this a known compatibility issue with Linux nvmet, or is there another configuration I should try? I didn't install Windows Multipath I/O (MPIO), is that necessary?

[yaroslav (staff)]

Welcome to the StarWind forum.
If you have access to GUI, I think you are using Trial or NFR. Please reach out to the person who shared the key with you. Also, please check if your license is still valid.
How many devices are backing that initiator?
Please check
-MTU values (set to 1514 on the Initiator host and 1500 on target)
-Drivers and Firmware for your Initiator host NIC.
-Try without NIC teaming.
-Try older version of the initiator.
-Try connecting the target and initiator host directly.

I didn't install Windows Multipath I/O (MPIO), is that necessary?

You need multipath only where you have the same target accessible over multiple links. Say, you have redundant network communications (e.g., multiple IP addresses) or highly available storage setups.

[wilfredgamble]

I’d first suspect a compatibility or protocol issue rather than MPIO. Since discovery and the NVMe/TCP connection succeed but Windows hangs as soon as it tries to enumerate the namespace, I’d focus on the namespace exposure and I/O path rather than the network itself.
If possible, I’d test with a known-good Linux NVMe-oF initiator against the same target. That would help determine whether the Debian nvmet configuration is actually serving I/O correctly. I’d also check the kernel logs on the target (dmesg/journal) while Windows attempts to access the disk for any NVMe/TCP or namespace errors.
MPIO generally isn’t required just to establish a single NVMe/TCP path, so I wouldn’t install it solely to fix this particular hang. Testing an older StarWind initiator version could be worthwhile too, especially since you’ve already found reports of similar behavior with newer releases.

[fleymi]

Hello, sorry for the late reply...

I checked the license XML. It shows:

FreeLicense = 1
GuiManagementAllowed = 1
GuiMonitoringAllowed = 1
LicenseType = 1002
expdate = 0

It also explicitly includes the nvmfinitiator plugin.

Could you please confirm what LicenseType 1002 represents and whether this license is valid for my NVMe-oF Initiator 2.0.0.729 setup? In particular, I'd like to confirm whether there are any licensing restrictions that could affect the initiator's ability to connect to and expose the NVMe-oF target to Windows.

- I have a single initiator (one pc) connecting to the NVMe-oF target over a single 2.5GBe link.
- When setting the initiator MTU value to 1514 it caused my initiator to automatically detect the drive on connection instead of me having to run a command or opening Disk Management. But it still remains at 100% active time with 0 KB/s read, 0KB/s write and 0 ms latency.
- The drivers for my initiator host NIC needed an update but updating did not help.
- I never setup NIC teaming on this setup.

-Try older version of the initiator.

-Could I have access to a download for an older version please? Such as a v1.9.0.x?
-I tried using a different switch (TRENDnet TEG-S50204) but the issue persists.

If possible, I’d test with a known-good Linux NVMe-oF initiator against the same target.

Great Idea! I have a Debian Bullseye mini pc I can try it with.

[yaroslav (staff)]

The key you have is only for StarWind VSAN (i.e., target), not initiator; please request the initiator key from website or your account manager. nvmf is a rudiment; ignore it.
Also, it will not give NVMe-oF functionality; you will need a new key if you would like to have one. It is paid only feature. Alternatively, you can use tech preview key (trial) that is not convertible to free: https://www.starwindsoftware.com/techni ... ew-program