I know System requirements for System Center Virtual Machine Manager (https://docs.microsoft.com/en-us/system-center/vmm/system-requirements?view=sc-vmm-2019) does not list Server 2012 R2 Hyper-V as being a supported Hyper-V host in a VMM 2019 environment. And there's a difference between "not officially supported" and "officially not supported". VMM 2019 simply does not allow you to install its agent on a Server 2012 R2 Hyper-V server:

Error (20523)
The verslon of the Windows operating system on the computer xxxxx is not supported for a host.

Recommended Action
Upgrade the operating system to Windows Server 2016 or a later supported version, and then try the operation again.

So if you're planning to upgrade from a Hyper-V 2012 R2 environment to Server 2019: you can't do it using VMM. We're adapting our plans using an intermediate 2016-environment, but that's not easy.

Funny thing: ESXi 5.1, which is even older than Hyper-V 2012 R2 IS supported... So please, Microsoft: support your own stuff if you want your customers to remain loyal and make it possible to migrate from a Server 2012 R2 Hyper-V environment to a Server 2019 Hyper-V environment using VMM.

Currently VMM 1807 does not support using a Fabric defined WSUS Update server for updating nodes of a S2D Hyper-converged infrastructure cluster; in fact there within Microsoft VMM documentation there is a "Note" that explicitly states the following:
“..Note that you cannot update servers part of a Storage Spaces Direct cluster (either hyper-converged or disaggregated) using VMM and trying to patch these using VMM may cause data loss.”

Yes, MAY CAUSE DATA LOSS!!

First idea is that this should not be a mere Note, it should be flagged as a WARNING-DATA LOSS IS POSSIBLE.

Second, how does the VMM group consider managing the update compliance status of these servers? If VMM is THE Microsoft virtualization host management solution and we are to use it as such, how is it that we cannot use the Fabric defined WSUS? Is there a "recommended practice" ?

Afraid to hear that an additional WSUS would be the answer; Current guidelines call out a Configuration Manager WSUS for VM's, and a VMM Fabric WSUS for Hosts. So if yet another is required...

Since UR5 VMM polls the Hyper-V hosts every half hour for the DHCP agent version. The Win32_Product WMI class is used for this.

Because this class is used, every half hour MSIEXEC processes will run consistency and reconfiguration steps for all MSI packages on all Hyper-V hosts. This results in a flood wave of Application Event ID 1035 occurring every 30 minutes.

The overall impact I cannot oversee as I don't know what is actually reconfigured.
You can validate VMM is the cause of these calls by enabling WMI tracing.

Microsoft itself actually advises (https://support.microsoft.com/en-us/kb/974524) not to use this class because it does more than just list installed products. It’s an old KB but it still applies.

A quote from the KB:
If you have an application that makes use of the above class, please contact the vendor to get an updated version that does not use this class.