Speaking at MMS 2013

If you will be attending MMS 2013 next week in Las Vegas and want to learn more about automating the cloud with the Windows Azure PowerShell Cmdlets please stop by my session!


WS-B311 Take Control of the Cloud with the Windows Azure PowerShell Cmdlets

In this session you will learn how to tame the simplest to most advanced Windows Azure deployments with the Windows Azure PowerShell cmdlets. Automate repetitive tasks and learn how build advanced reproducible deployments so you can save time and money while working in the cloud. The presenter will cover dev-ops scenarios with Virtual Machines and Cloud Services in this demo packed session.

Windows Azure PowerShell Cmdlets Now Supports Storage!

The Windows Azure Storage team has delivered an outstanding set of PowerShell cmdlets for managing and using storage from PowerShell.

The new abilities include the ability to create and manage containers and blobs which includes the ability to asynchronously copy blobs (across storage accounts and across regions!).

A quick example of how to kick off async blob copies is below. The cmdlets were designed to allow multiple blob copies to start and then to monitor the results at a later time. This allows the end user to take advantage of the async nature of the APIs instead.

Import-Module Azure
Select-AzureSubscription mysubscription

$destContext = New-AzureStorageContext  –StorageAccountName $storageAccount `
                                        -StorageAccountKey $storageKey

New-AzureStorageContainer -Name $containerName

$blob1 = Start-CopyAzureStorageBlob -srcUri $srcUri1 `
                                 -DestContainer $containerName `
                                 -DestBlob $fileName1 `
                                 -DestContext $destContext 

$blob2 = Start-CopyAzureStorageBlob -srcUri $srcUri2 `
                                 -DestContainer $containerName `
                                 -DestBlob $fileName2 `
                                 -DestContext $destContext 

$blob3 = Start-CopyAzureStorageBlob -srcUri $srcUri3 `
                                 -DestContainer $containerName `
                                 -DestBlob $fileName3  `
                                 -DestContext $destContext 

$blob1 | Get-AzureStorageBlobCopyState 
$blob2 | Get-AzureStorageBlobCopyState
$blob3 | Get-AzureStorageBlobCopyState

The output of the Get-AzureStorageBlobCopyState cmdlet is below:

CopyId            : 60a3c559-14f4-4b37-ae2b-80755fc072c4
CompletionTime    : 3/27/2013 10:33:29 PM +00:00
Status            : Success
Source            : https://mwweststorage.blob.core.windows.net/source/testcopy1.vhd
BytesCopied       : 32212255232
TotalBytes        : 32212255232
StatusDescription : 

CopyId            : 0c665b44-aa33-47db-8367-b00aa450ed78
CompletionTime    : 3/27/2013 10:33:30 PM +00:00
Status            : Success
Source            : https://mwweststorage.blob.core.windows.net/source/testcopy2.vhd
BytesCopied       : 32212255232
TotalBytes        : 32212255232
StatusDescription : 

CopyId            : d425fae7-c9ba-4816-a81e-d0ded84baa75
CompletionTime    : 3/27/2013 10:33:31 PM +00:00
Status            : Success
Source            : https://mwweststorage.blob.core.windows.net/source/testcopy3.vhd
BytesCopied       : 32212255232
TotalBytes        : 32212255232
StatusDescription : 

The complete list of storage cmdlets are below:

  • Get-AzureStorageContainerAcl
  • Get-AzureStorageBlob
  • Get-AzureStorageBlobContent
  • Get-AzureStorageBlobCopyState
  • Get-AzureStorageContainer
  • New-AzureStorageContainer
  • New-AzureStorageContext
  • Remove-AzureStorageBlob
  • Remove-AzureStorageContainer
  • Set-AzureStorageBlobContent
  • Set-AzureStorageContainerAcl
  • Start-CopyAzureStorageBlob <- will likely be renamed to Start-AzureStorageBlobCopy
  • Stop-CopyAzureStorageBlob <- will likely be renamed to Stop-AzureStorageBlobCopy

Migrate a Virtual Machine to Windows Azure with PowerShell

In my previous post I show how you can use the Add-AzureVHD cmdlet to upload a VHD. I wanted to take it a bit further and show how you can use this new cmdlet in conjunction with the other PowerShell cmdlets to migrate and provision an entire virtual machine.

The script below uploads two VHDs; one for the Operating System Disk and one for an additional data disk. Once the VHDs are uploaded it then creates the disk entities using the Add-AzureDisk cmdlet and then proceeds to construct the virtual machine using the newly uploaded VHDs.

