Cloud Computing|Hyper-V|PowerShell

Converting Availability Set Virtual Machines to Azure Managed Disks

In this post, I will explain the benefits of using Azure Managed Disks with availability sets. I will also show how to convert virtual machines in an availability set with unmanaged disks to Managed Disks. These will respect the protection offered by the availability set.



Sponsored Content

What is “Inside Microsoft Teams”?

“Inside Microsoft Teams” is a webcast series, now in Season 4 for IT pros hosted by Microsoft Product Manager, Stephen Rose. Stephen & his guests comprised of customers, partners, and real-world experts share best practices of planning, deploying, adopting, managing, and securing Teams. You can watch any episode at your convenience, find resources, blogs, reviews of accessories certified for Teams, bonus clips, and information regarding upcoming live broadcasts. Our next episode, “Polaris Inc., and Microsoft Teams- Reinventing how we work and play” will be airing on Oct. 28th from 10-11am PST.

Availability Sets

Azure uses availability sets for virtual machines in a few ways:

  • Fault domains: Virtual machines in a common availability set are spread across fault domains. This means that if there is an unplanned localized outage, such as a top-of-rack (ToR) switch failure, the other virtual machines in the availability set are unaffected. A scenario might be, the service offered by a set of load-balanced web servers survives the outage because the remaining web servers pick up the load of the down machine.
  • Update domains: Microsoft patches the Hyper-V hosts used by Azure several times per year. They use a rolling upgrade. Hosts have upgraded one update domain at a time. Virtual machines in a common availability set are spread out across multiple update domains. Imagine that you have two domain controllers. If Microsoft reboots a set of hosts because of host updates, then only one of your domain controllers will be offline. This is because of host reboots and the use of an availability set for the domain controllers.
An illustration of update domains and fault domains in Azure [Image Credit: Microsoft]
An Illustration of Update Domains and Fault d=Domains in Azure [Image Credit: Microsoft]

Managed Disks

Availability sets sound like they give us ample protection but there was still a remaining single point of failure. The storage of the virtual machine disks was this point. It was possible for the virtual hard disks of virtual machines to be placed into a single Azure storage cluster. This cluster provides triple-redundancy of storage (LRS) to protect you against disk or JBOD (a tray of just-a-bunch-of-disks) failure and/or maintenance. It does not protect you against a certain outage profile. For example, a virtual machine availability set protects you against a localized outage within a fault domain. A similar style of outage in the Azure storage cluster could bring down all 3 copies of your virtual machines’ disks.

Managed Disks for virtual machines offer many benefits. This is quickly summarized as, “Azure just takes care of all the disk placement for you.” One of those benefits is that if you use Managed Disks with virtual machines in an availability set, then Azure will disperse the disks of the machines across different storage clusters within the data center. If one of the storage clusters fails, then the other copies of your disks remain online. Your service also remains online.

Converting Availability Sets to Managed Disks

It is possible to convert an availability set of virtual machines from unmanaged disks to Azure Managed Disks. The process understands that you require the service in the availability set to remain online throughout the upgrade process. The upgrade is done one virtual machine at a time. I have added a sleep command after each upgrade. This will occur before the next upgrade starts to add a buffer. Alternatively, you can request manual confirmation that the process should continue after each virtual machine upgrades. This would allow you to check that the last virtual machine is OK before allowing the upgrade to take place for the next machine in the availability set.

The conversion process is done using PowerShell. Note that you should have the latest version of the PowerShell modules. At the time of writing (February 2017), you also need to have the very latest ARM Compute module but this will probably be folded into later bundled installations:

Install-Module AzureRM.Compute -RequiredVersion 2.6.0 -AllowClobber

The PowerShell script for doping the conversion of virtual machines in an availability set is shared below:

$ResourceGroupName = "rg-petri"
$AVSetName = "as-petri"
$SubscriptionID = "1a2b3c45-aa12-1a23-12a3-a1bcdefg345h"
$Delay = 60


Select-AzureRmSubscription -SubscriptionId $SubscriptionID

Write-Host "`nRetrieving the availability set, $AVSetName"

$AVSet =  Get-AzureRmAvailabilitySet -ResourceGroupName $ResourceGroupName -Name $avSetName

Update-AzureRmAvailabilitySet -AvailabilitySet $AVSet -Managed

foreach($VMInstance in $ AVSet.VirtualMachinesReferences)
    $VM =  Get-AzureRmVM -ResourceGroupName $ResourceGroupName | Where-Object {$_.Id -eq $}

    $VMName = $VM.Name
    Write-Host "`nWorking on the virtual machine, $VMName"

    Stop-AzureRmVM -ResourceGroupName $ResourceGroupName -Name  $VMName -Force

    Write-Host "`nConverting the disks of virtual machine, $VMName, and then starting it"

    ConvertTo-AzureRmVMManagedDisk -ResourceGroupName $ResourceGroupName -VMName $VMName

    Write-Host "`nSleeping for $Delay seconds before proceeding"
    Sleep $Delay

    #You can replace the previous two lines with the following to allow for a manual verification before proceeding
    #Read-Host "Press Enter/Return to continue to the next virtual machine"


A few variables define the environment that will be upgraded:

  • ResourceGroupName: The name of the resource group that contains the availability set and virtual machines
  • AVSetName: The name of the availability set
  • SubscriptionID: The GUID of the subscription that contains the resources
  • Delay: How many seconds you want the script to wait between upgrading virtual machines

The first part of the script will request you to log into your Azure administrator account and then it will select the subscription that you defined in the SubscriptionID variable.

The AVSetName variable is used to retrieve the availability set resource and then the availability set is upgraded to a managed state. This supports the concept of Managed Disks. It instructs Azure to spread Managed Disks in the availability set across different storage clusters.

A for loop will then run and perform an upgrade on each virtual machine in the availability set. This will happen one at a time:

  1. The virtual machine is shut down to enable the upgrade.
  2. An upgrade command is run to convert the disks of the machine to Managed Disks. The process will automatically start up the virtual machine.
  3. A delay command pauses the script for the number of seconds stored in the Delay variable.

Note that I added a line, commented out using #, that you can use instead of the Sleep cmdlet. Doing this would replace the timed delay with a manual control, which stops the script from running until you press enter. You can use this approach if you want to manually check a converted virtual machine before continuing.


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (0)

Leave a Reply

Aidan Finn, Microsoft Most Valuable Professional (MVP), has been working in IT since 1996. He has worked as a consultant and administrator for the likes of Innofactor Norway, Amdahl DMR, Fujitsu, Barclays and Hypo Real Estate Bank International where he dealt with large and complex IT infrastructures and MicroWarehouse Ltd. where he worked with Microsoft partners in the small/medium business space.
External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by: