Best of TechEd 2013: Windows Azure – New Choices and Flexibility for Stopped VMs

Didn’t make it to TechEd this year? Don’t worry! This month, we’ll be releasing a new article series that highlights the Best of TechEd announcements and technical information for IT Pros. Today’s article focuses on a new, much-heralded enhancement to Windows Azure Infrastructure Services to make it more cost-effective for spinning VMs up and down on-demand on the Windows Azure cloud platform.

NEW! VMs that are shutdown from the Windows Azure Management Portal will no longer continue to accumulate compute charges while stopped!

Previous to this enhancement being available, the Azure platform maintained fabric resource reservations for VMs, even in a shutdown state, to ensure consistent resource availability when starting those VMs in the future. And, this meant that VMs had to be exported and completely deprovisioned when not in use to avoid compute charges.

In this article, I'll provide more details on the scenarios that this enhancement best fits, and I'll also review the new options and considerations that we now have for performing safe shutdowns of Windows Azure VMs.

Which scenarios does the new enhancement best fit?

Being able to easily shutdown VMs from the Windows Azure Management Portal without continued compute charges is a great enhancement for certain cloud use cases, such as:

On-demand dev/test/lab environments - Freely start and stop lab VMs so that they are only accumulating compute charges when being actively used.

"Bursting" load-balanced web applications - Provision a number of load-balanced VMs, but keep the minimum number of VMs running to support "normal" loads. Easily start-up the remaining VMs only when needed to support peak loads.

Disaster Recovery - Startup "cold" VMs in the cloud when needed to recover from disaster scenarios.

BUT ... there is a consideration to keep in mind when using the Windows Azure Management Portal to shutdown VMs: although performing a VM shutdown via the Windows Azure Management Portal causes that VM to no longer accumulate compute charges, it also deallocates the VM from fabric resources to which it was previously assigned. These fabric resources include compute resources such as virtual CPU cores and memory, as well as network resources, such as IP addresses. This means that when the VM is later started after being shutdown from the portal, the VM could be assigned a different IP address or placed on a different compute node within the fabric.

In some cases, you may want to shutdown VMs using the old approach, where fabric resource assignments are maintained while the VM is in a shutdown state. Specifically, you may wish to do this when temporarily shutting down or restarting a "7x24" VM as part of a maintenance activity. Good news - you can still revert back to the old VM shutdown behavior when necessary by using the alternate VM shutdown approaches listed below.

Let's walk through each approach for performing a VM Shutdown action on Windows Azure so that we can understand the benefits and considerations of each...

How many ways can I shutdown a VM?

In Windows Azure Infrastructure Services, there's three general ways that can be used to safely shutdown VMs:

Shutdown VM via Windows Azure Management Portal

Shutdown Guest Operating System inside the VM

Stop VM via Windows PowerShell using Windows Azure PowerShell Module

Although each of these options performs a safe shutdown of the guest operation system and the VM itself, each option handles the VM shutdown end state differently.

Shutdown VM via Windows Azure Management Portal

When clicking the Shutdown button at the bottom of the Virtual Machines page in the Windows Azure Management Portal, the VM is safely shutdown and "deallocated" from fabric resources.

When the shutdown process completes, the VM will be shown on the Virtual Machines page with a "Stopped ( Deallocated )" status as shown in the figure below.

Virtual Machine in a "Stopped (Deallocated)" Status

"Deallocated" means that the VM configuration is no longer being actively associated with fabric resources, such as virtual CPUs, memory and networks. In this state, the VM will not continue to allocate compute charges, but since fabric resources are deallocated, the VM could receive a different internal IP address ( called "Dynamic IPs" or "DIPs" in Windows Azure ) the next time it is started.

TIP: If you are leveraging this shutdown option and consistency of DIPs is important to applications running inside your VMs, you should consider using virtual networks with your VMs. Virtual networks permit you to assign a specific IP Address Space for use with VMs that are assigned to that virtual network. As long as you start VMs in the same order in which they were originally provisioned, each VM should be reassigned the same DIP that it was previously using.

What about consistency of External IP Addresses?

Great question! External IP addresses ( called "Virtual IPs" or "VIPs" in Windows Azure ) are associated with the cloud service in which one or more Windows Azure VMs are running. As long as at least 1 VM inside a cloud service remains in a "Running" state, the VIP assigned to a cloud service will be preserved. If all VMs inside a cloud service are in a "Stopped ( Deallocated )" status, then the cloud service may receive a different VIP when VMs are next restarted.

TIP: If consistency of VIPs is important for the cloud services in which you are running VMs, consider keeping one VM inside each cloud service in the alternate VM shutdown state listed below to preserve the VIP associated with the cloud service.

Shutdown Guest Operating System inside the VM

When performing a Guest OS shutdown or restart ( ie., a shutdown or restart operation initiated from the Guest OS running inside the VM ), the VM configuration will not be deallocated from fabric resources. In the figure below, the VM has been shutdown from within the Guest OS and is shown with a "Stopped" VM status rather than the "Stopped ( Deallocated )" VM status that was shown in the previous figure. Note that it may require a few minutes for the Windows Azure Management Portal to reflect that the VM is in a "Stopped" state in this scenario, because we are performing an OS shutdown inside the VM rather than through an Azure management endpoint.

Virtual Machine in a "Stopped" Status

VMs shown in a "Stopped" status will continue to accumulate compute charges, because fabric resources are still being reserved for these VMs. However, this also means that DIPs and VIPs are preserved for VMs in this state, so you don't have to worry about VMs and cloud services getting different IP addresses when they are started in the future.

Stop VM via Windows PowerShell

In the latest version of the Windows Azure PowerShell Module, a new -StayProvisioned parameter has been added to the Stop-AzureVM cmdlet. This new parameter provides the flexibility to choose the VM configuration end result when stopping VMs using PowerShell:

When running the Stop-AzureVM cmdlet without the -StayProvisioned parameter specified, the VM will be safely stopped and deallocated; that is, the VM will be left in a "Stopped ( Deallocated )" status just like the end result when a VM Shutdown operation is performed via the Windows Azure Management Portal.

When running the Stop-AzureVM cmdlet with the -StayProvisioned parameter specified, the VM will be safely stopped but fabric resource reservations will be preserved; that is the VM will be left in a "Stopped" status just like the end result when performing a Guest OS shutdown operation.

So, with PowerShell, you can choose how Windows Azure should handle VM configuration and fabric resource reservations when stopping VMs on a case-by-case basis.

TIP: It's important to note that the -StayProvisioned parameter is only available in the latest version of the Windows Azure PowerShell Module. So, if you've previously downloaded this module, be sure to download and install the latest version to get this new functionality.

Want to Learn More about Windows Azure Infrastructure Services?

To learn more about Windows Azure Infrastructure Services, be sure to check-out these additional FREE resources:

Yes – if you shutdown a VM in one of the manners list above in which it is left in a "Stopped" status, rather than a "Stopped (Deallocated)" status, compute charges will continue to accumulate because fabric resources are still reserved for that VM.