Register an Azure VM Image from VHDs
During my recent activities for one of my partners, an interesting request raised: how we can export or publish or share a VM image between different subscriptions? In the ISV/CSV world is pretty common to have the possibility to create an image in a “factory” subscription and then use it in different subscriptions, whenever owned by the ISV/CSV itself or by the final customer. After investigations, I found that at the moment Azure does not permit (yet) sharing images between different Azure subscriptions. Here I need to be careful about what “sharing” means: in theory, you could either copy the image VHDs or simply share a link, in a second subscription, to the original one, that is no physical copy at all. Regarding the latter, it is not possible today, I heard about future improvements in this area but cannot confirm. Regarding the former, it is pretty easy to copy image multiple VHDs, in case of specialized images with additional disks, or single OS VHD, in case of generalized image. The perfect tool to use is AzCopy that supports this kind of scenarios:
AzCopy – Using Cross Account Copy Blob
For more information on generalized and specialized VM images, see the link below:
VM Image
http://azure.microsoft.com/blog/2014/04/14/vm-image-blog-post
QUESTION: a VM must be shut down before running the copy operation? For generalized images, the answer is yes, but for specialized images, it is not strictly required: you can take a “hot” snapshot of the underlying disks even with VM running (OS and data disks), then copy from the snapshots in the current subscription to the target subscription as autonomous disks. Anyway, I would recommend shutting down the VM anyway since if you have multiple disks, you need to start snapshot on each disk and this cannot be done exactly at the same time for each disk. Additionally, as you can read in the print screen below, data in memory will be not ported with the image.
Before being able to register VHDs as image, you need to be sure that both the following actions/conditions are satisfied:
- There is no Azure VM associated to those disks: if YES, you need to delete the VM from the Azure Portal being sure to do not remove the underlying disks.
- There is no Azure Disk associated to those VHDs: if YES, you need to delete the Disk from the Azure Portal being sure to do not remove the underlying VHDs/Blobs.
Now that you have a copy of the OS disk and eventually additional data disks, how you can register them as an image in the current subscription? I verified that there is no PowerShell cmdlet or Azure Portal function to register a VM image from existing VHDs, but there is a REST API that I’m going to use:
Create VM Image
https://msdn.microsoft.com/en-us/library/azure/dn775054.aspx
If you examine the XML structure of the request body and related specifications, you can see that this REST API supports additional data disks for specialized images:
Now, since I am a great fan of PowerShell, let me report here (attached to this blog article) a sample script to encapsulate this REST API and complete the task. Please be aware that this script is only an example and provided “as-is” then no official warranty from Microsoft or me (kudos to Christine Avanessians). In the first part of the script, you need to fill in some parameters related to your subscription and image disks, and then here is the core of the script, that is the REST API request body. In this example, I used a VM with a data disk in addition to the mandatory OS disk:
Now, you only need to use PowerShell Invoke-WebRequest to fire the REST API call and check for 200 – OK success return code:
Since this is an asynchronous API call, you need to check the status using the cmdlet below and wait until the request will be completed:
Now, if you try to create a new VM using an image from the Azure Gallery in the Portal, you will see something like this in the “My Images” section:
If you want to check your image listed in the catalog using PowerShell you can use the cmdlet below:
Finally, be careful with the location/region of your image: each time you create an image there is a region associated, that is it is not replicated in foreign regions, then you need to eventually repeat the register image operation in different regions. The location associated to the image is, by design, the one where the storage account containing the source VHDs reside.
That's all folks! I hope you will finds this content useful, your comments are welcome!
As usual, you can also follow me on Twitter at @igorpag. Regards.