The issue occurs when a virtual machine configured with Physical bus sharing issues a SCSI-2 command.
From /var/core/vmkernel-zdump, we can see back trace similar to:
YYYY-MM-DDTHH:MM:SS.MS cpu95:165224071)Backtrace for current CPU #95, worldID=165224071, fp=0xXXXXXXXXXXXXXXXX
YYYY-MM-DDTHH:MM:SS.MS cpu95:165224071)0xXXXXXXXXXXXXXXXX:[0xXXXXXXXXXXXXXXXX]MCSLockWork@vmkernel#nover+0x8
YYYY-MM-DDTHH:MM:SS.MS cpu95:165224071)0xXXXXXXXXXXXXXXXX:[0xXXXXXXXXXXXXXXXX]VSCSI_CmdPermittedOnPersResv@vmkernel#nover+0x121
YYYY-MM-DDTHH:MM:SS.MS cpu95:165224071)0xXXXXXXXXXXXXXXXX:[0xXXXXXXXXXXXXXXXX]VSCSI_FSCommand@vmkernel#nover+0x1119
YYYY-MM-DDTHH:MM:SS.MS cpu95:165224071)0xXXXXXXXXXXXXXXXX:[0xXXXXXXXXXXXXXXXX]VSCSI_IssueCommandBE@vmkernel#nover+0x35
YYYY-MM-DDTHH:MM:SS.MS cpu95:165224071)0xXXXXXXXXXXXXXXXX:[0xXXXXXXXXXXXXXXXX]VSCSIExecuteCommandInt@vmkernel#nover+0x4e7
YYYY-MM-DDTHH:MM:SS.MS cpu95:165224071)0xXXXXXXXXXXXXXXXX:[0xXXXXXXXXXXXXXXXX]PVSCSI_ProcessRing@vmkernel#nover+0x118
YYYY-MM-DDTHH:MM:SS.MS cpu95:165224071).[45m.[33;1mVMware ESXi 7.0.3 [Releasebuild-20036589 x86_64].[0m
SCSI-2 reservations are not supported on ESXi.
When such an unsupported command is issued, the ESXi storage stack mishandles the request, causing a purple diagnostic screen (PSOD).