SCVMM (VMM) & S2D should support cross-cluster migration of highly available VMs.

Migrations of highly-available VMs from one cluster to another while using S2D and SOFS as a storage solution (NOT hyper-converged) should be supported by VMM.

VMM has built-in functionality to allow migration of a VM from one cluster to another.

This does NOT work with HA VMs when your storage solution is SOFS on S2D. The VM will be placed in pause-critical, effectively a failed migration.

I believe this is a shortcoming on the part of Failover Clustering not properly handling storage communication, but not sure as this action isn't able to be automated outside VMM.

I have now tested this in Windows Server 2016, 2019, with VMM 2016 and 1807 and it doesn't work.

The VM is stopped in a 2016 environment and put into a paused-critical state in 2019. This appears to be due to some unseen error and the default AutomaticCriticalErrorAction, but I'm not sure.

This is functionality which worked under 2012 but S2D wasn't an option, so my guess is this is a failing as a combination of VMM, failover clustering and S2D w/SOFS as storage.

Note that this DOES WORK ONLY when migrating TO the Current Host Server (as shown in FOC Manager) on the target cluster.

Using a Logical Switch object for deployment in a cluster is a time saver and above all mitigates or removes human error by eliminating repetitive tasks. Problem arises AFTER the Logical Switch has been deployed and a modification/change is required, ex; if an additional vNIC is required upon adding it within the Fabric/Logical Switch it is NEVER flagged as non-compliant, hence can never be Remediated. If managing many servers and such a change is required, the only way is to either manually modify each server or create an additional Logical Switch, then remove/add logical switches. This is by no means the proper manner to address a networking change from a "management console".

When creating a VM from template in SCVMM, the disk name (vhd file) is named the same as the VM name. 1. This makes it match the directory the vhd file is in. 2. Saves a step which if it is missed creates a VHD the same as VHD stored in the library server ("bad"). 3. This will save "errors" if people forget to rename the VHD file prior to creating the VM.

Yes, yes automation with PowerShell or some other product can address this but this should be the default behavior in SCVMM. As if you just spin up a bunch of VM's they all have the same name for the VHD file, which can be confusing. I would think this feature would not be that hard to add during VM creation using the SCVMM template. In a way the SCVMM template does it already for the name of the VM. Just use that var in creating the VHD as well.

In our setup a Hyper-V cluster does have it's own SOFS cluster, we have several of those clusters. So a one-to-one relationship is established between a Hyper-V Cluster and a SOFS Cluster.
SCVMM 2016 does not allow for VM's to be live-migrated between Hyper- V clusters while this was possible using SCVMM2012R2. This functionality disappeared magically in 2016. We really need this since we migrate VMs regularly between clusters.
For example; we do have local clusters and stretched clusters, we need to live migrate VMs between those for distributing load and SLA levels. The loss of this functionality is documented nowhere and we really need this!

VMM Allows you to create shares that are hidden by adding a $ to the end of the name. It works fine and allows you to use them.

However, if you remove one of these shares (ie, retire it) all of the hidden shares disappear. This is because the discovery gets run and it incorrectly assumes anything with a $ at the end is special and needs to be filtered out.

At this point, all of your VMs on these shares go into an unsupported state and you lose the ability to manage VMs using VMM.

Please allow VMM to utilize hidden shares (why wouldn't you? Hyper-v and Failover Cluster Manager have no problems with them!) or prevent the user from creating them in the first place!

We have specific properties that we pass up and down to the VM via KVP, such as 'managed custom properties' to add a 'add existing kvp attribute'. These can then be selected to show on the main view.

Currently, we have a non-trivial WMI script that queries and updates same-name VMM custom attributes with this data so we have a single pane of glass for these values

For example, typically for us we bring drive usage (to compare against VHDx size), escalation manager, and particular system component information up (particular result of a SQL query) to view within VMM so they can be actioned directly rather than swapping to other views or dashboards.

We also pass down certain information, like VMMid (as we have clone VMs, along with automatic hostname and vmname, etc) - obviously scripted in the background, but useful to confirm it had been passed in or setable via trivial scvmm commandlets.