Windows Server Failover Cluster (WSFC) VMs fail to power on with error "Module DevicePowerOn power on failed" after storage migration to a different storage array

Products

• VMware vCenter Server

Issue/Introduction

Symptoms

• When attempting to power on virtual machines (vm1 and vm2) configured in a Cluster-Across-Box (CAB) setup using Windows Server Failover Clustering (WSFC), the operation fails.

  Unable to create virtual SCSI device for scsi1:0, '/vmfs/volumes/6a0ca3d9-########-####-############/vm1/vm1_2.vmdk' Failed to start the virtual machine. Module DevicePowerOn power on failed.

• Virtual disks shared between the VMs are configured as Thick Provision Eager Zeroed and the datastore has the Clustered VMDK feature enabled.

• SCSI bus sharing is set to Physical.

• The issue started immediately following a storage migration activity where the shared disks were detached and reattached on a new storage array.

  Note: If SCSI bus sharing is temporarily changed to Virtual, the VMs power on successfully and clustering functions. However, this is an unsupported configuration for Cluster-Across-Box deployments.

Environment

VMware ESXi 8.x

VMware ESX 9.x

Cause

The issue is caused by an underlying storage array's inability to process hardware-accelerated locking commands.

When the SCSI controller bus sharing is set to Physical, the ESXi host sends SCSI XCOPY commands directly to the storage array to claim and initialize the shared cluster space. While the new storage array accepts the command, its internal processors fail to execute the lock across the cluster volume.

When the setting is incorrectly changed to Virtual, ESXi stops sending these XCOPY commands to the SAN and handles locking internally. This masks the problem and allows the VM to boot, but leaves the cluster in an unsupported state.

Cause Validation:

Reviewing the /var/run/log/vmkernel.log file on the ESXi host during the power-on attempt reveals COPY TARGET DEVICE NOT REACHABLE errors on the device backing the clustered VMDK volume

2026-05-24T03:36:05.590Z In (182) vmkernel: cpu97:2098313) ScsiDeviceIO: 4697: Cmd (0x45ba44e34a00) Oxfe, CmdSN 0x9e55ae from world 2099559 to dev "naa.600##########################" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0xa 0xd 0x2
2026-05-24T03:36:05.5912 In (182) vmkernel: cpu97:2098313) ScsiDeviceIO: 4697: Cmd(0x45ba44f4f600) Oxfe, CmdSN 0x9e55ac from world 2099559 to dev "naa.600##########################" failed H:0x0 D:0x2 P:Ox0 Valid sense data: 0xa 0xd 0x2
2026-05-24T03:36:05.5912 In (182) vmkernel: cpu97:2098313) ScsiDeviceIO: 4697: Cmd (0x45ba2d342ec0) Oxfe, CmdSN 0x9e55b2 from world 2099559 to dev "naa.600##########################" failed H:0x0 D:0x2 P:Ox0 Valid sense data: 0xa 0xd 0x2

The sense data 0xa 0xd 0x2 translates directly to COPY TARGET DEVICE NOT REACHABLE, confirming the array's inability to route or complete the XCOPY operation across the cluster volume.

Resolution

Contact your storage array vendor's support team to investigate why the new array processors are unable to execute XCOPY/locking commands on the newly migrated cluster volume.