Support for moving Azure VMs between Azure regions
Article
This article summarizes support and prerequisites when you move virtual machines and related network resources across Azure regions using Resource Mover.
Windows VM support
Resource Mover supports Azure VMs running these Windows operating systems.
Operating system
Details
Windows Server 2019
Supported for Server Core, Server with Desktop Experience.
Windows Server 2016
Supported Server Core, Server with Desktop Experience.
Windows Server 2012 R2
Supported.
Windows Server 2012
Supported.
Windows Server 2008 R2 with SP1/SP2
Supported.
For machines running Windows Server 2008 R2 with SP1/SP2, you need to install a Windows servicing stack update (SSU) and SHA-2 update. SHA-1 isn't supported from September 2019, and if SHA-2 code signing isn't enabled the agent extension won't install/upgrade as expected. Learn more about SHA-2 upgrade and requirements.
Ubuntu servers using password-based authentication and sign-in, and the cloud-init package to configure cloud VMs, might have password-based sign-in disabled on failover (depending on the cloud-init configuration). Password-based sign-in can be reenabled on the virtual machine by resetting the password from the Support > Troubleshooting > Settings menu (of the failed over VM in the Azure portal.
Running the Red Hat compatible kernel or Unbreakable Enterprise Kernel Release 3, 4 & 5 (UEK3, UEK4, UEK5)
Supported Ubuntu kernel versions
Release
Kernel version
14.04 LTS
3.13.0-24-generic to 3.13.0-170-generic, 3.16.0-25-generic to 3.16.0-77-generic, 3.19.0-18-generic to 3.19.0-80-generic, 4.2.0-18-generic to 4.2.0-42-generic, 4.4.0-21-generic to 4.4.0-148-generic, 4.15.0-1023-azure to 4.15.0-1045-azure
16.04 LTS
4.4.0-21-generic to 4.4.0-171-generic, 4.8.0-34-generic to 4.8.0-58-generic, 4.10.0-14-generic to 4.10.0-42-generic, 4.11.0-13-generic to 4.11.0-14-generic, 4.13.0-16-generic to 4.13.0-45-generic, 4.15.0-13-generic to 4.15.0-74-generic 4.11.0-1009-azure to 4.11.0-1016-azure, 4.13.0-1005-azure to 4.13.0-1018-azure 4.15.0-1012-azure to 4.15.0-1066-azure
18.04 LTS
4.15.0-20-generic to 4.15.0-74-generic 4.18.0-13-generic to 4.18.0-25-generic 5.0.0-15-generic to 5.0.0-37-generic 5.3.0-19-generic to 5.3.0-24-generic 4.15.0-1009-azure to 4.15.0-1037-azure 4.18.0-1006-azure to 4.18.0-1025-azure 5.0.0-1012-azure to 5.0.0-1028-azure 5.3.0-1007-azure to 5.3.0-1009-azure
Supported Debian kernel versions
Release
Kernel version
Debian 7
3.2.0-4-amd64 to 3.2.0-6-amd64, 3.16.0-0.bpo.4-amd64
Debian 8
3.16.0-4-amd64 to 3.16.0-10-amd64, 4.9.0-0.bpo.4-amd64 to 4.9.0-0.bpo.11-amd64
Debian 8
3.16.0-4-amd64 to 3.16.0-10-amd64, 4.9.0-0.bpo.4-amd64 to 4.9.0-0.bpo.9-amd64
Supported SUSE Linux Enterprise Server 12 kernel versions
Release
Kernel version
SUSE Linux Enterprise Server 12 (SP1, SP2, SP3, SP4)
Supported if the VM runs on a supported operating system.
Azure Gallery images (published by third party)
Supported
Supported if the VM runs on a supported operating system.
Custom images (published by third party)
Supported
Supported if the VM runs on a supported operating system.
VMs using Site Recovery
Not supported
Move resources across regions for VMs, using Site Recovery on the backend. If you're already using Site Recovery, disable replication, and then start the Prepare process.
Azure RBAC policies
Not supported
Azure role-based access control (Azure RBAC) policies on VMs aren't copied over to the VM in target region.
Extensions
Not supported
Extensions aren't copied over to the VM in target region. Install them manually after the move is complete.
Supported VM storage settings
This table summarized support for the Azure VM OS disk, data disk, and temporary disk. It's important to observe the VM disk limits and targets for managed disks to avoid any performance issues.
Note
The target VM size should be equal to or larger than the source VM. The parameters used for validation are: Data Disks Count, NICs count, Available CPUs, Memory in GB. If it sn't a error is issued.
The following table summarizes limits that based on our tests. These don't cover all possible application I/O combinations. Actual results vary based on your application I/O mix. There are two limits to consider, per disk data churn, and per VM data churn.
Storage target
Average source disk I/O
Average source disk data churn
Total source disk data churn per day
Standard storage
8 KB
2 MB/s
168 GB per disk
Premium P10 or P15 disk
8 KB
2 MB/s
168 GB per disk
Premium P10 or P15 disk
16 KB
4 MB/s
336 GB per disk
Premium P10 or P15 disk
32 KB or greater
8 MB/s
672 GB per disk
Premium P20 or P30 or P40 or P50 disk
8 KB
5 MB/s
421 GB per disk
Premium P20 or P30 or P40 or P50 disk
16 KB or greater
20 MB/s
1684 GB per disk
Supported VM networking settings
Setting
Support
Details
NIC
Supported
Specify an existing resource in the target region, or create a new resource during the Prepare process.
Internal load balancer
Supported
Specify an existing resource in the target region, or create a new resource during the Prepare process.
Public load balancer
Supported
Specify an existing resource in the target region, or create a new resource during the Prepare process.
Public IP address
Supported
Specify an existing resource in the target region, or create a new resource during the Prepare process.
The public IP address is region-specific, and won't be retained in the target region after the move. Keep this in mind when you modify networking settings (including load balancing rules) in the target location.
Network security group
Supported
Specify an existing resource in the target region, or create a new resource during the Prepare process.
Reserved (static) IP address
Supported
You can't currently configure this. The value defaults to the source value.
If the NIC on the source VM has a static IP address, and the target subnet has the same IP address available, it's assigned to the target VM.
If the target subnet doesn't have the same IP address available, the initiate move for the VM will fail.
Dynamic IP address
Supported
You can't currently configure this. The value defaults to the source value.
If the NIC on the source has dynamic IP addressing, the NIC on the target VM is also dynamic by default.
IP configurations
Supported
You can't currently configure this. The value defaults to the source value.
VNET Peering
Not Retained
The VNET which is moved to the target region will not retain its VNET peering configuration present in the source region. To retain the peering, it needs to do be done again manually in the target region.
Outbound access requirements
Azure VMs that you want to move need outbound access.
URL access
If you're using a URL-based firewall proxy to control outbound connectivity, allow access to these URLs:
Name
Azure public cloud
Details
Storage
*.blob.core.windows.net
Allows data to be written from the VM to the cache storage account in the source region.
Microsoft Entra ID
login.microsoftonline.com
Provides authorization and authentication to Site Recovery service URLs.
Replication
*.hypervrecoverymanager.windowsazure.com
Allows the VM to communicate with the Site Recovery service.
Service Bus
*.servicebus.windows.net
Allows the VM to write Site Recovery monitoring and diagnostics data.
NSG rules
If you're using a network security group (NSG) rules to control outbound connectivity, create these service tag rules. Each rule should allow outbound access on HTTPS (443).
Create a Storage tag rule for the source region.
Create an AzureSiteRecovery tag rule, to allow access to the Site Recovery service in any region. This tag has dependencies on these other tags, so you need to create rules for them to:
AzureActiveDirectory
*EventHub
AzureKeyVault
GuestAndHybridManagement
We recommend you test rules in a non-production environment. Review some examples.