Unfortunately only one ASR subscription from one recovery vault is attachable into SCVMM. AS such, protected VMs can only be saved into a storage vault, that resides in the same datacenter as the recovery vault. In case of a global deployment, where SCVMM administrates hosts and VMs around the globe with appropriate site definitions, a failover would force users to connect to Azure VMs situated in another region as themselves. This situation also applies to the MARS agent around the globe replicating VMs to the same, single recovery/storage vault.

When deploying a new VM from a disk image, I cannot do OS Customization during the deploy process. If I create a new VM Template using the same disk, I can then do OS customizations when deplying from tha template. This carries over to WAP. I would like to not have to create a VM Template in order to deploy a VM and get OS customization (Admin password, hostname, etc.). Effectively, I can't deploy from a generic Image and get access to the VM.

* Storage classification
* Multiple IP Addresses
* Allow migration of NVGRE gateway between clusters and set fixed Public IP on virtual networks.
* Better monitoring integration, get more information from VMM to WAP.

In the SCVMM 2012 R2 UR 6 we have an option to Start and shutdown Azure VMs. We would like to see the Resize option as well which will help the support teams in large environment.

A quota system similar to what is in place for memory and cpu to govern how much space a user or a subscription from Azure Pack is able to use on different classifications of storage. E.G. User A wants high speed storage for VMs and some low speed storage for general data, so this user gets 80GB of "Silver" tier storage and 300GB of "Bronze tier. This would also need to be accompanied by the ability to select where a VM's disk are placed during provisioning through the Azure pack portal or from VMM.

Wish list...

1. Allow to set relative priorities for CPU, RAM, Storage QoS, etc. between clouds. i.e. - All VMs in Cloud A (Prod) and higher priorities than VMs in Cloud B (Test/Dev).
2. Control/restrict VM networks in addition logical networks in a cloud. I don't want users connecting their test/dev VMs to the production networks that they otherwise have permission to.

Please make the integration with SCOM less dependent on a single SCOM Management Server. It would be nice if the VMM could discover all the MSes and dynamically pick the next available one, in case if the current becomes unavailable (i.e. host maintenance or failure).

Also Service Templates and VM Templates should use tags, Familiy name and versioning to use Disk instead of attaching them directly