Table of Content

Migrate VM to Azure using Azure Site Recovery

On-premises VMs replicated to Azure must meet the Azure VM requirements summarized in this table. When Site Recovery runs a prerequisites check for replication, the check will fail if some of the requirements aren't met.

See VM requirements for migration using Azure Site Recovery.

NOTE: Microsoft recommend that you migrate machines to Azure using the Azure Migrate service. Azure Site Recovery is purpose built for Backup & Disaster Recovery. See Azure Migrate below.. ⭐

Migrate VM to Azure using Azure Migrate

Azure Migrate is purpose-built for server migration. Azure Migrate provides a centralized hub for discovery, assessment and migration of on-premises machines to Azure.

See migration options

• Agent-less
• Agent-based

See VM requirements for migration using Azure Migrate.

• BitLocker: Not supported
• Data disk count: <=64
• Data disk Size: <=32TB
• OS disk Size: <=2TB OS disk for gen1 VM; <=4TB OS disk for gen2 VM
• Disk Limit: <=63 disk p/vm
• Disk Encryption: Not supported
• Shared disk cluster: Not supported
• NFS mount: Won't be replicated

Migrate 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)

🅰️ - 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. The Subnet drop-down list box makes it easy to move between subnets within a single Vnet.

Reference: R1

Migrate VM between VNets

Suppose you had VNet1 is in RG1. VNet2 is in RG2.

An administrator named Admin1 creates an Azure virtual machine named VM1 in RG1. VM1 uses a disk named Disk1 and connects to VNet1. Admin1 then installs a custom application in VM1. You need to move the custom application to VNet2. The solution must minimize administrative effort.

❓ - Which two actions should you perform?

1. Delete VM1
2. Create new VM in VNet2

🅰️ - You cannot move VMs between VNets. What we need to do is identify the disk used by the VM, delete the VM itself while retaining the disk, and recreate the VM in the target virtual network and then attach the original disk to it.

Reference: R1, R2

Azure Instance Metadata Service (IMDS)

The Azure Instance Metadata Service (IMDS) provides information about currently running virtual machine instances. You can use it to manage and configure your virtual machines. This information includes the SKU, storage, network configurations, and upcoming maintenance events.

IMDS is available for running instances of virtual machines (VMs) and virtual machine scale set instances. All endpoints support VMs created and managed by using Azure Resource Manager. Only the Attested category and Network portion of the Instance category support VMs created by using the classic deployment model. The Attested endpoint does so only to a limited extent.

IMDS is a REST API that's available at a well-known, non-routable IP address (169.254.169.254). You can only access it from within the VM. Communication between the VM and IMDS never leaves the host. Have your HTTP clients bypass web proxies within the VM when querying IMDS, and treat 169.254.169.254 the same as 168.63.129.16.

For more info see: Link