Once upon a time Azure only had VMs of one size, the "A" size. Then in 2014, Microsoft introduced the new "D" size VMs. The new VM sizes were immediately available for new VMs, but what if you wanted to update an existing VM? What if you wanted to introduce a new D-series VM to your existing cloud service? Problems can crop up quickly, and that is the topic of this post. Read past the break for more.
The A-series VMs, specifically the A0 through A7 VMs, have essentially the same characteristics. They guarantee a certain amount of CPU, RAM, and IOPS which are most likely remote 10k or 15k disks. Since Azure is Hyper-V, and Microsoft likes to eat its own dog food, they are probably using Scale-out File Servers (SoFS) with JBOD enclosures providing storage over SMB. That's just a guess on my part, but it fits with the pattern. When MS was designing the underlying Hyper-V clusters to support Azure, they sized the hosts and clusters to have a certain number of blades available - slots if you prefer - that a new VM could be dropped into. That meant tweaking the VM sizes so that they could maximize the number of VMs per host. If you look at the different VM sizes, you might see some strange numbers in terms of CPU, RAM, and disk size. That is largely b/c of the blade sizes they have allocated on the backend.
When D-series VMs were introduced, the main difference was an SSD available for storage use and faster processors. The SSDs are onboard the host, and are presented to the VMs as non-persistent disk. That means if the host goes down, or the VM is rebooted and starts on another host it will not have access to that drive. The addition of SSDs in the host and dramatically faster CPUs means that new Hyper-V host clusters had to be created. The net impact is that D-series VMs cannot live on old A-series Hyper-V clusters. However, A-series VMs can live on the new D-series Hyper-V clusters.
The proscription above also goes for existing cloud services. As far as I can tell, a cloud service is a logical entity in Azure which is tied to a specific Hyper-V cluster that houses its VMs. When a new cloud service is created and associated with a VM, the available VM sizes gets locked down. In my Azure account I created a new cloud service and added a single A2 size VM to it. In Azure PowerShell I ran the Get-AzureService command and it returned the following information:
VirtualMachineRoleSizes : {A5, A6, A7, Basic_A0, Basic_A1, Basic_A2, Basic_A3, Basic_A4, ExtraLarge, ExtraSmall, Large, Medium, Small}
Then I created a new cloud service and added a single D1 size VM to it. The output from Get-AzureService gave me this:
VirtualMachineRoleSizes : {A5, A6, A7, Basic_A0, Basic_A1, Basic_A2, Basic_A3, Basic_A4, ExtraLarge, ExtraSmall, Large, Medium, Small, Standard_D1, Standard_D11, Standard_D12, Standard_D13, Standard_D14, Standard_D2, Standard_D3, Standard_D4}
And that kind of proves the point. The first cloud service won't host anything but A-size VMs, while the second cloud service will house either.
If I try to create a new D1 size VM in the first cloud service, the creation will fail:
 |
| Sadness on the dashboard |
Clicking into the Error screen on the new portal you get this helpful message:
 |
| No Wesley Snipes for you. |
Yeah, thanks for the "super helpful" message Azure. What it means to say is that you are handing it a VM definition for a D-series size blade, but that blade type is not available in the current cloud service.
So what can you do?
If you want to have a D-series size VM in your existing cloud service, I've done the following and it works. Remove all the VMs from your cloud service, then create the D-series size VMs. That's sort of the nuclear option though. I'm checking to see if the cloud service will lose it's VirtualMachineRoleSizes property when all existing VMs are shut down. If that's the case, you might be able to simply shut down all the A-series VMs, create one D-series VM, then start up your A-series VMs again. You would lose your current public IP address in the process, but that's a lot easier than removing all the VMs.
Your second option is to create a new cloud service and create your new D-series VM in that. Then you can migrate your A-series VMs over if you would like. The process for moving a VM from one cloud service to another is pretty straightforward, and has been documented
here. If you have a bunch of VMs, you can actually script the whole process with a for loop and go have some lunch.
If you wanted to upgrade your A-series VMs to a D-series size you might encounter a similar issue where the D-series size is not available:
The same process of moving your VM to a cloud service with D-series size VMs will solve that issue. Here is the drop-down of that same VM after I moved it.
No matter how you choose to do it, there is going to be some disruption to the VM. But that will happen regardless when you resize it anyway. I am currently reviewing some other potential options for resizing, but for right now I would follow these processes. For all future cloud services and VMs, I would recommend starting at D1 and then sizing down to an A-series VM if you want.
Labels: Azure, cloud service, IaaS, powershell, virtual machines, virtualization
