Here is an Operational Risk that should be mitigated with an update of your Operational Procedures and Administrator training/awareness. This exact issue impacted my organisation recently.
Windows Server 2012 and Windows 8 now process NMIs (Non-Maskable Interrupts) differently from previous versions. NMI processing is now hard-coded and cannot be modified, as compared to previous versions (by setting the Registry key “NMICrashDump”).
Where is the risk? When your administrators generate the system logs for a responsive VM via the vSphere C#/Web Client, there is a “Send_NMI_To_Guest” sub-option to the “HungVM” option (should only be used for unresponsive/hung VMs). If your administrators have been in the habit of selecting these options due to misunderstanding or by mistake, then these VMs will be reset for Windows Server 2012 and Windows 8 Guest Operating Systems.
In previous versions, this setting would only reset the Guest OS if the default “NMICrashDump” registry value had been changed. That is, you were avoiding a responsive VM reset even though you were selecting the wrong options.
Not a big deal in a Test and Development environment, but a major issue for Business Critical Applications.
What are the steps of this process? In the vSphere C# client: Highlight the VM under investigation, Select File, Export, Export System Logs.
In the Export System Logs window, make sure the “HungVM” options and sub-options are DESELECTED (unless you want to perform a crash log collection of a HUNG VM).
vcdx133.com 