Moving a VM to a different virtual network in Microsoft Azure

At first glance, it may seem to be a trivial task to move a VM (virtual machine) to a different virtual network in Microsoft Azure. However, there are a couple of options available: Create a new VM using the information from the previous one or perform a backup/restore using Azure Site Recovery. In this article, we are going to start with a simple VM using a subnet (AP-VNET01). The same VM will have a couple of data disks associated with it. Our goal is to move this VM to a different virtual network, and we can see a graphical description of the scenario in the image below.
Moving a VM

We are going to delete the VM resource (not the data!), then we are going to provision a new VM using the same configuration. As part of the process, we will attach the data disks to make sure that the new VM has the same settings as the original.

Moving a VM between virtual networks: The issue

If you have never done this, you may be worrying about the two possible options I mentioned, but don’t worry! We are going to cover them both in this section. The goal is to understand where lies the problem that we are trying to solve and how we can address the issue adequately. The first option is to remove the current virtual network interface (vNIC), and then attach a new one in the new virtual network/subnet. Easy peasy, right?

If you have ever tried to remove the primary vNIC, you will get an error stating that “Failed to detach network interface <InterfaceName> from virtual machine <VMName>. Error: Virtual Machine <VMName> must have at least one network interface.” That is not good, so the option to remove the primary vNIC is out of the question, and now we understand why.

If you cannot beat them, join them! We know that we cannot remove the primary vNIC, so the next logical step is to add a second vNIC to a different virtual network. Then, the final step would be the removal of the first one, and bob is your uncle! Here we will face another type of issue. When adding a vNIC, we cannot choose the virtual network, just the subnet. Long story short, a VM must have all vNICs in the same virtual network.

Moving a VM

Moving a VM between virtual networks

The first step is to log on to our desired virtual machine, and we are going to run these following commands in a command prompt to find the VM name and IP address. We can see by the results that we are connected to AP-VNET01 virtual network.

hostname
ipconfig

Moving a VM

I would recommend taking a screenshot or the output of the VM configuration before performing any changes. Our next step will be the re-creation of the VM (spoiler alert, we are about to delete this VM), and we want the same VM and disk configuration. The process to move between virtual networks requires some outage and destruction. Let’s keep a positive attitude, and we can call it the “Phoenix process” because, like in Greek mythology, the result will be a reborn VM in the desired virtual network.

After scheduling some downtime (a few minutes, but your mileage may vary), we are going to start by stopping the virtual machine using Azure Portal. Note: If the VM has a public IP associated with it, the chances are that the IP will change when we start it again.

That is the destruction part that I mentioned before. Let’s delete the VM by clicking on delete and confirm by clicking on Yes. The deletion of a VM from the VM Blade Properties will not delete disks and virtual network interfaces.

The result of the VM deletion process can be seen in the image below. We have all the data disks, OS disk, public IP address, network security group, and network interface still available at the Resource Group level.

Moving a VM

Time to start creating a new VM. Click on the OS Disk from the list, and the new blade, click on Create VM.

Moving a VM

In the Basics tab of Create a virtual machine wizard, we are going to notice that the Image is our OS disk — which is good. Select the Size of the new VM (use the same settings from the VM that we have just deleted) and click Next.

In the Disks tab of Create a virtual machine wizard, add the data disks (if they exist in the original VM), the name of the data disks should give you a good idea of the order. In a worst-case scenario, check the screenshot or output that you generated from the original VM before deleting it.

Moving a VM

Here is the silver bullet: Finally, we can pick the virtual network where we want to place the new VM (with the old data). Complete the wizard and wait for the provision of the new virtual machine.

Moving day is complete!

You may have to configure NSGs (in case you are using them at the network interface level). After logging on to the new VM and running the same cmdlets that we ran at the beginning of this article, the idea is to have the same VM but in the new virtual network.


Featured image: Shutterstock

About The Author

7 thoughts on “Moving a VM to a different virtual network in Microsoft Azure”

  1. Hi Anderson,

    Thanks for sharing. It’s really helpful.

    I did the same thing in a different way so just thought to share here.

    1- Export the JSON template of VM
    2- Delete the VM
    3- Created new NIC to the desired Vnet
    4- Made few changes in exported JASON template,
    A- Remove image reference section from template:
    “imageReference”: {
    “publisher”: “Canonical”,
    “offer”: “UbuntuServer”,
    “sku”: “18.04-LTS”,
    “version”: “latest”
    },
    B- Remove OS profile section from the template:
    “osProfile”: {
    “computerName:”[parameters(‘virtualMachines_vm01_name’)]”,
    “adminUsername”: “admin”,
    “linuxConfiguration”: {
    “disablePasswordAuthentication”: false,
    “provisionVMAgent”: true
    },
    “secrets”: [],
    “allowExtensionOperations”: true,
    “requireGuestProvisionSignal”: true
    },
    C- Change “create option” to Attach under os Disk:
    “caching”: “Attach”
    5- Use the same exported template to create the VM.

  2. Hi Anderson

    Excellent article. I found this while doing some searching as I was looking at moving MV’s between subscriptions and vNets.

    Followed this to the tee, however I do have an issue accessing the VM via the new Public IP after migrating it. This just wont work anymore, any pointers?

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top