Jose Guay

I’ve been working with Windows Azure Virtual Machines recently and they are great. I initially worked with them when they were still in preview mode and they were not as stable and robust as they are now. One of the most interesting features is the ability to re-configure them by just selecting the new characteristics from a dropdown.

As you can see we have many different options from a very small instance that shares CPU cores up to a dedicated 8 core & 56GB instance. If you’re concern is the price, well, just take a look at the pricing page for details, but in general prices are now very reasonable for those types of configurations.

A very strange situation happened to me a few days ago when I was trying upgrade a Large (4 cores, 7GB memory) instance to an A6 instance (4 cores, 28 GB memory). All I needed was more RAM so I went ahead and selected the new size and… wait… an error?!

Unable to upgrade the deployment. The requested VM size may not be available in the resources supporting the existing deployment.

I could not believe my eyes! Wait, did I just hit my max allowed cores? This particular subscription has several virtual machines and you should know you can only have up to 20 cores in use at any given time, in addition, you can only have up to 20 storage accounts and up to 20 cloud services per subscription, but this subscription looked like:

Besides, I was keeping the same amount of cores, just upgrading the RAM, so it didn’t make any sense. I tried different things:

First Attempt

Just upgrading as normal. This is where I first saw the error.

Second Attempt

I shut-down the VM and then to my surprise I was able to upgrade, but when I tried to restart it the error showed up again. I changed the configuration back and the VM started work normally.

Third Attempt

Twitter! I asked if anyone knew about this and specifically send the tweet to Robin Shahan and Scott Hanselman. Robin in turn contacted Neil Mackenzie. It’s amazing how you can get in touch with two Windows Azure MVPs in a matter of minutes.

Neil mentioned something that I wasn’t aware of: High-memory instances (A5, A6, A7) are not available in all clusters. I was in awe! How could that be? Well, as it turns out it makes sense. High-memory instances were just recently launched and therefore not available in every single cluster. Now, how can I be sure of this? He then went on to also mentioned that I could check the affinity group to verify if high-memory instances were available. But I created the VM without an affinity group, so I was sure there wasn’t any. This was a problem, as Neil pointed out, and quoting him exactly:

If a VM cannot be upgraded because of cluster age I don’t think there is any way to access high-memory without a migration into a new cluster (i.e., create new and delete old).

He also made sure I understood why it was needed to create the VM with an affinity group:

You can create a VM without the use of an affinity group – although one is recommended ot ensure that you keep compute and storage co-located in the datacenter. However, an affinity group is necessary if you want to use a VNET.

A motivation for creating an affinity group in this particular case – desire for high-memory instances – is that Microsoft has indicated that you WILL have access to high-memory instances in newly created affinity groups.

If you create a new affinity group, you should be able to:

• create a new affinity group
• create a new storage account in it
• shutdown your instances
• copy the VHDs to the new storage account
• create a new cloud service in the new affinity group
• create a new instance with the old VHDs in the new affinity group

More Theory

Robin also came to the rescue when I asked: What if I just re-create the VM without moving the VHDs making sure I create it in an affinity group? She said:

Whenever you create a VM in an affinity group, it assigns it to a high memory cluster. This is basically a hack to ensure that you get a high-memory cluster, even if you only have one VM in your affinity group.

You can’t add a current storage account to an affinity group, you have to assign it to the affinity group when you create the storage account. That’s why you have to create and use a new storage account.

And to complement, Neil said:

An affinity group is a way to co-locate compute and storage. You specify the affinity group instead of the datacenter when you create a cloud service or storage account. You can’t merely copy a cloud service or a storage account into an affinity group since they may not be in the same part of the datacenter. You need to create new cloud services and storage accounts and redeploy the compute and copy the data.

The reason for all of this was that my storage account as well as the cloud service were not in an affinity group either, so there was no guarantee that by just re-creating the VM in an affinity group, high-memory instances were going to be available.

Solution

So basically what I did was just follow Neil’s instructions. I needed to make sure the storage account where the VHDs were, as well as the cloud service and VM needed to be in an affinity group to guarantee that high-memory instances are going to be available.

The process is as follows:

• Create a new affinity group: Go to Azure Portal, then scroll down to Settings and select Affinity Groups. Then click in the Add button at the bottom.

 

• Create a new storage account: Scroll up to Storage and click on the + New. Then select Data Services –> Storage –> Quick Create. Make sure you select your new affinity group in the Location/Affinity Group field.

 

• Shut down the VM: Scroll to Virtual Machines, then select the VM you want and click on the Shut Down button. This will de-allocate the IP address so make sure you re-configure any DNS pointers to this VM.

 

• Delete the VM but keep the attached disks

• Copy the VHDs to the new storage account: This process is a bit elaborated and is discussed in a different post.
• Create new disks for the VHDs: Scroll up to Virtual Machines and select the Disks tab. Add a new disk based on the VHD that has the operating system and ensure you checked the option to indicate Azure that it is a VHD with an OS. Repeat the same for the other disks (if any) but don’t check the option for an OS VHD.

 

• Re-create the cloud service to make sure it is located in the affinity group you just created: Scroll down to Cloud Services, then select the cloud service, click delete and then re-create it.

 

• Create the VM: Scroll back up again to Virtual Machines and select + New. Then select Compute –> Virtual Machine. Ensure you are using the “From Gallery” option this time because you need to select the OS disk you just created. In the location/affinity group field, make sure you select the new affinity group. Also, remember to re-attach the other disks (if any).

 

• Set the size of the VM to the desired high-memory instance.
• Presto! You have now a high-memory virtual machine.

Thanks to Robin Shahan and Neil Mackenzie for their invaluable help in this process.

I hope this will help you understand why you need affinity groups and if you haven’t use them how to move your resources to use one.

Other Resources

• Affinity Groups in Windows Azure by Neil Mackenzie
• Neil Mackenzie on Twitter
• Neil’s blog
• Robin Shahan on Twitter
• Robin’s blog

Tags: Virtual Machine, Windows Azure