- Interact with Azure Cosmos DB with PowerShell - Tue, Sep 14 2021
- Azure health services: Track Microsoft cloud outages and maintenance - Wed, Sep 8 2021
- Powerline: Customize your PowerShell console - Tue, Aug 31 2021
If you have worked with virtual machines (VMs) in Azure, you understand how simple it is to change the subnet assignment for a VM in a virtual network. Specifically, the option exists in the Azure portal on the IP configurations settings blade for the VM's virtual network interface (vNIC). I show you the interface in the screenshot below.
However, moving a VM to another vNet is not a trivial task. The reason for this difficulty, I believe, centers on the nature of the vNet itself. Remember in Azure that the virtual network is a fundamental, strong isolation boundary for network resources. You need to deploy either a vNet-to-vNet VPN connection or a peering relationship to link two vNets, for instance.
But today I'd like to show you how we can move a VM to a new virtual network by using, of all things, Azure VM Backup and the Recovery Services vault.
Our scenario ^
Take a look at diagram below, which depicts our current Azure environment.
For simplicity, let's assume that all resources reside in a single Azure region. Our dc1 VM currently resides in the adSubnet subnet of the advNet virtual network. That was a configuration mistake—we actually need this VM located on the front subnet of the advNet2 virtual network.
You'll notice that the private IPv4 addressing scheme is different for the two vNets. It is possible to preserve the original address ranges, but in this simple use case we will implement a different IPv4 range.
Remember also that a VM in Azure is much more than a simple VM running either Windows Server or an Azure-endorsed Linux distribution. Many dependencies exist, including:
- OS and data virtual hard disks (.VHDs)
- Virtual network interface card (vNIC)
- Public IP address(es)
- Network security group (NSG) assignments
- Storage account(s)
The high-level overview of what we are about to do is as follows:
- Back up the dc1 VM to a Recovery Services vault.
- Shut down dc1 in the source vNet.
- Ensure the destination environment is in place.
- Restore dc1 to the destination vNet.
- Clean up any dependencies and/or recreate objects as required.
Back up the VM ^
Navigate to the VM's configuration blade, select the Backup option, and follow the instructions to enable VM backup. You must specify the following:
- Recovery Services vault: This container holds your backups. You can create one here if you don't already have one ready. Gotcha: be sure to choose the same Azure region as your VM.
- Resource Group: Top-level organizational container in Azure.
- Backup policy: Determines backup retention settings.
"Enabling the VM for backup" specifically means that Azure will automatically install the VMSnapshot agent on the target VM.
To take a manual VM backup, click Backup Now from the Backup Settings blade.
You can follow the backup progress through the Jobs blade in your chosen Recovery Services vault.
Note: You probably wonder how much Azure VM Backup costs. See the appropriate pricing page at Azure.com, but I'll summarize by saying you pay a flat monthly fee plus the storage consumed for your backups.
Restore the VM to a different vNet ^
To avoid name, security identifier, and other conflicts, be sure to stop and deallocate your VM. To keep the VM state as current as possible, you might want to shut down the VM prior to taking the most recent backup.
Next, head on back to the Backup settings blade for your VM. This time, click Restore VM. In the Select restore point blade, choose the most recent application-consistent backup and click OK to proceed to the Restore configuration blade. I show you this journey in figure 4.
NOTE: Per the Azure documentation, an application-consistent backup uses the Volume Shadow Copy service (VSS) to back up applications and files while the VM is running.
The key here is ensuring that you place the restored VM on the appropriate vNet and subnet. You'll get an error if you try to put the VM into the same resource group as the source VM if you haven't changed the name (don't do this anyway).
Another protip: make sure you have the target resource group defined by the time you restore the VM. As of this writing in fall 2017, the Azure portal only allows you to select from a list of existing resource groups. Of course, you could do all of this work programmatically with Azure PowerShell or Azure CLI v2.0, in which you have full control over the entire process!
Cleaning up ^
The next diagram shows our Azure environment after the migration (and after I removed the original dc1 instance):
There is bound to be a bit of "fiddling" you'll need to do to restore service to the given VM completely. For example, in the screenshot below I show you that Azure created a new vNIC for our restored VM. By extension (pun intended), this may mean we need to reassign an NSG and/or a public IP address reservation.
Subscribe to 4sysops newsletter!
All in all, the VM Backup/Recovery Services approach to relocating a VM to a different vNet is a time-intensive task more than anything else. I hope that someday Microsoft will make vNet reassignments as trivial to undertake as subnet changes.