- Azure PowerShell vs. Azure CLI - Wed, Mar 15 2023
- Use Azure Storage for backup - Thu, Feb 23 2023
- Azure Data Studio vs. SQL Server Management (SSMS) - Wed, Feb 8 2023
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
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:
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:
- Stop and deallocate the VM.
- Delete the VM, but save its virtual hard disks (VHDs).
- 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):
- Add a new vNIC in the target Vnet.
- Associate the new vNIC to the target VM; the VM will therefore be multihomed.
- Make the new secondary vNIC primary and the old primary vNIC secondary.
- Detach the secondary interface.
As a commenter verified in this Azure docs article, attempting the previous procedure generates the following error:
ErrorCode: SubnetsNotInSameVnet
ErrorMessage: Subnet customer-subnet-01 referenced by resource {ipconfig_resource_id} is not in the same Virtual Network {vm_resource_} as the subnets of other VMs in the availability set.
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:
- Create a Recovery Services vault in the same region as your VM.
- Onboard the target VM to Recovery Services and initiate a manual backup.
- Ensure your target Vnet is ready to receive the VM.
- Stop and deprovision the target VM.
- 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
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
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
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
Two important notes are worth mentioning:
Subscribe to 4sysops newsletter!
- 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.
So there is no way of achieving the same with attaching/detaching network cards for Resource Group Deployment model?
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.
I tested this(Playing around with NIC’s to switch between VNET’s) and failed 🙂
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.
*meant to say “without scary backup/restore”
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
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?
The only way & Easy way
Take a snapshot of the OS disk, move it to a new subscription and then create a new disk from this moved snapshot. Now, re-create same configured VM to have it in a new sub and new VNET.
Hi, I found this article when searching for a way to move an Azure VM to another vnet. I tried the Azure backup and restore but found it was a long process waiting for the VMs to be restored. After much googling I found there were other ways to move a VM, mainly be deleting and re-creating it. These steps were quicker but riskier due to lots of manual steps and if you made a mistake you could permanently lose your VM! Long story short I decided to automate it all with PS script and noticed there was nothing like on the net so finally decided to write my own blog post and share it.
Just thought I'd mention it here as an alternative to the backup and restore method if that's ok with you? Might help some others out like me!
Thanks!
https://think-like-a-computer.com/2020/02/06/azure-move-vm-to-another-vnet-powershell/
Easy way is to delete the VM which stores the disk. Then go to the disk and create a New VM under new VNET.
Take a look at this script which I created:
https://stackoverflow.com/a/61543545/12172680
You can just use the “-newSubnetId” parameter