How to Move Azure VMs from One Subscription to Another
How to Move Azure VMs from One Subscription to Another
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
Quite recently I was helping somebody out on MSDN forums with a question about Windows Azure Virtual Machines (IaaS). One thing that came up on that thread is how would one move their VMs from one subscription to another. There could be many reasons as to why one would want to do this. One possible scenario is that you started trying these features out in a subscription which was tied to your personal account and now you want to move that to a subscription associated with your official account. Another reason could be that you wish to move VMs from one data center to another (e.g. EU to US). I found one way of doing so which I am about to describe in this post. To be honest, it is rather a very convoluted process. If you think of better ways to accomplish this or if you’re doing it some other way, please let me know by providing your comments.
How it is accomplished?
Since the Windows Azure Virtual Machines are stored as page blobs in blob storage, mostly we’ll rely on the new asynchronous copy blob functionality to copy the blobs storing the virtual machines and data from storage account in 1st subscription (Source) to another storage account in 2nd subscription (Target). Then we’ll add these as disks and create VMs using those in the target subscription.
Again, I don’t really use VMs that much so I created a bunch of VMs using Windows Azure Platform Training Kit exercises. The one I followed is “Introduction To Windows Azure Virtual Machines” Hands On Lab. You can download the kit from here: http://www.microsoft.com/en-us/download/details.aspx?id=8396.
Once I completed the exercise, this is how things look on the portal for me. Essentially I have 2 VMs – One for the web server, one for the SQL Server and 4 Disks – 2 for VMs and 2 for SQL Server Data and Logs:
If I explore my Blob Storage, I will see 4 page blobs in “vhds” blob container. For obvious reasons, I used Cloud Storage Studio
When I run my application, this is what I see in the browser.
Now let’s try and move this application to another subscription.
I followed the steps below to move my VMs from one subscription to another.
Step 1 – Copy Blobs
First we’ll copy these blobs into a storage account in the target subscription. To do so, we can make use of Asynchronous Copy Blob functionality. You can read more about this functionality on Windows Azure Storage Team Blog here: http://blogs.msdn.com/b/windowsazurestorage/archive/2012/06/12/introducing-asynchronous-cross-account-copy-blob.aspx. I have also written a blog post with code sample to copy an object from Amazon S3 to Windows Azure Blob Storage. You can read that post here: http://gauravmantri.com/2012/06/14/how-to-copy-an-object-from-amazon-s3-to-windows-azure-blob-storage-using-copy-blob/ (You can download the source code of the Visual Studio project from here). All you have to do is provide appropriate values for various variables there. For “amazonObjectUrl” variable, you would need to provide the URL for the blobs. Richard Conway from ElastaCloud has also written a blog post about copying blobs across storage accounts which you can read here: http://blog.elastacloud.com/2012/07/04/copying-azure-blobs-from-one-subscription-to-another-with-api-1-7-1/. When copying blobs from source to target storage account, there are a few things to remember:
- Make sure that your target storage account is created after 7th June 2012 otherwise asynchronous copy blob operation will fail. If the target storage account is created before 7th of June 2012, you would need to first download the blobs on your computer and then upload them again as page blobs in the target storage account. You could use Cloud Storage Studio or any other storage explorer tool which supports downloading page blobs sparsely i.e. which only downloads the pages which are occupied or in other words downloads the pages containing non-zero bytes.
- Since the blob container holding your blobs has a private ACL, for asynchronous copy to work, either you would need to make that blob container public (not recommended) or generate a signed URL using Blob Shared Access Signature with at least “Read” permission on the blobs (recommended). Again you could use Cloud Storage Studio or any other storage explorer which allows generation of signed URLs.
After the copy operation is completed, I see the same 4 page blobs in my target storage account.
Step 2 – Create Disks
Next we’ll create disks from these page blob VHDs for our IIS Server and SQL Server. To do so, on the portal, click on Virtual Machines –> DISKS –> CREATE DISK and follow the wizard.
You would need to do for all 4 page blob VHDs. For the disks which contain the operating system, you would need to specify so by checking the checkbox which reads “This VHD contains an operating system”. Once you’re done with this, you should see the new disks in the portal.
Step 3 – Create VMs and Attach Disks
Next step would be to create VMs. To do so, on the portal click on NEW –> VIRTUAL MACHINE –> FROM GALLERY
On the subsequent screen, click on MY DISKS option and select one VM.
Once the VM has been set up and in running state, I can RDP into that box and see exact same settings as that of the previous one.
In my scenario, I will do the same thing for my SQL Server VM.
Since with the SQL Server VM in the 1st subscription we attached 2 disks (to store the data) we would need to do the same here as well. To do so, select the SQL Server VM and click on ATTACH icon on the bottom and choose ATTACH DISK option there.
In my case, I needed to do this 2 times as I had 2 data disks. Once I am done with all of these, this is what I see in the portal.
I was expecting to see my website up and running on my 2nd subscription but got an error instead. I guess the reason for that being my SQL Server VM (and hence SQL Server) was brought up before I could attach the disks containing data. I rebooted the SQL Server VM and once it came back up, I accessed my site and it was live and kicking!!!
Step 4 – Clean Up
Last and final step is clean up which is essentially deleting the VM and associated blobs from the source subscription. These are large blobs and you don’t want to pay for storing the blobs in case you don’t want to use them anymore. To clean up data from the source subscription:
- Detach the disks you attached.
- Delete the VMs
- Go into DISKS menu and delete those disks from there. IMPORTANT – Please note that deleting those disks from the portal doesn’t physically delete them from blob storage. This process just removes the locks (leases) from these disks so that you can delete them using any storage explorer. If you don’t need those disks anymore, please delete them to avoid storage charges.
- Now delete all the disks using a storage explorer.
In this blog post, we saw that how we can move Windows Azure VMs across subscriptions. Obviously my scenario was rather simple and the VMs were not in a complex configuration. By and large, this was all made possible by Windows Azure team’s foresight of keeping the virtual machine’s and other VHDs as page blobs in blob storage. Also having asynchronous blob copy functionality across storage accounts helped immensely by cutting down the blob copy time significantly. In my case both storage accounts were in the same region and I was able to transfer 4 blobs totaling 70 GB (30 GB + 30 GB + 5 GB + 5 GB) in less than a minute.
I hope you have found this information useful. As I said at the start of my blog post, if there are better ways to accomplish this please feel free to share by providing comments below. If you think I have made some errors and provided some incorrect information, please feel free to correct me by providing comment. I’ll fix those issues ASAP.
Published at DZone with permission of Gaurav Mantri , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.