Dell EMC VxRail: Host unexpectedly reboots when collecting support bundle with vSAN iSCSI Target owner host

Host hits an unexpected reboot and generate a PSOD when collecting support bundle with an iSCSI Target owner host.

Sample logs before Panic in vmkernel.log:

2019-02-24T06:46:33.773Z cpu36:4863200)vit: VitPRInfoFileOpen:553: Opened PR info file /vmfs/volumes/vsan:528215e0f741636b-6a9e6ad61d6c2ccc/8d916b5c-4ed5-361e-718e-6805ca7f6d1a/.7f9e6b5c-062f-3cb3-70e0-6805ca7f6d1a.vmdk.pr (handle = 33790184).
2019-02-24T06:46:33.776Z cpu8:4863200)vit: VitPRInfoFileClose:631: Closed PR file 33790184 successfully.
2019-02-24T06:46:33.838Z cpu8:4863200)vit: VitPRInfoFileOpen:553: Opened PR info file /vmfs/volumes/vsan:528215e0f741636b-6a9e6ad61d6c2ccc/08916b5c-c24f-3856-96e3-6805ca7f6d1a/.c6956b5c-dc95-c06e-5cd6-6805ca7f68fa.vmdk.pr (handle = 43817200).
2019-02-24T06:46:33.842Z cpu8:4863200)vit: VitPRInfoFileClose:631: Closed PR file 43817200 successfully.
2019-02-24T06:46:35.152Z cpu36:2100043)Backtrace for current CPU #36, worldID=2100043, fp=0x430c05b95f00
2019-02-24T06:46:35.152Z cpu36:2100043)0x451b06e9bca0:[0x41801a90ac15]PanicvPanicInt@vmkernel#nover+0x439 stack: 0x451a00000001, 0x41801ac3f0d8, 0x451b06e9bd48, 0x0, 0xb0f8c400000001
2019-02-24T06:46:35.152Z cpu36:2100043)0x451b06e9bd40:[0x41801a90ae48]Panic_NoSave@vmkernel#nover+0x4d stack: 0x451b06e9bda0, 0x451b06e9bd60, 0x1ddb53dea958, 0x24, 0x200b4b
2019-02-24T06:46:35.152Z cpu36:2100043)0x451b06e9bda0:[0x41801a82e006]LockCheckSelfDeadlockInt@vmkernel#nover+0x5b stack: 0x45a3bf5ff7c9, 0x41801a911260, 0x0, 0x8b, 0xffffffffffffffff
2019-02-24T06:46:35.152Z cpu36:2100043)0x451b06e9bdc0:[0x41801a91125f]MCS_LockWait@vmkernel#nover+0x104 stack: 0xffffffffffffffff, 0x451b06ea3100, 0x1, 0x41801ab082e6, 0x1
2019-02-24T06:46:35.152Z cpu36:2100043)0x451b06e9be90:[0x41801a91172a]MCSLockWithFlagsWork@vmkernel#nover+0x23 stack: 0x1cc0824217db8, 0x451b06e9bf40, 0x41801bb0e0bb, 0x4317a3c27d58, 0x1cc0824218073
2019-02-24T06:46:35.152Z cpu36:2100043)0x451b06e9bea0:[0x41801a83e567]vmk_TimerIsPending@vmkernel#nover+0x30 stack: 0x41801bb0e0bb, 0x4317a3c27d58, 0x1cc0824218073, 0x41801bb0e81a, 0xffffffffffffffff
2019-02-24T06:46:35.152Z cpu36:2100043)0x451b06e9bed0:[0x41801bb0e819]VSANServerMainLoop@com.vmware.vsanutil#0.0.0.1+0x972 stack: 0x4317a3c27e28, 0x3a00000000, 0x451b00000000, 0x4317a3c27ee8, 0x8
2019-02-24T06:46:35.152Z cpu36:2100043)0x451b06e9bf90:[0x41801a9281fe]vmkWorldFunc@vmkernel#nover+0x4f stack: 0x41801a9281fa, 0x0, 0x451ace2a3100, 0x451b06ea3000, 0x451ace2a3100 

WSFC (Windows Server Failover Cluster) is configured on vSAN iSCSI Target LUNs, or vSAN iSCSI LUNs are used using persistent reservations. 
When collecting a support bundle using vm-support, it encounters a PSOD on iSCSI Target owner host. The iSCSI kernel grabs a spin lock, then opens a PR(persist reservation) file for a LUN and read content, and the world is non-blocked during open file, which is not recommended per best practice.

This issue has been fixed in vSAN6.7U2. -> VxRail 4.7.200

Workaround: This issue only happens when collecting support bundle on vSAN 6.7U1 with WSFC deployed for vSAN iSCSI Target service. 
 

• Place the server into Maintenance Mode before collecting, and move out of MM after collection is complete.