All ESXi hosts in vSAN ESA Purple Screen
Article ID: 404789
Updated On:
Products
Issue/Introduction
Hosts experience Purple Screen Fault events upon boot and regular operation. The backtrace of the fault appears as:
2025-06-11T18:48:52.828Z cpu68:2133898)Backtrace for current CPU #68, worldID=2133898, fp=0x0
2025-06-11T18:48:52.828Z cpu68:2133898)0x453a6b89bad0:[0x42000cf7be80]PanicvPanicInt@vmkernel#nover+0x20c stack: 0x3567dfa, 0x42000cf7be80, 0x0, 0x420000000001, 0x42000cf7be80
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89bb80:[0x42000cf7c5fc]Panic_NoSave@vmkernel#nover+0x4d stack: 0x453a6b89bbe0, 0x453a6b89bba0, 0x0, 0x42000f224b00, 0x2157
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89bbe0:[0x42000cf7c7e1]Panic_OnAssertAt@vmkernel#nover+0xba stack: 0x215700000000, 0x42000f224b00, 0x42000d50bf02, 0x42000d51e109, 0x42000d52a810
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89bc60:[0x42000d4a85e7]Int6_UD2Assert@vmkernel#nover+0x260 stack: 0x0, 0x0, 0x0, 0x42000d4a10c7, 0x0
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89bc90:[0x42000d4a10c6]gate_entry@vmkernel#nover+0xa7 stack: 0x0, 0x1, 0x120000, 0x0, 0x45dbdf627e98
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89bd50:[0x42000f0fdbaf][email protected]#0.0.0.1+0x33 stack: 0x1, 0x42000f0ee5e2, 0x4321b1214d58, 0x453a6b89bdd0, 0x45daf722aac8
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89bd70:[0x42000f0ee5e1][email protected]#0.0.0.1+0x18a stack: 0x45daf722aac8, 0x90000051962061, 0x45db60745548, 0x0, 0x0
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89be40:[0x42000f0eea0a][email protected]#0.0.0.1+0x15b stack: 0xe, 0x4321b1214e28, 0x4321b1209b88, 0x45db60745320, 0x4321b1213df8
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89be90:[0x42000f0f3f6f][email protected]#0.0.0.1+0x28c stack: 0x38, 0x42000f0964fb, 0x0, 0x3800000000, 0x0
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89bf00:[0x42000f0f4038][email protected]#0.0.0.1+0x65 stack: 0x0, 0x42000f095bac, 0x432441a46df8, 0x4321b1201268, 0x0
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89bf50:[0x42000f095be0][email protected]#0.0.0.1+0x35 stack: 0x0, 0x42000f095bac, 0x67, 0x432441a46df8, 0x67
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89bfa0:[0x42000cf9fae4]vmkWorldFunc@vmkernel#nover+0x31 stack: 0x42000cf9fae0, 0x0, 0x453a6b89f000, 0x453a66e9f100, 0x453a6b89f100
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89bfe0:[0x42000d4dc88e]CpuSched_StartWorld@vmkernel#nover+0xbf stack: 0x0, 0x42000cf44fb0, 0x0, 0x0, 0x0
2025-06-11T18:48:52.829Z cpu68:2133898)0x453a6b89c000:[0x42000cf44faf]Debug_IsInitialized@vmkernel#nover+0xc stack: 0x0, 0x0, 0x0, 0x0, 0x0
Environment
vSAN 8.x
Cause
vSAN cluster object is not removed from vCenter before rebuilding vSAN hosts for repurposing in the vSAN cluster. This can cause a conflict between the vCenter and Hosts on the cluster encryption status.
In rare circumstances, Hosts are unable to load their local configuration for encryption - as a result this data is populated from vCenter which generally just re-provides the same information the cluster has - however once the above conflict exists and vCenter and Hosts are not in agreement... a Purple Diagnostic screen may result when settings from vCenter are incorrectly applied to vSAN Hosts.
Resolution
Recreate a cluster that had inconsistent encryption status
- Wipe clean (delete all VMs, remove storage pools for ESA & DG’s for OSA with no action)
- Put the host in the MM mode, move it out of the cluster. Repeat for all hosts in the cluster.
- Delete the current cluster
- Validate config store configuration on host by running the command. (The expected dek_generation_id should be 0)
- configstorecli config current get -c 'vsan' -g 'system' -k 'vsan' -p 'encryption'
- Ensure KMS (or similar vendor) has been configured properly beforehand
- After recreating the cluster in the VC, firstly move all hosts into the cluster, then enable ESA & encryption.
- After enabling encryption, check the configstore configuration again to make sure the values are correct, e.g., the dek_generation_id should now be 1
Additional Information
It is recommended that any time a cluster is intended to be completely rebuilt from scratch, that the cluster object is deleted and recreated from within vCenter (as opposed to just removing all hosts and recreating storage pools or reinstalling ESX) to ensure the vCenter state is pristine.
Feedback
