Earlier last month, Microsoft announced the general availability of managed disks. This has been one of the most heavily requested Azure features in the past for many reasons. Below are some big benefits of managed disks:
- Centralized management and automatic configuration – VHDs are now all stored on a centralized storage account instead of having them spread out on multiple storage accounts. In the past, you would need to do this to get higher IOPS as well but this is no longer the case with managed disks as it is all configured automatically in the back end.
- Storage disks inside an availability set are isolated at the hardware level – Some people might not of been aware of this, but previously you could have had your VMs knocked out if the underlying storage cluster failed regardless of whether or not they were in an availability group.
- Snapshots (full disk copy) support – You will now be able to have a point in time backup. It works on both standard and premium disks. This is very useful for in place upgrades as you can easily rollback if any issues arise. If you striping multiple disks with storage spaces, snapshots would not be aware of this configuration so that scenario is not supported. Incremental snapshot support is expected in the future at a later date.
- Image support – You can create an OS “image” from a VM and deploy it to another VM. The image includes any attached disks.
With that being said, the biggest limitation to managed disks at the moment is that Azure Storage Service Encryption (SSE) for data at rest is not supported. If you have SSE enabled and you want to migrate to managed disks, you will have to create a new storage account that doesn’t have SSE enabled. Copy the VHDs to that storage account and re-create the VM with the VHDs as managed disks.
If you don’t have SSE enabled, below is a quick outline to migrate from unmanaged to managed disks for most people. Make sure you backup all your VHDs prior to migrating. We cannot be held responsible for any unexpected changes to your environment.
- Convert your availability set to a managed availability set – If your VMs are in an availability which they most likely are, you need to first convert it to a “managed availability set”. Your VMs will be de-allocated and restarted during this process. If your VM is not part of an availabilty set, you can go ahead to step 2. Additional information can be found here.
12345678910111213141516$rgName = ‘myResourceGroup’$avSetName = ‘myAvailabilitySet’$avSet = Get–AzureRmAvailabilitySet –ResourceGroupName $rgName –Name $avSetNameUpdate–AzureRmAvailabilitySet –AvailabilitySet $avSet –Managedforeach($vmInfo in $avSet.VirtualMachinesReferences){$vm = Get–AzureRmVM –ResourceGroupName $rgName | Where–Object {$_.Id –eq $vmInfo.id}Stop–AzureRmVM –ResourceGroupName $rgName –Name $vm.Name –ForceConvertTo–AzureRmVMManagedDisk –ResourceGroupName $rgName –VMName $vm.Name} - Migrate your disk – This step is only to migrate unmanaged standard disks to managed standard disks or unmanaged premium disks to managed premium disks. Additional information can be found here.
1234567$rgName = “myResourceGroup”$vmName = “myVM”Stop–AzureRmVM –ResourceGroupName $rgName –Name $vmName –ForceConvertTo–AzureRmVMManagedDisk –ResourceGroupName $rgName –VMName $vmName
There is a way to migrate from an unmanaged standard disk to a managed premium disk at this time but it’s not the smoothest process and there’s reports of it simply not working – additional information can be found here.
Great Info Vatsana. Thanks