Monthly Archives: July 2013

Microsoft Azure

A network by any other name…

Leave a comment

OK, funny story. A Windows Azure virtual network with the name MDS-vNET1; no problem. A Windows Azure cloud service with a production deployment slot associated with a virtual network with the name MDS-vNet1; no problem. Try to combine those two; problem.

So let me give you a few more details. Everything in this setup was created with PowerShell. I pre-created all the cloud services, affinity groups, storage accounts etc. I created a virtual network XML file and uploaded it with PowerShell too. But the crucial bit came when I created the VMs. On the New-AzureVM cmdlet I specified a vNetName of MDS-vNet1, instead of MDS-vNET1 that was in the network configuration. The command did not give any errors but when I tried to see which subnet a VM was on that information was missing from the Azure portal, and from PowerShell, and from SC App Controller. All I could see in any of those was the incorrect vNetName (MDS-vNet1). The Subnet field was simply missing. If I did an export of the VM with Export-AzureVM, the Subnet section was empty. Needless to say, the VMs were not communicating.

So how to fix it? You cannot change the vNet associated with a deployment once it is up and running. Neither can you move a VM from one subnet to another once it is created. The only time you can select a subnet for a VM is when you create it. In this case I had do to the following:

  1. Export and delete all VMs in the faulty deployment
  2. Delete the cloud service with the faulty deployment
  3. Manually edit all the VM XML files to include the correct subnet names
  4. Re-create the cloud service
  5. Import all the VMs and for the first VM specify the correct vNetName on the New-AzureVM cmdlet.

Problem solved.

As far as I know the only thing case sensitive in Windows Azure are storage account names, which can include only lower case letters and numbers. Not in any other case have I seen an error relating to text case. Strange that it should have such a drastic effect. If you have any experiences similar to mine, please leave a comment.

Microsoft Azure, System Center

App Controller and Azure HighMemory SKUs

1 Comment

We are all aware of the lag between the evolution of the Windows Server platform and the System Center suite. It always takes some time from when a new feature in Windows Server is released, before it is supported in the System Center products. Now, it seems, this applies to Windows Azure as well. Consider the following…

Recently I did a Windows Azure project for a customer which included the introduction of System Center App Controller 2012 SP1 in their environment. They were already using System Center Virtual Machine Manager 2012 SP1 to manage their Hyper-V hosts. We specifically wanted to use App Controller to be able to easily migrate VMs from on-premise Hyper-V into Windows Azure IaaS.

To add an Azure subscription to App Controller you need access to the subscription ID (obtained from the Azure portal e.g.) and a management certificate in PFX format, i.e. you need access to both the private and public keys of the certificate. This certificate needs to already be registered in the subscription. I my case adding the two subscriptions the customer used presented no problems. However, when I came back a few weeks later more instances had been created in the subscriptions and now we had the following error in App Controller under the Public Clouds heading:

* Service unavailable

The first I checked was the status of the App Controller Windows Azure Provider (cmazure) service. This Windows service is responsible for communicating with the Windows Azure platform through the REST API. On my server the service was not running. I started the service and refreshed App Controller, but got the same error. Checking the service status again I found that it had crashed!

The first remedy I tried was updating the App Controller installation with the System Center Service Pack 1 Update Rollup 2 (KB2802159). That did not prevent the cmazure service from crashing but now I had a new error in the App Controller console:

* Requested value ‘A6’ was not found.

A6 and A7 are the IDs of the new HighMemory SKUs introduced in Windows Azure back in April 2013. They are higher memory variants of the Large and Extra Large SKUs respectively. My next move was to check if App Controller knew about these newer SKUs. But first I had to determine if one of my subscriptions in Windows Azure were in fact using any A6 or A7 instances, and if so, remove that subscription. To do this I logged on to the portal, and it was indeed the case. One of the subscriptions had two A6 machines.

I deleted that subscription from App Controller so that I could test my theory that the reason for the error was that App Controller did not know about A6 and A7. Here is a screenshot of deploying a new VM to Azure from App Controller:

image

As you can see, the Instance size list does not contain the A6 and A7 SKUs. Mystery solved!

This case was very surprising to me in several respects. First, it seems strange that App Controller keeps its own definition files of what is available in Windows Azure (a platform that is updated every 4-6 weeks) instead for dynamically downloading that information on demand and caching it. Secondly it seems like bad code when the introduction of a new instance SKU actually crashes a Windows service. Surly that exception could easily be handled in the code.