If the customer tried to create a new D series VM in the same VNet or cloud service, they will also receive the following warning message telling them the cloud service doesn’t support those compute units.
If you create an A series VM in a new cloud services, Azure’s cloud fabric will host that VM in a cluster that currently may only support A series. That’s why you’ll see the behaviour that our customer has experienced.
It is not possible to move a VM between cloud services either so even if you had a service currently hosting D series VMs, the customer would need to delete their VM (but choosing the option to keep the attached disks) and recreate the VM from the attached disks in the other cloud service.
So our little trick would be for this customer to create the VM as a D series initially and as soon as it’s created, scale the VM down to an A2. That way Azure will host the VM in a cluster capable of supporting both A and D series compute units. The customer can scale up, down and mix VMs of A and D series to their heart’s content (with the exception of the A8-A11 compute sizes). The image below shows a cloud service with both A and D series compute units.
This doesn’t work with G series currently but at present they can only be hosted in the West US and East US 2 data centres anyway. Of course the feature release cadence of Azure is rapid so it’s likely this will be possible at some point in the future.
How would the customer have known to create the D series first to avoid this trap? We’d recommend utilising a Microsoft partner with experience in Azure services or attend one of our training courses; that’s what we’re here for.