So there you are. You have created a new virtual machine late at night and didn't pay close attention when hitting enter on that
New-AzVM command. Unfortunately it got placed in the wrong virtual network/subnet.
"Okay, let's just create another NIC attached to the desired vnet and then associate it with the VM!" - you think. Unfortunately things are not that easy as you might have guessed...
There are a two possible scenarios.
You want to move the VM to a subnet that is in the same virtual network as the original one.
You want to move the VM to a subnet that is in a different virtual network as the original one. And the target vnet is in the same region as the VM.
This scenarios are getting constrained by the following facts, so let's keep them in mind while working through this article.
A NIC must be in the same region as the vnet/subnet it is going to be attached to.
A public IP that is going to be used by a VM must be in the same region as the VM itself.
A managed disk that is going to be used by a VM must be in the same region as the VM itself.
All NICs attached to a VM must also be attached to the same virtual network. They can't span multiple virtual networks, but they can span multiple subnets.
A NSG must be in the same region as the NIC/subnet is going to be associated with.
Let's see what options we have.
1. Move to another subnet in the same virtual network
This can easily be done from within the
Network interface blade. Just navigate to
IP configurations and from the dropdown box named
Subnet choose a different one.
With Azure PowerShell this can be done as follows.
# Get network interface $nic = Get-AzNetworkInterface -Name "vm-nic-foo" # Get virtual network $vnet = Get-AzVirtualNetwork -Name "vnet-bar" # Get a subnet from vnet $subnet = Get-AzVirtualNetworkSubnetConfig -Name "snet-bar-1 -VirtualNetwork $vnet # Change subnet of network interface $nic.IpConfigurations.Subnet.Id = $subnet.Id # Finally write back to Azure $nic | Set-AzNetworkInterface
That was easy! But things get more complicated if we want to move to anoter virtual network...
2. Move to another virtual network in the same region
First some disappointing words. Microsoft does not directly support migrations of virtual machines into other vnets.
This implies that we have to redeploy the VM in some or the other way and therefor will face a downtime!
There are two ways we can achieve this. Either be leveraging a recovery service fault or by manually recreating the VM from the OS disk.
2.1 Use a recovery service fault
This way requires a general purpose v2 storage account and recovery service fault in the same region as the VM we'd like to move.
Sounds overkill? Yes, kind of, I agree 😐. But this option is beneficial as it restores all items associated with the VM.
So go ahead and create this resources (if not already existent) and create a backup/restore point of your VM. After completion goto "Backup items > Azure Virtual Machine > Choose your VM" and hit "Restore VM".
Now we don't want to replace the existing VM as it won't give us the option to change the network configuration. Instead we are going to choose "Create new".
If you like you can delete the original VM (including its associated objects) beforehand, so you can reuse the original VMs name.
2.2 Recreate VM from OS disk
First we will have to delete the original VM object and leave any other objects related to that VM in place (NSG, NIC, DISKs).
Then we are going to open the managed disk and click "Create VM". We can reuse the original VM name. Within the disk section we have to make sure to add any additional data disks if applicable.
Then from within the network section we finally can select the target network and subnet. Here we also can reuse and existing public ip and nsg object if applicable.
As mentioned in the beginning you can't attach the VM/NIC to a virtual network which is in another region. Therefor we would have to move at least the disk to the target region.
Okay that's it for today. In case there is already a recovery service fault and storage account in place I always would choose that route for the move. Otherwise there is only the poor mans choice left, which involves manually recreating the VM.