Moving Azure Virtual Machines to a New VNET
In the prior blog post, I moved my Azure virtual machines from the Azure Service Manager (ASM) to Azure Resource Manager (ARM) model. In this blog post, I walkthrough how to change the IP address of the Azure Virtual Machine from one VNET to another VNET. What does this mean?
This scenario would come up if you needed to change the IP addresses of your Azure virtual machines to a different network. For example, suppose you needed to change the IP addresses of your Azure virtual machines from 10.0.1.0/24 (in VNET1) to a new range (10.0.2.x/24 in VNET2.
It turns out that if you need to move the virtual machine to another network, that you will need to delete and recreate the virtual machine in the new VNET. During this process, you only delete the virtual machine configuration and then recreate it and re-attach the VM virtual disk (VHD).
Changing Availability Sets Also Require Virtual Machine Recreation
We also discovered that in order to put the virtual machine into the correct availability set that this can only be done at creation. After our ASM to ARM migration, some of our VM’s were not in the correct availability set, so I wanted to correct this issue as well.
The Process..
Luckily, I found a blog post that documents this process. It can be found at:
https://blogs.technet.microsoft.com/espoon/2016/03/11/moving-an-arm-vm-to-a-new-vnet/
In this blog post, I’ll document the lessons learned as I went through this process.
Step 1: Document the current VM
- I documented the current configuration of my Azure virtual machines. Two key things that I needed to record were: the VM size and the storage location of the Azure VM.
- To get the VM size, go to the Overview page and it should be listed.
- To get the storage location, go to Disks on the VM properties. Then on the right, go to OS Disk and select the disk under the label.
- Then copy the storage location of the actual VHD file for the virtual machine. This is key. Since during the process, we are deleting the VM construct. However, we are not touching the VM VHD file. We will be re-building the VM and re-attaching to the existing VHD file in the new VNET.
Things to Do Before the Migration:
Disable Network Level Authentication Temporarily Before Migration
Before you move the VM’s to a new network, you may want to disable NLA during the time of the migration. I encountered the following error (see below) after the migration when I tried to RDP into the migrated VM. The migrated VM couldn’t connect to the domain controller so I wasn’t able to RDP into it since RDP required Network Level Authentication (NLA). So, I had to migrate back the VM so that it could connect to the domain controller. Then, I was able to disable NLA. I brought this up early so you can make this change before the migration. If you don’t do this, you maybe able to fix it after the migration, if you move the domain controller to the new VNET and also set the DNS on the VNET to point to the domain controller so that the VM can connect to the domain controller. However, I would recommend disabling it before the migration.
To disable NLA, RDP into the VM, go to the Properties and Remote settings of the server. Select Remote Settings and un-check the “Allow connections only from computers running Remote Desktop with NLA”.
Create Availability Sets Before Migration
Since you need to set the availability set during the VM creation, you need to create the availability sets that you need before you move the VM’s to the new VNET location.
Create the destination Virtual Network (VNET) and Subnet Before Migration
Design the new IP address strategy. Create the destination virtual network (VNET) and subnet before migrating the VMs. Identify the IP addresses for the migrated VM’s.
Use PowerShell for the Migration
I used PowerShell commands to move the VM’s to a new VNET. I would recommend using Power Shell and using Powershell ISE since it allows you to develop a PowerShell script for the move and allows you to re-use the script to each VM’s with minor tweaks. Remember to start Powershell ISE with “Run as Administrator” (Right-click on the Powershell ISE and select “Run as Administrator”).
Moving the VM to a New Subnet
I would recommend testing this procedure first on a trial/test VM.
- After recording the information, I deleted my virtual machine.
- Then I ran the following script to recreate the virtual machine and re-attach to the VHD.
# Installs Azure RM modules. Login to Azure.
# Select the Azure subscription that has the VM’s that you want to work on.
Install-Module azurerm
Login-AzureRmAccount
Get-AzureRmSubscription | sort SubscriptionName | select SubscriptionName
Select-AzureRmSubscription -SubscriptionName “<Substitute the subscription that has your VMs”
# define variables for your environment
$networkname = “<Enter your destination VNET>”
$subnetname = “<Enter your destination subnet>”
$rg = “<Enter the resource group that holds VMs”
$PIPName = “<Enter the public IP address name, eg. Servername-pip>”
$nic1name = “<Enter the NIC name, eg. Servername-nic>”
$vmname = “<Enter the servername>”
$storageaccount = “<Enter the storage account for your VMs>”
$PIPDNSName = “<Enter the public IP DNS name, eg. Servername>”
$VMSize = “<Enter the VM size, eg. Standard_A3>”
$StorageRg = “<Enter the resource group that holds the storage account>”
$Location= “<Enter the location where you want the resources, eg. Westus>”
$vhdname = “<Enter your servername, eg. ec360dc2>”
$network=Get-AzureRmVirtualNetwork -Name $NetworkName -ResourceGroupName $networkname
$subnet=Get-AzureRmVirtualNetworkSubnetConfig -Name $SubnetName -VirtualNetwork $network
$Stor=Get-AzureRmStorageAccount -ResourceGroupName “<Enter the resource group that has your storage” -Name $storageaccount
$pip=New-AzureRmPublicIpAddress -Name $PIPName -ResourceGroupName $Rg -Location $Location -DomainNameLabel $PIPDNSName -AllocationMethod Dynamic
# I wanted to set a static private address in the subnet (e.g. 10.0.2.30 so I specified it on this command.
$nic1=New-AzureRmNetworkInterface -Name $Nic1Name -ResourceGroupName $Rg -Location $Location -SubnetId $subnet.Id -EnableIPForwarding -PublicIpAddressId $pip.Id -PrivateIpAddress 10.0.2.30
$as = Get-AzureRmAvailabilitySet -ResourceGroupName $rg -Name “<Enter the availability set that you want to put the VM into>”
$VM=New-AzureRmVMConfig -VMName $VMName -VMSize $VMSize -AvailabilitySetId $as.id
$VM=Add-AzureRmVMNetworkInterface -Id $nic1.id -VM $VM -Primary
# This is a key variable. Need to paste in the path to the VHD storage location noted earlier
$OSDiskUri = “<Paste in the VHD storage path recorded earlier, e.g. https://###.blob.core.windows.net/vhds/ … .vhd>”
$VM=Set-AzureRmVMOSDisk -Name $VHDName -VhdUri $OSDiskUri -Caching ReadWrite -CreateOption attach -Windows -VM $VM
# Creates the VM
New-AzureRmVM -ResourceGroupName $RG -Location $location -VM $VM
After the VNET Migration
- Confirm that each of the VM’s started.
- Configure the Network Security Groups (NSG) to allow RDP if it doesn’t work. Need to enable inbound access to port 3389
- If you want internet access, add the rules to the NSG for Internet and DNS.
- Confirm that you can RDP into each of the VM’s.
- Re-apply the Network Level Authentication (NLA) as you check each VM.
