Any ideas for a Hyper-V cluster that broke after a rolling upgrade?

I’d pause any more WMI repair commands until you have a clear picture of the damage. Capture the exact error messages and timestamps, then collect cluster validation results and relevant cluster, Hyper-V, and WMI event logs from every node. Check whether the failures line up with one node or started across the cluster after the same change.

WMI problems can affect several management tools at once, but that does not prove WMI is the only cause. Validate domain connectivity and cluster health separately, and keep a backup and recovery plan handy before changing providers or cluster resources.

If the evidence points to one bad node, rebuilding that node may be a cleaner recovery than repeatedly trying repairs. Evacuate or move its workloads where possible, remove it from the cluster using the documented process, reinstall and configure it, then validate it before returning it to service. Don’t move on to another node until the first one is stable.

That’s a recovery option, not a diagnosis. With shared SAN storage and cluster shared volumes, verify the storage, multipath, and cluster configuration before attempting any migration or rebuild. A mistake there can make a bad situation worse.

In-place rolling upgrades can be supported and still go wrong in a particular environment. I’d compare firmware, drivers, storage presentation, and multipath settings against the requirements for the new OS, especially if those were changed or updated around the upgrade. Also check whether the WMI repair advice came from a vendor procedure that matches this hardware and software combination.

Since one node reportedly cannot provide logs, note that limitation rather than filling in the gaps with guesses. If the cluster is production-critical and the failures persist, get a Windows Server or hardware vendor specialist to review the collected logs before making broad changes.