Creating a Windows Azure Virtual Machine – the RIGHT Way

UPDATE - 09/14/2015: This is an older post. Check the site for more current information.

Windows Azure has added Infrastructure-as-a-Service (IaaS), the ability to deploy, run and manage Virtual Machines, to its growing list of services. You can create Virtual Machines from a gallery, upload them from images you create locally on Hyper-V (that's right, you can do that, even from PowerShell) and of course you can just jump right in and just click the "Plus" sign at the bottom of the Windows Azure Management Portal, then hit Compute, then Virtual Machine and then Quick Create. Enter a few fields and you're off to the races. (video here:

Of course, that works just fine - but if you do it that way you're doing it wrong.  There's a better way - there are a few steps you should take before you deploy a Virtual Machine, and a few steps after. In general, the process looks like this:

  1. Create an Affinity Group
  2. Create a Virtual Network
  3. Create your Storage Account and Container
  4. Create the Virtual Machine
  5. Optionally, add an Availability Set

Note - some of these steps need to be done only once, others once per logical group of Virtual Machines, and so on. Hit the links below for more info on when to do what.

Step One: Create an Affinity Group

An Affinity Group is a logical grouping that dictates how Windows Azure will lay out the resources assigned to it. When you create services, you can assign them to the Affinity Group, and the Fabric will deploy those into the same Datacenter cluster. Create one these per grouping that you want.

Steps to do that:

Step Two: Create a Virtual Network

The TCP/IP address for Windows Azure Virtual Machines come from a predefined range. You can just let us pick that for you, or you can create your own Virtual Network that has a user-defined range of DHCP addresses, and even place a DNS Server or connect your local network to the Windows Azure network for your Virtual Machines. When you create the Virtual Network, you can assign it to the Affinity Group. It's a way of grouping machine networks together. Create one of these per group of Virtual Machines that you want to have the same DHCP and DNS Server.

More Detail:

Steps to do that:

Step Three:  Create a Storage Account and Container

Windows Azure Virtual Machine Disks are stored in Windows Azure Storage. That's a great benefit. If you don't define a Storage Account and a Container first, The Windows Azure  Management Portal will do that for you as you create the machine. Defining that Storage Account and Container ahead of time allows more control, and a better naming convention than what we'll pick for you. Read more to find out the strategy you should use to group the disks. Also, some workloads such as SQL Server have a best-practice of creating a separate disk for data and backups.

More Detail:

Steps to do that:

Step Four:  Create the Virtual Machine

You have a lot of choices here, from creating the Virtual Machine quickly, from a Gallery with pre-loaded software (like SQL Server), or even choosing from Windows or Linux. You can also create the Virtual Machines by uploading an image of your own, or create them through PowerShell. With the previous steps completed, you can select those pre-defined entries as you build the machine - just select them from the drop-down menus when prompted.

More Detail:

Steps to do that:

Step Five: Optionally, Add an Availability Set

When you build more than one Virtual Machine (always a good idea, and required for availability) you can load-balance the IP ports for them, and you can also specify that they are on separate "fault domains" for greater availability. This is called an Availability Set. Even if you think you're only going to build one VM, you can add the Availability Set it up now and use it when you grow the systems. Create one of these per group of Virtual Machines you want to add into your High Availability strategy.

More Detail:


Comments (3)

  1. Nirmal says:

    How about assigning a VM to a vNet?

    Is that doable?


  2. Paul says:

    Affinity groups are becoming legacy and new VNETS should be created a regional vnets and not bound to affinity groups. You can still create vnets with affinity groups if required for special cases through powershell.

  3. mcb says:

    Almost a year since its publication this remains a good article, except that in Step One one may want to reserve a public virtual IP (new feature, needs to be reserved before creating the VM) instead of creating an affinity group (deprecated feature, prevents the use of other resources later).

    Reverse DNS is another new feature that became available after this article appeared, and thus could be an interesting additional step.

Skip to main content