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.