StarWind Software

Validated with these versions as of 2026-10-06 (this lab only):

Windows Server 2019 Datacenter Evaluation 1809
StarWind NVMe-oF Initiator: Controller / miniport 2.0.0.729
VAST: 5.5.1. - Lab cluster (block NVMe/TCP; two mapped volumes per host)
Mellanox CX-6 Driver=2.42.22627.0

Summary
On domain-joined hosts, after reboot (including a clean domain rejoin), one of two VAST NVMe/TCP volumes fails to appear in Get-Disk / mpclaim, while StarWind reports Attached Controllers: 32 of 32. Every time this happened in lab, Device Manager (Show hidden devices) showed a grey NVMe VASTData Multi-Path Disk Device, and Get-PnpDevice reported Problem : CM_PROB_PHANTOM (Code 45) for that Multi-Path InstanceId (missing volume’s EUI). In workgroup, both volumes stay present across reboots. Leaving the domain heals the host (with or without manually uninstalling the phantom first).

Windows Event Viewer Event ID 47:
An error occurred while the system tried to claim a Multipath I/O (MPIO) path. The location of the failing path is described by the SCSI address (4, 0, 5, 1) (Port, Bus, Target, Lun). To resolve this issue, either reboot the system, or show hidden devices in Device Manager and try uninstalling the specific disk device indicated above, and then rescan for hardware changes.

VAST Cluster:
No alarms or alerts visible - all block components report "ok".

Welcome to StarWind forum. Please try:
1. Update to the latest build of NVMe-oF.
2. Try using non-management (i.e., dedicated data network) network for connecting storage.
3. Check Group policies/Firewalls.

When joined to WORKGROUP - i.e. no domain join everything works perfectly.

Join Domain, reboot - path goes phantom - every time
Leave Domain, reboot, path comes back - every time

Could it be a race condition introduced by the domain join on reboot?

This is the topology - single cx6 - dedicated network to VAST