I'm installing Windows Server on a Cisco UCS blade with one virtual HBA. The HBA connects through one FC fabric to a Dell EMC XtremIO array, but the array presents the same boot LUN through two storage ports, so Windows Setup sees the LUN twice after the Cisco VIC fnic driver is loaded. The installation completes if I select one copy of the disk, but Windows fails on the first reboot with status 0xc0000185 and a message referring to ntoskrnl.exe.
The usual approach is to expose only one path during installation, boot Windows, configure MPIO/MSDSM, and then enable the additional paths. Unfortunately, I do not have administrative access to the MDS switches or the storage array, so I cannot change zoning or masking. I tried installing the Multipath-IO feature offline from WinPE with DISM, but the system still does not boot. It may be that MPIO is not configured to claim the disk early enough, or that the XtremIO hardware ID has not been added to the offline installation.
Is there a supported offline registry or MPIO configuration that makes MSDSM load early enough to claim this FC boot disk? If not, is cloning a disk from another server that already boots from SAN a practical workaround?
3 Answers
Cloning another server is unlikely to solve this. The cloned system would still encounter the same two visible paths, fabric configuration, WWPNs, and boot-policy behavior on the destination blade. Boot-from-SAN normally requires the target LUN to be presented in a way the installer and Windows boot stack can handle, followed by a supported MPIO configuration for that array and driver combination.
The FC boot paths need to be configured correctly in the UCS boot policy and, where applicable, in the virtual HBA or adapter boot settings. The firmware must present a valid boot target and consistent path priority before Windows takes over. This is different from simply selecting a disk in Windows Setup. It would be best to verify the UCS boot-from-SAN design with the UCS and storage vendors rather than adding arbitrary offline registry entries.
The duplicate disks are caused by the two array ports being visible through the single vHBA, not by two separate LUNs. Firmware sees one boot target, but once fnic loads, Windows sees both FC paths. If you cannot temporarily change zoning or storage masking, the remaining fix has to come from a documented UCS, XtremIO, Cisco VIC, and Windows MPIO boot-from-SAN procedure. Installing the MPIO feature offline alone does not guarantee that MSDSM is configured to claim the boot LUN early in startup.
The UCS boot order is already configured, and the firmware can boot when only one target is exposed. The failure happens after fnic loads and Windows discovers the second path, so this does not appear to be a simple firmware boot-order problem.