Moving a Windows Server or Linux virtual machine (VM) in Azure between virtual networks isn't as easy as you might think at first glance.

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

In Microsoft Azure, the virtual network (Vnet) is the fundamental communications boundary in an Azure subscription.

Migrate an Azure VM to another subnet ^

Within a virtual network, it is trivially easy to move a Windows Server or Linux VM between subnets. Let us count the ways:

  • Azure portal
  • Azure PowerShell
  • Azure CLI v2.0
  • Azure software development kits (SDKs)
  • REST API

In the Azure portal, for example, browse to a virtual machine's virtual network interface card (vNIC) configuration blade. Once there, navigate to the IP configurations settings blade. As shown in the following screenshot, the Subnet drop-down list box makes it easy to move between subnets within a single Vnet.

Assign a VM to another subnet in the same Vnet

Assign a VM to another subnet in the same Vnet

Migrate an Azure VM between VNets ^

However, the situation takes on a different difficulty level when we need to move a VM between Vnets. Now, of course you have options for linking Azure virtual networks:

  1. Vnet-to-Vnet VPN
  2. Vnet peering (now between regions!)

The reason for this complexity is the fact I mentioned earlier, that Vnets represent communication isolation boundaries in Azure. It's by design, in other words. That said, you may have a use case that requires you to perform the migration. How can you accomplish this goal?

The first thing to accept is that Microsoft does not support Vnet-to-Vnet VM migration, and you'll have to redeploy the VM regardless. So—you need to plan for some downtime.

Historically, the Vnet-to-Vnet migration process in Azure required the following steps:

  1. Stop and deallocate the VM.
  2. Delete the VM, but save its virtual hard disks (VHDs).
  3. Recreate the VM in the target Vnet by specifying the original disk.

You can accomplish the preceding (tedious) procedure by using many different methods, including:

The main gotcha with this approach is that of dependencies. Remember that a VM consists of more than a configuration and one or more VHDs. The vNIC is, in turn, linked to one or more IP configurations. These IP configurations determine the Vnet and subnet to which the VM is linked.

The following idea isn't supported and doesn't work, but I wanted to give it to you for completeness' sake.

Imagine if you could hack a Vnet-to-Vnet VM migration by following this recipe (which requires Azure PowerShell):

  1. Add a new vNIC in the target Vnet.
  2. Associate the new vNIC to the target VM; the VM will therefore be multihomed.
  3. Make the new secondary vNIC primary and the old primary vNIC secondary.
  4. Detach the secondary interface.

As a commenter verified in this Azure docs article, attempting the previous procedure generates the following error:

Watch this space, however—the Azure product groups tinker with their features every single workday, and we may be able to do something like this in the future.

The Recovery Services method ^

It seems to me that using Azure VM Backup presents the path of least resistance to accomplish our goal of migrating a VM to another Vnet.

Here is the high-level overview of this recipe:

  1. Create a Recovery Services vault in the same region as your VM.
  2. Onboard the target VM to Recovery Services and initiate a manual backup.
  3. Ensure your target Vnet is ready to receive the VM.
  4. Stop and deprovision the target VM.
  5. Restore the backed-up VM to the target Vnet.

In my environment, I have two Vnets, as shown in the next screenshot.

Multiple Vnets in Azure

Multiple Vnets in Azure

My adVM Windows Server VM resides on the adVNET Vnet in the adSubnet subnet. Our goal is to move the VM to the infra subnet in the adVNET2 Vnet.

The VM before the migration

The VM before the migration

We need to shut down and deallocate the source VM so we don't get resource conflicts after restoring the backed-up copy. Let's do that with Azure PowerShell:

Stop-AzureRMVM -ResourceGroupName '4sysops' -Name 'adVM' -Force

Next, in the Azure portal we will browse to Recovery Services Vault > Your Vault Name > Backup Items > Azure Virtual Machine > adVM (whew, that's a long path!) and click Restore VM. I show you this in the following screenshot.

Starting the VM restore process

Starting the VM restore process

Select the most recent restore point, and then be sure to specify the destination Vnet and subnet in the Restore configuration blade, shown next.

The most important step in the migration process

The most important step in the migration process

Two important notes are worth mentioning:

  • If you want to keep the VM's name the same, you need to restore the object into another resource group if the source VM hasn't already been removed.
  • If you need more configuration flexibility than what is shown in the Azure portal, you'll need to invoke Azure PowerShell.

Wrap-up ^

Well, there you have it! I hope that you're in a better place now in terms of what's possible with VM network migration in Microsoft Azure.

Are you an IT pro? Apply for membership!

Your question was not answered? Ask in the forum!

3+
Share
7 Comments
  1. Oleksiy Pavlenko 2 years ago

    So there is no way of achieving the same with attaching/detaching network cards for Resource Group Deployment model?

    1+

    • Chris neale 2 years ago

      No. You can't detach the last NIC and you can't add a new NIC that is connected to a subnet that is in a different VNet.

      3+

  2. Ganesh 2 years ago

    I tested this(Playing around with NIC's to switch between VNET's) and failed 🙂

    2+

  3. Richard 2 years ago

    I wanted to change a VM that was assigned to a VNET with 10.0.0.0/16 address space to a VNET with a smaller address space e.g. 10.3.0.0/24 so I basically added the new address space, created a new network interface.  Now you have 2 NIC's in same VNET so you can add one then remove the other.  Then you need to go through a disassociate/delete/reassociate process (note VM must be stopped (deallocated).  So yes you can't move VM between VNET easily but can restructure existing VNET with scary backup/restore & now global VNET peering is GA getting VM's where you need them is much easier/cheaper.

    1+

  4. Richard 2 years ago

    *meant to say "without scary backup/restore"

    1+

  5. Isaac 1 year ago

    great suggestion. I've done the redeploy method a couple of times and found it to be tedious. I have a vm that has multiple NICs and encryption(as well as the temp drive changed to a different letter), so I have my work cut out for me. I believe just doing a restore will be key here. Its already backing up anyway, so doing the restore will likely save me some time

     

    1+

  6. Luis Simões 11 months ago

    What if you want to move the VM to a different subscription with a different Vnet and you cannot move the old Vnet because it will still be supporting other things on the source subscription?

    3+

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2019

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account