# Retrieve with Get-AzureSubscription 
$subscriptionName = '[MY SUBSCRIPTION]'  

# Retreive with Get-AzureStorageAccount 
$storageAccountName = '[MY STORAGE ACCOUNT]'   

# Specify the storage account location to store the newly created VHDs 
Set-AzureSubscription -SubscriptionName $subscriptionName -CurrentStorageAccount $storageAccountName 
# Select the correct subscription (allows multiple subscription support) 
Select-AzureSubscription -SubscriptionName $subscriptionName 

# Retreive with Get-AzureLocation 
$location = 'West US' 

# ExtraSmall, Small, Medium, Large, ExtraLarge
$instanceSize = 'Medium' 

# Has to be a unique name. Verify with Test-AzureService
$serviceName = '[UNIQUE SERVICE NAME]' 

# Server Name
$vmname1 = '[MY VM NAME]'

# Source VHDs
$sourceosvhd = 'C:\MyVHDs\AppServer1OSDisk.vhd'
$sourcedatavhd = 'C:\MyVHDs\AppServer1DataDisk.vhd'

# Target Upload Location 
$destosvhd = 'http://' + $storageAccountName + '.blob.core.windows.net/uploads/AppServer1OSDisk.vhd'
$destdatavhd = 'http://' + $storageAccountName + '.blob.core.windows.net/uploads/AppServer1DataDisk.vhd'

Add-AzureVhd -LocalFilePath $sourceosvhd -Destination $destosvhd 
Add-AzureVhd -LocalFilePath $sourcedatavhd -Destination $destdatavhd

Add-AzureDisk -OS Windows -MediaLocation $destosvhd -DiskName 'AppServer1OSDisk'
Add-AzureDisk -MediaLocation $destdatavhd -DiskName 'AppServer1DataDisk'

$migratedVM = New-AzureVMConfig -Name $vmname1 -DiskName 'AppServer1OSDisk' -InstanceSize 'Medium' |
					Add-AzureDataDisk -Import -DiskName 'AppServer1DataDisk' -LUN 0 |
					Add-AzureEndpoint -Name 'Remote Desktop' -LocalPort 3389 -Protocol tcp 
New-AzureVM -ServiceName $serviceName -Location $location -VMs $migratedVM 					

Windows Azure IaaS Webcast Series Part Two: Virtual Machine Networking Basics

This is part two of the Windows Azure IaaS Webcast Series. This webcast discusses connecting virtual machines together in a cloud service for direct network connectivity and also shows the basics of configuring load balanced endpoints.


If you missed it click here for: Part One Getting Started with Windows Azure Virtual Machines

Windows Azure IaaS Webcast Series Part One – Getting Started with Virtual Machines

I’ve started a series of webcasts focused on Windows Azure Infrastructure as a Service. This series is targeted at new users to IaaS and starts from the basics with creating virtual machines. I plan on building many of these webcasts to cover the getting started scenarios to more advanced topics.

If you have any scenario requests shoot me an email at: mwasham@microsoft.com or Tweet me at MWashamMS!


Advanced Windows Azure IaaS – Demo Code

First of all thanks to everyone that watched my session at Build. I’ve received quite a bit of positive feedback so far (one wasn’t so positive.. you know who you are ;-)).


One of the common requests I’ve received is to get access to the source code for the demo virtual machine manager app I showed.

I’ve posted the full source for this demo in a repo on GitHub.

Disclaimer: This demo was designed specifically to show off how to how to use the service management API for basic operations. The code has limited (to no) exception handling, best practices or anything else that would work in a production application 🙂

So now that you know the quality level of the code level of the demo I do want to explain a bit of how it works.

There are two projects: SMLibrary which is a very basic wrapper around the Windows Azure Service Management API and MyVMPortal is the other. MyVMPortal is an ASP.NET WebForms app that uses the API to create a VM.

To run it locally you will need to have a management certificate installed on your local machine that is also installed in your Windows Azure subscription.

Open the web.config page and add your subscription ID, cert thumbprint and storage account name(s) (separate them by comma if you want multiple storage accounts). The app by default is hard coded to deploy to West US. So unless you change that you will need to create your storage accounts in West US as well.

Long term it might be nice to further expand this demo to show other functionality for automating virtual machines. If you are interested in contributing please let me know.

Michael Washam

Windows Azure Virtual Machines

Windows Azure Virtual Machines are a new addition to the services provided by Windows Azure. They allow a much easier and flexible solution for quickly moving an existing workload from on-premises to the cloud or for building new applications that have dependencies on applications that will only run on a server with persistent local storage. Creating VMs in Windows Azure is easy and flexible because Windows Azure provides three different ways of provisioning one.

