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.

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?

When adding a new Windows 2016 Hyper-V cluster to SCVMM, all VM's deployed to the new Windows 2016 cluster automatically deploy from SCVMM as a configuration version 8.0 machine. In order to allow time to upgrade all other Hyper-V Servers still running Windows 2012, it would be good to have the option to have a choice of configuration version of the VM. This is currently only possible if creating a VM directly on the Windows 2016 Hyper-V server itself. When creating VM's directly on a Windows 2016 Hyper-V server one can use the cmdlet "New-VM" and specify the configuration version using "-Version". The problem is that you cannot migrate any VM's off a Windows 2016 Hyper-V server back to a Windows 2012 R2 Hyper-V Server without the configuration version being 5.0. If any of our new Windows 2016 Hyper-V servers had an issue we will be in deep trouble, being unable to migrate any configuration version 8.0 VM's off to any other of our Windows 2012 R2 Hyper-V servers. Please consider adding this same option to SCVMM (New-SCVirtualMachine) and Windows Azure Pack (New-WAPackVMRole). This would be extremely helpful to maintain VM's across SCVMM, while we make progress in converting to Windows 2016 Hyper-V across all infrastructure.

It would be helpful to have an RSS Feed or email distribution so when "known Issues" internal to microsoft are "known", the community in general will also know.

for example, there was a hotfix for an issue created with UR12 for system center affecting replication. Our engineering team had to open a case with microsoft.

https://www.microsoft.com/en-us/download/details.aspx?id=54854

Admittedly, in this case, the title of the article for the hotfix does not imply that it fixes our specific replication issue which was caused by UR12 but when we call in and are told it is a "known Issue", it would be nice to "Know" it is a "known issue".

This has caused business risk for us since we do expect replication is happening in case of recovery so if this replication is not happening, we are at risk with downtime.

I realize communication can be an area of "you send to much" or "you don't send enough". In the case of known issues... I'd rather know of one and ignore than to not know and be troubleshooting.

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.