SPP 2019.03.1 application removes HyperV Clustered Virtual Switch Configuration

[Monkfish_1]

This is to highlight an issue I experienced with SPP 2019.03.1 in the last few weeks, I hope this helps someone who has been scratching their head and also perhaps HPE will do something about it.

The configuration is Microsoft HyperV cluster, SCVMM 2012, Hardware: 3x BL460c Gen9 with Server 2012 R2 as HyperV nodes. I don't need to expand on the rest of the physical infrastructure as the problem, in my opinion, seemed to be caused entirely by an update included in the SPP.

I put the first node out of service, applied Windows updates, shut it down, restarted and then applied SPP 2019.03.1 through the operating system via the iLO virtual drive mounted ISO. Once complete the server was rebooted again and initially seemed okay once maintenance mode was turned off, however after about a minute a yellow triangle appeared next to the cluster in SCVMM. There were plenty of "Error 2915" failures trying to live migrate VMs to the HyperV node. Investigating the errors revealed that the Virtual Switch Configuration for the updated node was corrupt. After two days of investigation I found this:

https://help.flexxible.com/how-to-resolve-the-scvmm-agent-problem

Which showed a similar issue with SCVMM 2016 and how to restore the WMI configuration.

To check if the WMI VMM classes existed I entered the following line in an Administrator elevated powershell:

Get-CimClass -Namespace root/virtualization/v2 -classname *vmm*

Which returned nothing. I then confirmed the existence of the appropriate ",mof" files in the Server 2012 R2 filesystem and modified the 2016 Powershell scripts accordingly  and executed them in an Administrator elevated Powershell:

Mofcomp.exe "C:\Program Files\Microsoft System Center 2012 R2\Virtual Machine Manager\setup\scvmmswitchportsettings.mof"　

Mofcomp.exe "C:\Program Files\Microsoft System Center 2012 R2\Virtual Machine Manager\DHCPServerExtension\VMMDHCPSvr.mof"

After executing these commands, executing the Get-CIMclass script again revealed a healthy collection of VMM WIMI classes. Without doing anything else, the HyperV cluster status changed to "OK" and VMs could be live migrated to it with no error.

On the next node to see if the problem was due to the mix of Windows updates and SPP 2019.03.1, I applied the SPP first, with all options. Before I commenced I carried out the Get-CimClass script and confirmed the VMM WMI classes were in place. After I had completed the SPP update, the classes had gone. These were restored using the above procedure.

On the third node, I applied the NIC drivers on their own, rebooted the node, checked Get-CimClass again, then applied the rest of the SPP; prior to rebooting on completion I checked the Get-CimClass again and found that the VMM classes had been removed. Before restarting I re-applied the MOF files as before. After reboot the node performed normally.

If I had more nodes to play with I reckon I could isolate the package that is causing the problem.

[Jimmy Vance]

Please open a ticket with HPE support so this issue can be tracked and worked by the support organization

[brownfc55]

I had the same issue after installing the SPP on all 4 nodes in our Hyper-V 2012 Cluster. Following those steps are resolved the issue.