There's probably multiple ways to do this, both right and wrong, but, here's a process that I've been using for a while that I've recently tweaked to take advantage of new Azure Managed Disks.
Sidebar - standard managed disk warning
Before I go on though, I wanted to issue a quick warning about the differences between standard unmanaged and managed disks. Microsoft will be pushing you to you Managed Disks more and more. Yes, its a great feature that makes the management of VM disks simpler. The key bit of information though is as follows:
- If you provision an unmanaged disk that is 1Tb in size, but, only use 100Gb, you are paying for 100Gb of storage costs. So you're only paying for what you use. 1
- If you provision a managed disk that is 1Tb in size, but, only you 10Mb, you will be paying for the privilege of the whole 1Tb disk 2
- Additionally, Premium disks, you're paying for what you provision no matter if its managed or unmanaged
That aside, Managed Disks are a pretty good feature that makes disk and storage account management considerably simpler. If you're frugal with your VM allocation and have the process to manage people and technology correctly, Managed Disks are great.
I've gone through this recently and updated it so that it's as streamlined, for me, as possible. Again, this is skewed towards managed disk usage, but, can easily be extended to be used with unmanaged disks as well. Lets begin:
Step 0 ?
If you're wanting to do this to create copies of your VM instances, to scale out your workload, remember to generalise or sysprep your VM instance prior to Step 1. In the example I go into below, my use case was to create a copy of a server from a production environment (VNET and subscription) and move it to different and seperate non-production environment (seperate VNET and subscription).
The first thing we need to do is actually power off your virtual machine instance. I've seen that snapshots can happen while the VM instance is running, but, I guess you can call me a a little bit more old school, a little bit more on the cautious side when it comes to these sorts of things. I've been bitten by this particular bug in the past, unpleasant it was; so i'm inclined to err on the side of caution.
Once the VM instance is offline, go to the Azure Portal and search for “Snapshots”. Create a new snapshot.
One the snapshot is created, complete this quick next step to generate an export access URL (we'll need this in step 2):
The next part relies on PowerShell. Update the following PowerShell script with your parameters to copy the snapshot to Blob:
$storageAccountName = "<storage account name>" $storageAccountKey = “<storage account key>” $absoluteUri = “https://blahblahblah.blob.core.windows.net/blahblahblah/........” $destContainer = “<container>” $blobName = “server.vhd” $destContext = New-AzureStorageContext –StorageAccountName $storageAccountName -StorageAccountKey $storageAccountKey Start-AzureStorageBlobCopy -AbsoluteUri $absoluteUri -DestContainer $destContainer -DestContext $destContext -DestBlob $blobName
Just for your info, heres a quick explanation of the above:
Before we actually create a new VM instance based on this snapshot blob, there is an additional option we could take. That is, perhaps it would make sense to move the blob to a different subscription. This is particularly handy when you would have a development environment that you would want to move to production. Other use cases might be the inverse- making a replica of a production system for development purposes.
The absolute fastest way to do this, as I don't like being inefficient here is with the Azure Storage Explorer (ASE) tool. Its an application that provides a quick GUI for completing storage actions. If you add in both the storage accounts in the ASE, you can as easily as this:
It can't get any simpler or faster than that. I'm sure if you're command line inclined, you have a quick go to PowerShell cmdlet for that, but, for me, I've found that to be pretty damn quick. So it isn't broken, why fix it.
The final piece of the puzzle, as the cliche would go, is to create a new virtual machine instance. Again, as the wonderfully elusive and vague title of this blog post states, we'll use PowerShell to do this. Sure, ARM templates would work and likely the Azure Portal can get you pretty far as well. However, again I like to be efficient and I've found that the following PowerShell script does this the best.
Additionally, you can change this up to mount the VHD from blob, vs create a new managed disk as well. So, for purpose of creating a new machine, PowerShell is as flexible as it is fast and convenient.
Here's the script you'll need to create the new VM instance:
#Prepare the VM parameters $rgName = "<resource-group-name>" $location = "australiaEast" $vnet = "<virtual-network>" $subnet = "/subscriptions/xxxxxxxxx/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network>/subnets/<subnet>" $nicName = "VM01-Nic-01" $vmName = "VM01" $osDiskName = "VM01-OSDisk" $osDiskUri = "https://<storage-account>.blob.core.windows.net/<container>/server.vhd" $VMSize = "Standard_A1" $storageAccountType = "StandardLRS" $IPaddress = "10.10.10.10" #Create the VM resources $IPconfig = New-AzureRmNetworkInterfaceIpConfig -Name "IPConfig1" -PrivateIpAddressVersion IPv4 -PrivateIpAddress $IPaddress -SubnetId $subnet $nic = New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $location -IpConfiguration $IPconfig $vmConfig = New-AzureRmVMConfig -VMName $vmName -VMSize $VMSize $vm = Add-AzureRmVMNetworkInterface -VM $vmConfig -Id $nic.Id $osDisk = New-AzureRmDisk -DiskName $osDiskName -Disk (New-AzureRmDiskConfig -AccountType $storageAccountType -Location $location -CreateOption Import -SourceUri $osDiskUri) -ResourceGroupName $rgName $vm = Set-AzureRmVMOSDisk -VM $vm -ManagedDiskId $osDisk.Id -StorageAccountType $storageAccountType -DiskSizeInGB 128 -CreateOption Attach -Windows $vm = Set-AzureRmVMBootDiagnostics -VM $vm -disable #Create the new VM New-AzureRmVM -ResourceGroupName $rgName -Location $location -VM $vm
Again, let me explain a little the parameters we've set that the start of the script:
And that is pretty much that!
It's Friday in Sydney. Its the pre-kend and it's a gloomy, cold 9th day of Winter 2017. I hope that the above content helps you out of a jam or gives you the insight you need to run through this process quickly and efficiently. That feeling of giving back, helping. That's that feeling that should warm me up and get me to lunch time! Counting down!