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.
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.
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.
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.
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.
Time to start creating a new VM. Click on the OS Disk from the list, and the new blade, click on Create 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.
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.
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
Deep fakes are a catastrophe waiting to happen. Facebook’s attempt to create a tool that differentiates between real and fake…
Microsoft Intune is getting a bunch of new updates that will streamline the administration experience for users of the popular…
As businesses evolve into a SaaS/IaaS model for accessing applications, new network technology is crucial. SD-WAN is just such a…
What you don’t know about Exchange and your network can come back to bite you. Monitoring Exchange is one way…
Warnings are nice, except when they are annoying and unnecessary. Here’s a tip to show you how to remove warning…
Having a Group Policy Central Store in Active Directory made life easier for administrators. But does it still work in…