Creating a VM from an image

The first is to create the virtual machine directly in the cloud using a number of images provided by Microsoft or partners. This is by far the easiest route to take to quickly spin up a new virtual machine.

Virtual Machine Image Gallery

Creating from a Custom Image

The second option is building your own custom images and provisioning virtual machines from the resulting image. This involves creating a new VM using a platform image, customize it with your own software and settings, and then generalize it using sysprep within Windows or waagent -deprovision+user on Linux. Once the VM is generalized and shut down you can then use the capture functionality to save the VM as a custom image.

Note: You can also generalize a VHD offline and upload it using the csupload.exe tool available in the 1.7 SDK.

Bring your own VHD

The third option is uploading existing virtual machines in VHD format. This method also uses the csupload.exe utility. You can upload a generalized image or a non-generalized VHD. The generalized image can be used to provision new VMs in the cloud as a template and the non-generalized VHD can be used as an OS disk to boot from or just a data disk to mount as a data drive.

The process you choose for each of these creation methods is up to you. Windows Azure provides capabilities from a point and click web interface to full automation with PowerShell in addition to a REST based Service Management API.

IaaS is all About the App and not the Runtime

With Windows Azure Virtual Machines the focus is all on the application. Providing the underlying infrastructure to run applications for the most part as-is in the cloud is a key goal behind introducing Virtual Machines. New scenarios such as running applications like SharePoint Server, SQL Server, Active Directory and even various distributions of Linux are now available to Windows Azure users.

VM Architecture

If you have a solid understanding of the current Windows Azure service model you have a good base of knowledge for understanding how Windows Azure Virtual Machines are built. Windows Azure Virtual Machines are built on the same service model that web and worker roles are. However, the service model has just been enhanced to support functionality needed for virtual machines such as persistent storage and single instance per role.

The Cloud Service acts as a container for virtual machines. Within a cloud service there are two slots for deployments for traditional web and worker roles Staging and Production. With virtual machines the Production slot is the only one in use (VIP swapping is not supported with VMs). The deployment is another container for VMs (within the cloud service) that has its own set of properties specifically pertaining to virtual networking which I will talk about later. Within the deployment a virtual machine is its own role with a single instance.

Cloud Services and VM Architecture

Virtual Machine Disks and Storage

One key difference with virtual machines from other Windows Azure roles is the underlying storage. There was actually a long discussion internally on whether to refer to virtual machines as Durable VMs or Persistent VMs before landing on just Virtual Machines. This internal discussion is still visible in the service management API where virtual machines are still referred to as PersistentVMRole.

The disks in a virtual machine are actually stored as page blobs in Windows Azure Storage. When you create a Virtual Machine from an image, a writable copy of the image is created in the storage account you specify on VM creation. This is where the underlying operating system VHD is created. Windows Azure storage offers numerous benefits such as extremely scale and durability. Your virtual machine storage is replicated three times within the same data center and optionally another three times in a different datacenter in the same region for extreme durability. Windows Azure storage also has the benefit of being easily accessible with a well-known API so there is already plenty of tooling available to manage it.

Virtual Machine Architecture

Looking at the diagram above you will notice that I did not add the D: drive into the list. The reason is very important. The D: drive is available to your application but you should very careful about using it for storage. It is actually the physical storage on the rack server the VM is running on. It is NOT backed by Windows Azure storage and should be considered temporary storage only. One great use for it is the OS paging file which contains data that does not need to be persistent (this is the default behavior in Windows Azure).

When dealing with virtual machine storage you should understand capacity and caching. The operating system disk can be at most 127GB. However, each virtual machine can also have additional data disks attached to it up to 1 TB per with the number of data disks dependent on the VM size. Data disks can also be dynamically added or removed while the VM is running. So adding additional storage to the VM is as simple as a few clicks in the portal or a short PowerShell command.

Virtual Machine Size and number of data disks supported

Disk Caching

There is a layer of disk caching support between the virtual machine and the underlying host. The default configuration of your OS disk will have ReadWrite host caching enabled and for data disks no caching is enabled. Take note not to put data on the OS disk without first changing the cache settings using the PowerShell Set-AzureOSDisk cmdlet. The OS Disk can also be configured for ReadOnly caching where the data disk supports None, ReadOnly and ReadWrite.

Windows Azure Virtual Machine Disks

Virtual Machine Networking

