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!

When using VMM with SelfService Users (SSU) the SSU can only see the virtual machine status (VMS) – the user is not able to see the host status itself. I.e. when the host is “host not responding” the SSU will see Status: Running and Virtual Machine Status: Running.

(screenshot 1)

VMM hides the host status and keeps the last known VMS. It’s the same story for Admins and Delegated Admins with one difference – the user is able to see the host status:

(screenshot 2)

It’s possible that a not responding host does not lead to an outage of the vm itself. But from a VMM perspective this is “unknown”. VMM does not know the status of the VM. It just keeps the last “known” virtual machine status.
This should be changed. When the Host is not responding, the virtual machine status should be “unknown” or “needs attention”. This will allow the SSO user to be aware that the VM is either running or not. Otherwise the VM is showed as “running” but it’s not available anyway (more or less schrodingers cat).

As discussed in the following forum topic:
https://social.technet.microsoft.com/Forums/systemcenter/en-US/917c90d5-f7f4-454c-825b-fe0f28592978/cannot-create-vm-from-gen2-template?forum=virtualmachingmgrhyperv

I am not able to fix whatever causes error 23352 to be thrown after
- Creating a new generation 2 Virtual machine
- Booting, installing and configuring the machine
- shutting down the machine
- Creating a VM template from the VM
- Enabling "Create a differencing disk using the specified disk as parent"
- Trying to create new virtual machines from the template.

After the VHDX was deployed to the host(s) and differencing disks are to be created, error 23352 ("VMM cannot find the device or this device is not valid for a boot device") is thrown.

KB2955362 suggests to manually set the boot device to the disk which contains the OS. I use that command, but it did not fix the issue.

There is no hint on what exactly may be the cause of this error.

Sometimes it helps to create a new VM template after changing the name of the VHDX file of the original VM. But sometimes this does not help.
In the forum topic mentioned above it was posted that this issue still occurs in SCVMM 2016.

TL;DR - Is there any chance that VMMAgent will ever use SMB Multichannel for file transfers?

I understand that VMMAgent does stuff over 443 (or 80 if specified) for file copies. If there's an ODX-capable storage provider, then it will leverage that. Otherwise, it will try "Fast File Copy" and then BITS over HTTPS (or HTTP if specified).

My question (or feature request?) stems from the fact that Microsoft is pushing these great new technologies as the bee's knees - Storage Spaces Direct (S2D), SMB Multichannel, Converged Networking, VMM + WAS, etc. Why can't VMM use them?

In a multi-NIC environment, couldn't VMMAgent be improved to be a little "smarter"? If there's a faster route, use it. The ODX functionality is already built in to pass transfers over various protocols depending on providers, why not extend this to SMB Multichannel?

With options like Dynamic Disk and Memory allowing you to get the most out of your resources. It would also make sense to allow end users to oversubscribe resources.

Turned off Virtual Machines count towards cloud limits and therefore users cannot easily switch between workloads in a lab environment without an offline Library. When users work with multiple VMs for a test and can switch multiple times in a day it makes little sense to force the Library usage as they cannot export VMs from the Library until the cloud is clear enough. This leads to countless lost hours waiting for VMs to import and export from the Library.