Importing virtual machines across labs

The Azure DevTest Lab service significantly improves management of virtual machines for development and testing activities.  However, team or infrastructure requirements change over time and we need to adapt our current activities to meet the new requirements – to enable this adaptation we’re introducing the ability to import Virtual Machines to another lab!


In our experience working with enterprise customers, here are some common reasons we’ve received this feature request:

  • An individual on the team is moving to another group within the enterprise and wants to take his developer desktop with him to his new team’s DevTest Lab
  • The group has hit a subscription-level quota and wants to split up the teams into a few subscriptions
  • The company is moving to Express Route (or some other new networking topology) and the team wants to move the Virtual Machines to leverage this new infrastructure

Solution and Constraints

This new feature enables the lab owner to kick off an ‘import’ of a source Virtual Machines into a destination lab, optionally giving the destination Virtual Machine a new name in the process.  This process includes all the dependencies like disks, schedules, network settings, etc.  The process does take some time and is impacted by the number/size of the disks attached to the source machine (since it’s a ‘copy’ and not a ‘move’) and the ‘distance’ to the destination (East US region to Southeast Asia region for example).  Once the process is complete, the source Virtual Machine remains shutdown and the new one is running in the destination lab.

There are two key constraints to be aware of when planning to import Virtual Machines to another DevTest Lab:

  • Virtual Machine imports across subscriptions & across regions are supported, but the subscriptions must be associated to the same Azure Active Directory tenant
  • Virtual Machines must not be in a ‘claimable’ state in the source lab

Along with this, to be able to import a virtual machine from one lab to another, you need to be the owner of the VM in the source lab and owner of the lab in the destination lab.

Currently, this feature is supported only through a Powershell script located here and via the REST API.

Sample Powershell Usage – Import a single machine

Executing the powershell script requires identifying the source Virtual Machine and the destination lab, and optionally supplying a new name to use for the destination machine:

./ImportVirtualMachines.ps1 -SourceSubscriptionId "929ae747-879f-4692-975b-e4c56768f609" `
                            -SourceDevTestLabName "WestUS_VMs" `
                            -SourceVirtualMachineName "MyVm" `
                            -DestinationSubscriptionId "ad1c93d1-51a3-4dc0-b620-64a8bdcc1b57" `
                            -DestinationDevTestLabName "EastUS_VMs" `
                            -DestinationVirtualMachineName "MyVmNew"

Sample Powershell Usage – Importing all machines from a DevTest Lab

If the Source Virtual Machine isn’t specified, the script will automatically import all Virtual Machines in the DevTest Lab.  For example:

./ImportVirtualMachines.ps1 -SourceSubscriptionId "929ae747-879f-4692-975b-e4c56768f609" `
                            -SourceDevTestLabName "WestUS_VMs" `
                            -DestinationSubscriptionId "ad1c93d1-51a3-4dc0-b620-64a8bdcc1b57" `
                            -DestinationDevTestLabName "EastUS_VMs"

Sample HTTP REST usage

The REST call is simple; just enough information to identify the source and destination resources – just remember that the operation takes place on the destination lab resource:

   sourceVirtualMachineResourceId: "/subscriptions/929ae747-879f-4692-975b-e4c56768f609/resourcegroups/WestUS_VMs_rg/providers/microsoft.devtestlab/labs/WestUS_VMs/virtualmachines/MyVm",
   destinationVirtualMachineName: "MyVmNew"

We hope you find this new feature useful!

Got an idea to make it work better for you?

Submit your feedback/ideas or vote for others at Azure DevTest Labs UserVoice forum.

Have a question? Check out the answers or ask a new one at MSDN forum.


Avi Pilosof, Senior Software Engineer

Avi is part of the Developer Division IT team, spending most of his time building internal tools. He has been with Microsoft for 18 years, most of that working remotely from Sydney.

image Peter Hauge, Principle Software Engineer

Peter is part of the Visual Studio and .Net engineering team focused Visual Studio and Azure customers. He has been at Microsoft for 15 years, working on developer technologies throughout that time.

Comments (0)

Skip to main content