Virtual machines within the same cloud service have direct connectivity with each other. You do not have to configure internal endpoints through the service model because virtual machine’s default to allow all traffic on all ports between virtual machines. That does not mean that traffic will flow though. This is Infrastructure as a Service after all so you will still have to manage the firewalls on your VMs to allow traffic between servers.

Name resolution is handled through a multi-tenant DNS service provided by Windows Azure. Note: If you choose to configure a virtual network this DNS service is not provided and you are expected to configure your own DNS if name resolution is a requirement.

Endpoint Configuration

Configuring inbound traffic to your virtual machines is straight forward. Windows Azure has the concept of an Input Endpoint or more commonly known as just an endpoint. An endpoint is associated with a virtual machine and its properties allow traffic to flow.

Endpoint Property Names

  • Name (friendly name of your endpoint)
  • Protocol (tcp/udp)
  • Local Port
  • Public Port

For example if you wanted to configure an endpoint for a single web server your endpoint configuration might look like the following:

  • Name: iishttp
  • Protocol: tcp
  • Local Port: 80
  • Public Port: 80

If you needed to open up the web server for SSL

  • Name: iishttps
  • Protocol: tcp
  • Local Port: 443
  • Public Port: 443

Configuring the Load Balancer
The previous examples are great for opening up a port for a single virtual machine. However, sometimes you need multiple VMs responding on the same port in a load balancer. Windows Azure allows you to directly configure and control which virtual machines are configured for load balancing. It does this through load balanced sets.

Load Balanced Endpoints

A load balanced set is simply configuring the same endpoint on multiple VMs and setting another property called the “LoadBalancedEndpointSetName (or LBSetName in PowerShell) with a common name to group the endpoints together. This functionality is abstracted away within the Windows Azure management portal but it is good to go into in detail because from the command line you can have much more control over the load balancer by using custom health probes.

Load Balanced Endpoints

Configuring a Custom Health Probe for the Load Balancer

For an example on configuring a custom health probe see my post on Automating VMs with PowerShell.

Authenticated Sites and Custom Probes

It is important to understand that the URL configured for the custom probe receives a GET request from the load balancer without passing host headers or any authentication of any kind. So if the probe path you specify returns a 401 ACCESS DENIED then the load balancer is not going to add the VM to rotation. It is important to configure a health check URL here that can respond anonymously.

Port Forwarding

The architecture of cloud services makes endpoint configuration interesting. Since each cloud service has a single public IP address but multiple virtual machines can reside in it how do you address individual servers directly in a non-load balanced fashion?
The answer is port forwarding.

Port Forwarding to Multiple VMs

Port forwarding allows you to configure an endpoint on a specific VM listening on any of the ephemeral ports that will then be forwarded to the correct internal port. The illustration above shows two VMs both listening on ports 3389. To address them individually from the same public IP address two endpoints are made with the first listening on port 5586 and the second on 5587. When a remote desktop client connects to either endpoint they are forwarded to the correct machine.

Virtual Machines and Virtual Networks

Another new set of functionality with this release is Windows Azure Virtual Networks. Virtual Networks are more than just connecting your on-premises data center to the cloud (which does make it tremendously easier for building hybrid networks) but they also provide you the ability to configure the network within your Windows Azure deployment.

Persistent IP Addresses for Virtual Machines

This scenario is the easiest to understand so I will start here first. By default when you provision a virtual machine in Windows Azure you get name resolution by default and IP address management. The defaults are usually good enough until you need to do something that would require a persistent IP (notice I did not say static IP address). In the default networking configuration your VM’s IP address can and will change. So if you need to deploy something like Active Directory the default network stack will not work. This is where virtual networks save the day.

VNETs allow you to define the entire IP addressing scheme for your cloud network. You define the address space, the subnets and ultimately which VM goes into which VNET and subnet. The current biggest benefit to all of this is that each VM provisioned inside a VNET will retain the same IP address no matter how many times it is rebooted or recovered. Think of it as an infinite DHCP lease (do not set the IP address statically!). The downside is you do lose that built in name resolution when using a VNET and you do need to have a basic understanding of subnetting. If /16 and /24 are significant to you then you are likely already there.

Example Virtual Network Configuration (No Gateway)

Connect Your Data Center to a Windows Azure

Using a VPN device that supports site to site VPN you can create hybrid networks that span networks that you define from on-premises to the cloud. This means applications that do not move easily to the cloud can be directly accessed from applications in the cloud without expensive re-writes or wiring up of proxy interfaces to access the data remotely. Accessing the corporate Exchange Server, Active Directory, Solaris machines, whatever is on your corporate network can be made available to applications in the cloud. All that is needed is to configure a gateway in the virtual network configuration, share keys between the Windows Azure gateway and your VPN device and configure.

