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.

Thanks!
Michael Washam
Senior Technical Evangelist – Windows Azure

16 thoughts on “Windows Azure Virtual Machines

  1. azurecoder

    Michael, thanks for a great explanation on iaas. I’m adding some of these things into a C# fluent management library I’ve been writing and the huge changes to the service management api with little current documentation are very daunting. This is a great explanation and moved me further forward quite a bit (and saved me a lot of trial and error attempts)

    Reply
  2. Michael Washam

    A tip that might help you with the service management API. For most of the IaaS operations (and most of the PaaS) I’ve added a -Verbose switch to the PS cmdlets that will dump out the XML request going across the wire to the service management API. Comes in handy when trying to build out the payload.

    Reply
    1. krith

      Hi , how do i load balance azure VMs via service management API.Any hint or help on this will be appreciated very much

      Thanks.
      Krithika Vittal

      Reply
  3. Jon Wapstra

    Great write up Michael. I have found most of the Azure VM deployments I have done so far to be straight-forward. It would be good to see Microsoft firewall products added to the list of supported VPN site to site offerings.

    Reply
  4. Pingback: Overview of the Windows Azure Platform | Convective

  5. Meir Kraushar

    Hi Michael
    Thanks for a great article.
    I do have a question about VNETs:
    I deployed an Active Directory environment.
    Yes, all IP addresses are DHCP enabled (and they are persistent), works beautifully.
    The DNS client configuration though (on each VM NIC), is static, manually configured to the DC Server.
    So now, each time a VM is rebooted, it loses its DNS client configuration on the NIC.
    AM I wrong?

    Reply
  6. Richard Paluzzi

    Hi Michael,
    This was a huge help in my moving forward with my understanding of Azure and it’s possibilities. I’ve been asked to enact what I believe is shown in the last dialog, that is two or more cloned web VMs under round robin load balance, each on a different update/fault domain and all pointing to one VM with SQL Server which is mirroring/synced to another VM with that same SQL Server but in a fail over relationship. I’ve mimic-ed this in Azure’s new UI and come up with 4 VM’s which basically do the above, except the VMs in the web scenario are not showing in different update domains while the SQL ones do. The Web VM’s share one endpoint, a service and an availability set while the SQL VM’s share only a service and an availability set. Can you suggest what I’ve done wrong.

    Also any suggestions on the best method for mirroring the SQL VM’s? Can SQL Data Sync be used to keep an instance of SQL Server on two different VM’s in a fail over configuration in sync.

    Reply
    1. Michael Washam

      Hi Richard,

      I haven’t ran into two VMs in the same availability set being in the same fault domain yet. I would recommend reporting it on the support forums: http://social.msdn.microsoft.com/Forums/en-US/WAVirtualMachinesforWindows/threads.

      As for SQL mirroring. I think implementing SQL mirroring itself would be your best bet.

      If you do not have AD in the cloud you can implement mirroring using certificates. Here is an article that should get you up and running: http://msdn.microsoft.com/en-us/library/ms191140.aspx

      Reply
  7. mkariti

    Hi there,
    What do I need to do if I would like to expose my VM to the web?
    I have a website running on it but cant seems to expose it….
    Many thanks
    mkariti

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>