Introduction

I needed  way to easily stop and start my different lab setups in Windows Azure. I don’t want to keep running, and pay for, a set of VMs I use maybe once a month. So here is a PowerShell script to stop and start a set of Azure VMs. One important dimension here is the order in which the VMs start (and possibly; shuts down, depending on your setup). Since all IP addresses are dynamically allocated in Windows Azure I had to make sure that my VMs started in a specific order and that the script executed synchronously. That way whatever IP they had when they were provisioned would most likely be assigned to them when they started. Therefore the script includes code to start and stop VMs in the order you specify them in the input file. It also tries to wait until the current VM is fully started or stopped before proceeding with the next one.

Pre-requisites, input file and usage

The input file is really simple. It is a text file with a Cloud Service name and a VM name on each line, separated by a semi-colon, no header:

<cs name>;<vm name>

The VMs in the file will be started in the order they are listed and stopped in the reverse order!

By default, the script looks for a txt file in its execution directory called Control-AzureVMs.txt. If it is not found PowerShell throws an error. You can override this behavior by specifying your own file with VMs to either start or stop.

You must already have your machine configured to use Windows Azure PowerShell and specify your subscription in the script:

Select-AzureSubscription “<your subscription name here>”

Whether you want to start or stop a set of VMs is controlled by a script parameter. You use either Stop or Start. Optionally you can add your own txt file with VMs after the Start/Stop parameter.

Usage with the default input file:

Control-AzureVMs.ps1 Stop

Control-AzureVMs.ps1 Start

Usage with the custom input file:

Control-AzureVMs.ps1 Stop MySetOfVms.txt

The code

Here is the code. I can think of all sorts of improvements, but I needed this quickly so that will have to wait. Error checking is pretty much non-existent at this point so use at your own risk. I accept no responsibility whatsoever.

https://gist.github.com/morgansimonsen/8529297

UPDATE: With the release of the Windows Azure PowerShell module v0.7.3 you can now create DHCP reservations for your VMs that will persist when the machine is deallocated. Check out Get-AzureStaticVNetIP, Set-AzureStaticVNetIP, Remove-AzureStaticVNetIP and Test-AzureStaticVNetIP.

The latest version of the Windows Azure PowerShell module v 0.7.0 (released 21-10-2013), which features such great improvements as Windows Azure Active Directory logon support, unfortunately has a bug relating to endpoint ACLs.

Any Set-AzureEndpoint or Add-AzureEndpoint command which includes the ACL parameter will seem to succeed, but no ACL changes will be applied to the endpoint. I reverted to the previous release, v 0.6.16.1, and it works correctly.

I submitted an issue on GitHub, hopefully it will be resolved soon.

Windows Azure guarantees a 99.95 % uptime SLA, but this is only for multiple instance roles. So, for example, one web server by itself will not be guaranteed 99.95 % uptime, but will rather have “best effort”. Whereas two, or more, in a multi instance role will. So how do you make something multi-instance?

You use something called an availability set. An availability set is spanned across multiple fault and update domains in the datacenter. A fault domain is a collection of resources that are expected to fail together, like a server rack. An update domain is a set of resources that are updated at the same time. An availability set ensures that your instances are spanned across multiple update and fault domains so that no single failure or update can impact all the instances. The point here is that all the instances must be the same and be able to offer the same service to your users. So going back to our example with web servers you have to have at least two identical ones in the same availability set for your service to have a 99.95 % uptime guarantee. It is not correct to say that any VM or instance is guaranteed 99.95 % since it is the service that the instance offers that is guaranteed. Furthermore only Internet facing services have the SLA, since you need to use the Windows Azure load balancer to publish your instances, but more on that another day. Back to availability sets.

You add VMs to availability sets either in the Windows Azure portal, with PowerShell or the REST API. In the portal or PowerShell there is no way to explicitly create an availability set, you always create one as a side effect of configuring a VM. In the portal it looks like this:

This is an availability set with only one instance. In the drop down list I can either remove the VM from the availability set or create a new availability set and add the VM to that set.

Note: when you either add or remove a VM from an availability set, it will get a new NIC. This will have the same IP address as before but you will see that its number has been incremented.

In PowerShell you use the Set-AzureAvailabilitySet or New-AzureVMConfig cmdlets. Set-AzureAvailabilitySet updates an existing VM while New-AzureVMConfig lets you specify an availability set when you create the VM.

Something I miss is the ability to list all my availability sets. Since there is no (yet) Get-AzureAvailabilitySet cmdlet you have to extract this information from each of your VMs. Here is a quick one-liner to do that:

https://gist.github.com/morgansimonsen/8039845

This will list the VM names, cloud service names and availability set names (if any) for all your VMs. Feel free to add any kind of formatting or sorting to the output.

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.

You can have several Windows Azure subscriptions defined in Windows Azure PowerShell. This lets you easily manage several subscriptions from the same PowerShell console. These are the steps required to add a new Windows Azure Subscription to your Windows Azure PowerShell profile:

1. Generate a management certificate:
   makecert.exe -pe -n “CN=<certificate subject>” -ss My –r <certificate filename>.cer
2. Upload management certificate through Windows Azure portal (Settings->Management Certificates):
   
3. Copy the subscription ID:
   
4. Add subscription to default subscription data file:
   Set-AzureSubscription -SubscriptionName <subscription name> –SubscriptionId <subscription ID> –Certificate <path to cer file> –CurrentStorageAccount <storage account name>

Miscellaneous subscription related commands:

• List all subscriptions currently defined in Windows Azure PowerShell profile:
  Get-AzureSubscription
• List current subscription:
  Get-AzureSubscription –Default
• Set current subscription:
  Set-AzureSubscription -DefaultSubscription <subscription name>
• Do not specify a default subscription:
  Set-AzureSubscription –NoDefaultSubscription
• Display currently selected subscription:
  Get-AzureSubscription –Current
• Set a specific subscription as the active one:
  Select-AzureSubscription –SubscriptionName <subscription>

By default, every Windows Azure subscription has a limit of 20 compute cores. This applies to both VMs (IaaS) and worker roles (PaaS). Fortunately this is a soft limit and you can increase it by submitting a support ticket to the Windows Azure team through the management portal here. The following table lists the number of cores for each available Windows Azure instance:

To see how many cores each of your cloud services are using just look in the management portal. You will se something like this:

Unfortunately you need to manually add all the cores for each cloud service to get the total number. To work around this limitation you can use PowerShell:

https://gist.github.com/morgansimonsen/8039470

Save the above as a PowerShell script and run it from a prompt with the Windows Azure PowerShell module added. It will return all your VMs, sorted by name, their instance sizes, the number of cores they each use and the total number of cores in use in your subscription.

If you are paying for your Windows Azure subscription with a credit card your credit limit is $15000 by default. This will let you increase to a total of 175 cores in your subscription. If you want more cores and still pay with a credit card you will have to go through a credit check process to increase your credit limit. If you move to an Enterprise Agreement there will be no need for any credit checks to increase your core count beyond 175.

For large deployments the Windows Azure Capacity Planning team will want information from you so that they can allocate the required resources in the regions you specify. Typical questions they will ask you is where (region) you want to deploy, if you can deploy in several regions, if you are creating a new deployment or growing an existing one, which VM sizes you require and other services, like CDN, SQL etc) that you may require.