Connect Cloud Services on the Same Virtual Network

Connecting multiple cloud services on the same virtual network will open up all kinds of technical opportunities. The most obvious is the ability to take an application designed for Windows Azure web or worker roles and have them directly communicate with another application on a virtual machine such as SQL Server or Active Directory or any other application that runs in a VM. Many existing applications could easily be converted to web or worker role except for dependencies that require persistent storage. This should remove many roadblocks for migrating applications to PaaS.
Note that web and worker roles cannot currently be deployed into the same cloud service as a Virtual Machine so for direct connectivity a Virtual Network is required.

Connecting Web or Worker Roles with VMs on a Virtual Network with Hybrid Connectivity

Another interesting scenario is segmenting cloud services for large VM deployments. Since each VM is itself a Role in the Window Azure service model that brings with it the same limitations. There can only be 25 roles per cloud service so that means there can only be 25 virtual machines per cloud service. For truly large applications creating multiple cloud services and connecting them via a virtual network is a simple solution.

Name Resolution in a Virtual Network

As I mentioned earlier name resolution is not provided out of the box when you deploy a VM into a virtual network. The expectation is you will or can provide your own. There are a few ways to configure DNS for VMs in a VNET.

Configure DNS on the Network Adapter

This has the obvious draw back that you have to manually configure the DNS server IP address(s) for each machine.

Specify DNS servers in the network configuration

You can specify DNS servers when you configure the network configuration. The draw back here is there currently is no way of modifying the DNS configuration without redeploying the VMs in the VNET so at the moment this is not a flexible option.

Specify DNS during the first VM deployment

This is by far the most flexible. If for some reason the DNS server needs to be updated it’s a simpler matter of removing thfce VMs and redeploying them using the disks and specifying the new DNS configuration. All of this is easily scriptable from the Windows Azure PowerShell cmdlets (currently this is the only way of setting DNS during deployment).

Deploying a Virtual Machine into a Virtual Network

The final VNET diagram shows a typical configuration when deploying virtual machines into a virtual network. There are a few considerations before deployment.

Configure the Virtual Network First!

The reason is simple: You cannot move a provisioned VM into a VNET. The VM has to be provisioned into the VNET.

Determine DNS up front.

Will you provide it yourself by hosting DNS in your cloud service or point to a public DNS server? Will you set it at the network configuration level or at the deployment level? These are all good questions to answer before deployment. Because once a VM is deployed into a VNET you cannot change the existing settings of the VNET without first removing any VMs or web/worker roles in the VNET.

Each VNET requires an affinity group.

The cloud service that hosts your VNET must reside within the same affinity group.

The storage account has to either be in the same region as the affinity group or the same affinity group.

It cannot reside in a different affinity group within the same region or another region.

Virtual Machine Availability

With the launch of Virtual Machines comes a new SLA. With web and worker roles we offer a %99.95 uptime SLA as long as you have at least two instances of your application running to compensate for host updates and hardware failures. With VMs we realize that many applications do not need (and many do not even work with) multiple VMs. So to address this need we will offer the single instance SLA of %99.9. We will of course also offer the %99.95 (this is still under consideration but did not make GA). SLA assuming you have >1 instance using a new feature called an Availability Set.

Availability Sets

If you are familiar with the concept of upgrade and fault domains then you are mostly there with availability sets. The concept is similar except the functionality of upgrade/fault domains are combined with availability sets with VMs. The main thing to understand is that your VMs in a set will be physically on separate racks in the data center and when we upgrade the host OS beneath your VMs we will never upgrade all of the VMs in the set at the same time so only part of your application is taken down for maintenance.

Availability Sets Visualized

Availability Sets and SLA

Availability Sets give you data center hardware redundancy at each tier of your application.

Wrapping Up

In summary I would say that with the launch of Windows Azure Virtual Machines and Virtual Networks we have opened the gates up to start migrating workloads to the cloud. You are no longer required to re-write/architect your applications to have it run in the cloud. With Virtual Networks you are no longer restricted by an “all or nothing” migration approach or forced to write lots of service wrappers to surface on-premises data over the Internet.

Windows Azure still has all of the great functionality with PaaS style applications but now with the ability to run these applications side by side with traditional apps an entirely new set of opportunities have been opened up.

Michael Washam
Senior Technical Evangelist – Windows Azure