Shared Disk Becomes Inaccessible in Guest OS After vMotion of MSCS Virtual Machine
search cancel

Shared Disk Becomes Inaccessible in Guest OS After vMotion of MSCS Virtual Machine

book

Article ID: 402005

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

Symptoms:

  • VMs are running on cluster vmdk enabled datastore.
  • After migrating Microsoft Cluster Service (MSCS) virtual machines from one ESXi host to another, the shared disk became inaccessible from within the guest OS.
  • Prior to vMotion, the disks were functioning normally. However, post-migration, the guest operating system was unable to detect the shared disks.
  • When the virtual machine was moved to a different host, the disk accessibility was restored.

Cause

The issue is caused by a persistent reservation (PR) key limitation on the storage array. Each host registers multiple keys per path for shared VMDK devices, and the total number of supported PR keys per device is limited to 160.When the VM is migrated to a new host, the new host attempts to register a key. If its key is not within the first 160 slots reported by the target, VMFS treats the reservation as lost, resulting in disk disconnection from the guest.

 In var/run/logvmkerne.log, you will see the below events
2025-05-30T11:56:20.260Z In(182) vmkernel: cpu2:2114958)FSS: 157: Reservation state of PM-DS-02 moved from Register In Progress to Reservation In Progress
2025-05-30T11:56:20.261Z In(182) vmkernel: cpu106:2098312)ScsiDevice: 10754: Set resv flag for device:naa.600009700001979xxxxxxxxxxxxx
2025-05-30T11:56:20.261Z In(182) vmkernel: cpu2:2114958)VSCSI: 10646: Registered SCSI-3 Persistent Reservation key (type WEAR) for datastore 633de175-b7a90cdc-f9b0-xxxxxxxxxxx
2025-05-30T11:56:20.261Z In(182) vmkernel: cpu2:2114958)FSS: 157: Reservation state of PM-Dx-xx moved from Reservation In Progress to Reserved
2025-05-30T11:56:21.227Z In(182) vmkernel: cpu106:2098312)VSCSI: 2742: handle 9080540124684303(GID:8207)(vscsi1:1):HB state change: HB_Loss -> HB_Ok
2025-05-30T11:56:21.238Z In(182) vmkernel: cpu52:2098839)NMP: nmpCheckForMatchingKey:1863: Target reported more keys (0xbc) than allocated slots: key 600a2b525000000
2025-05-30T11:56:21.238Z In(182) vmkernel: cpu52:2098839)ScsiDevice: 10672: VMFS notified as a result of WEAR reservation removal for device:naa.600009700001979028xxxxxxxxxxx. Reason: "Device Probe".

Resolution

Broadcom Engineering is aware of the current limitation regarding the number of Persistent Reservation (PR) keys supported per device and is actively working to increase this limit in future releases.

Workaround:

Example:

In a scenario where 12 hosts are accessing a shared datastore, and each host has 16 paths to connect to the device:

  • Each path consumes one registration key.

  • Therefore, the total key usage is:
    12 hosts × 16 paths = 192 keys,
    which exceeds the supported limit of 160 keys per device.

To mitigate the issue in such cases, consider either:

  • Reducing the number of hosts accessing the shared datastore (e.g., from 12 to 10 or 8),
    or

  • Reducing the number of paths per host, for example:
    12 hosts × 12 paths = 144 keys,
    which keeps the total within the acceptable threshold.