A Deep Look inside Windows Azure Virtual Machines

As I believe most people are aware that our application on Windows Azure is actually running on VM (Virtual Machine) that sits on top of Windows Azure Hypervisor, inside Microsoft Datacenter.

The objective of this post is to explain under-the-hood or deep view of what’s actually inside Windows Azure Virtual Machine.

This is NOT about VM (Virtual Machine) Role

Please do not be confused this post with VM Role. This post is purely discussing about the Virtual Machine of pre-provisioned by Windows Azure, specifically Worker Role and Web Role. While VM Role is another role type other than Web Role and Worker Role.

Fabric Controller – the “kernel” of the Cloud OS

Before moving on what inside the VM, I will explain how the Fabric Controller is, what it does, and how it relates to Windows Azure VM.

Fabric Controller is actually a Windows Azure service that is acting as the kernel on the Windows Azure Platform itself. It manages data center’s hardware as well as Windows Azure service. The Fabric Controllers run on nodes that will be spread across fault domains in the hardware. In order to ensure the high availability and multiple-fault tolerant, it has at least 5 instances, in most case it may be more.

Specifically, the main responsibilities are:

1. Data Center Resource Allocation

The Fabric Controller will manage the resource allocation over the hardware in Windows Azure datacenter including the blades and network. When you specify your input of your service (VM Size, number of instance, fault domain, upgrade domain),the Fabric Controller would be intelligent enough to allocate appropriate resource inside the datacenter.

2. Data Center Resource Provisioning

When appropriate node is found,the next step is to provision the VM for host our application to ensure the application and OS are up and running. The provisioning processes includes powering-on the node, perform a PXE-boot maintenance OS, download host OS, run sysprep, and eventually connect the Fabric Controller will communicate with host agent.

3. Service Lifecycle Management

Managing the deployment lifecycle of service. When you deploy your application on Windows Azure (regardless through portal or management API), your service package is actually passed to a service, namely RDFE (Red Dog Front End). The RDFE then subsequently send your service package to Fabric Controller based on target region. The Fabric Controller will then deploy your service accordingly given inputs that you’ve defined in Service Configuration and Service Definition files.

4. Service Health Management

When the service is successfully deployed, the responsibility of Fabric Controller is not done yet. However, it will manage and monitor the health of the VM. The monitoring process typically works by sending the heartbeat from guest OS to host OS and subsequently host OS to Fabric Controller. The Fabric Controller will then act appropriately should it encounters any issue.

Alright, having understand what Fabric Controller is, we can now just to our core topic about the Windows Azure VM.


Pre-provisioned VM sits on Hypervisor


A Windows Azure VM (regardless it’s web or worker role) is actually a pre-provisioned VM that is automatically placed and booted on top of Hypervisor, a custom version of Hyper-V to satisfy the needs. In the picture it’s reflected as “Guest VM”. This is actually the place where our service hosted on. The Guest VM will communicate to Root / Host VM to perform necessary management task such as as heartbeat-pinging.

Operating System Versions

At the moment, Windows Azure supports two type of operating system, namely:

  • Windows Server 2008 (64 bit)
  • Windows Server 2008 R2 (64 bit)

You can specify your preferred OS on either:

1. Service Configuration files by entering osFamily and osVersion attributes.


osFamily 1 represents Windows Server 2008, while 2 represents Windows Server 2008 R2.

On the osVersion, this is the setting where you tell Windows Azure, which version of OS your Guest VM will be using. Specify it with * (star) sign means Windows Azure will automatically upgrade the Guest VM OS when there’s new OS released. However, in some case customer does not want it to be automatically updated, then you can select the specific version of OS as could be found here.

2. Windows Azure Portal

You can also use user interface in Windows Azure Portal to select your preferred OS family and version.


 image_0373E245 image4_57977C87

What are the difference? Which one should I choose?

A few notable difference that I feel relevant to Windows Azure is some of the command utility exists in Windows Server 2008 R2 but not in Windows Server 2008, for example: tzutil command to set the timezone.

There’re indeed some more differences of each OS. I recommend you to check out more detail here.

VM Sizes

VM Size is to define the hardware specification of VM you want Windows Azure to provision to you. There’re 5 available VM Size at this moment from Extra Small all the way to Extra Large. Obviously, the higher specification the more expensive.


Extra Small




Extra Large


1.0 GHz

1.6 GHz

2 X 1.6 GHz

4 X 1.6 GHz

8 X 1.6 GHz


768 MB

1.75 GB

3.5 GB

7 GB

14 GB

VM Local Storage

20 GB

225 GB

490 GB

1,000 GB

2,040 GB

Network I/O Performance






Allocated Bandwidth

5 Mbps

100 Mbps

200 Mbps

400 Mbps

800 Mbps

Cost per Hour






Extra Small VM Size

Extra Small VM Size was announced in PDC 2010 with more affordable price. Selecting Extra Small VM in development or testing environment will fits properly. However, you are not recommended to use in Production environment.

VHDs (Virtual Hard Drives) inside Windows Azure VM

Windows Azure will provide three VHD images when a role is provisioned.


1. C Drive – Local Storage Drive

This drive is to store temporary file such as logs or to store local resource. The size of this VHD varies from 20 GB (Extra Small) to 2 TB (Extra Large) depending on what VM Size you choose. We can utilize this local resource drive to store temporary file, but keep in mind that it’s considered not persistence.

2. D Drive – OS Drive

The D Drive is to store the Operating System files. The foldering structure is as almost similar to the on-premise OS. It has Program Files, Windows, etc.

3. E Drive – Application’s code

The E Drive is the place for Windows Azure to store our application code. Our code will typically to be placed inside the “approot” folder.

Runtime Installed

As a PAAS (Platform as a Service) cloud provider, Windows Azure will take care of the OS and runtime level. As such, there are several pre-installed runtime in Windows Azure VM:

  • NET 3.5 SP1
  • NET 4
  • VC80 CRT (8.0.50727)
  • VC90 CRT (9.0.30729)
  • URL Rewrite Module 2.0
  • VC10 CRT (e.g. MSVCR100.DLL) is not fusion-ized and can be packaged together with the application

In future, there’s a plan (as mentioned by Mark) from Microsoft that Java will be pre-installed as well.


That’s all for this post and hope it’s useful to you!

This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to A Deep Look inside Windows Azure Virtual Machines

  1. wely.yahoo says:

    comment from wely.yahoo ACS

  2. Pingback: Can We Install Custom Software on Windows Azure? | Wely's Cloud Journey...

Leave a Reply

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