Last updated: 25/05/2020
General tips & troubleshooting:
- Create a dedicated temporary resource group for the Azure Migrate Project resources, other than the target resource group(s) you plan to migrate the virtual machines
- The Azure Migrate/Replication appliances cannot be de-registered, to remove it you’ll have to remove its resource group
- Azure Migrate Project resources (storage account, key vault, service bus, etc.) will generate some very minimal cost (most of it will be because of the dependency on the Azure Service Bus service)
- Assessment and dependency analysis can increase the cost due to the Log Analytics workspace requirement
- This dedicated temporary resource group can be removed after the migration completed
- A storage account will be automatically created to store boot diagnostics for the migrated VMs.
- Make sure to reconfigure boot diagnostics – if need – to a dedicated storage group after the migration completed
- The Azure Migrate virtual appliance is used for assessment and agentless VMware migration
- Agentless migration requires access to VCenter (over port 443) and direct access to the VMware ESX/ESXi hypervisor (over port 902) from the Azure Migrate virtual appliance
- Agentless dependency analysis feature will also require:
- direct access to the VMware ESX/ESXi hypervisor (over port 443) from the Azure Migrate virtual appliance
- VMware Virtual Machine Guest Operations role assigned to the account you’ll use to connect to vCenter
- If direct access to the hypervisors is not allowed, move to agent-based migration
- The Azure Migrate Replication virtual appliance used for agent-based migration of VMware VMs
- Works with standalone VMware hypervisors and without VCenter
- Can perform lift & shift migration to Azure
- Cannot perform assessment of discovered virtual machines
- For virtual machine assessment deploy an Azure Migrate virtual appliance as well
- Network throttling
- Consider limiting the outgoing Internet traffic from the appliance to prevent congestion on your Internet connection while replication multiple virtual machines
- Consider switch/network side throttling ingress traffic to the Azure Migrate appliance/Replication appliance as:
- With agentless migration the appliance pulls the data from the hypervisor
- With aged-based migration the source VM runs the Mobility Service that sends (push) local data to the replication appliance’s port 9443
- Test migrations:
- Test migration helps validating that the VM and the installed applications/services can be started in Azure, all disk/data is migrated – and are assigned the appropriate drive letters or mount points
- Prepare a temporary “blind” or restricted Virtual Network to use for test migrations, and prevent access to Domain Controllers, production servers, databases, etc.
- DO NOT run test migration to a production Virtual Network
- During test migration a new VM will be created in the target virtual network with “_test” attached to the source name
- Both the source (original) and the “replica” will be running, that can cause unexpected consequences
- Make sure time, time zone and date is correct on the appliance
- Reboot the VMs before completing the migration, to clear pending reboots or update installation
- Validate local administrator accounts and their passwords before completing the migration, these can come handy with test migrations to restricted networks
- Should the replication stuck at “Waiting for first recovery point” for an extended period then reboot the source VM
- To force syncing changes made to the on-premise (source) environment ( e.g. new VM created in VCenter, new VM credentials added, etc.) navigate to Azure Migrate | Servers > Overview > Infrastructure servers, select your appliance and click on Refresh Server
Agentless migration:
- During the initial setup the VMWare vSphere Virtual Disk Development Kit (VDDK) toolkit have to be download separately and extracted to a local folder on the appliance as the wizard will guide you
-
Only UPN is accepted in “VM credentials for discovery of applications and dependencies”
- Make sure the target Active Directory Domain’s both DNS and NetBIOS names can be resolved from the appliance, otherwise the credentials will not work
- Consider to install the Microsoft’s Azure Virtual Machine Agent before initiating replication or migrating a VM as it is not installed automatically.
- The manually installed Azure Virtual Machine Agent might be older than that comes preinstalled in newly deployed marketplace images – even if you downloaded the most recent version – you can leave it to Azure to update it in their next cycle in the background, see https://docs.microsoft.com/en-gb/azure/virtual-machines/extensions/agent-windows
Agent-based migration:
- Enter a name you use for registering the appliance with Azure Migrate Server will be set the as the hostname of the appliance as well
- For virtual machine credentials use Domain\User format, UPN is not accepted.
- Make sure the target Active Directory Domain’s both DNS and NetBIOS names can be resolved from the appliance, otherwise the credentials will not work
- On Windows together with the Mobility Service also the Virtual Machine Agent will be installed
- Validate this by looking up either by:
- Open Task Manager, click the Details tab, and look for a process name WindowsAzureGuestAgent.exe. The presence of this process indicates that the VM agent is installed.
- Or in the C:\WindowsAzure\Packages\GuestAgent folder
- To Install it manually, see: https://docs.microsoft.com/en-gb/azure/virtual-machines/extensions/agent-windows
- Validate this by looking up either by:
- On Linux install the Azure Guest Agent manually, see https://docs.microsoft.com/en-gb/azure/virtual-machines/extensions/agent-linux
- If the /var/log/waagent.log exists, the Virtual Machine Agent was installed
- Expect some errors show up in this log, as communication channel to Azure platform resources at 168.63.129.16 is not available outside from Azure
- If the /var/log/waagent.log exists, the Virtual Machine Agent was installed
- Stop all applications and services (e.g. SQL server) before finalizing the migration to prevent any data loss
- Data loss might occur if any changes occur after Mobility Service stops
Post-migration:
- Stop the replication
- Consider to remove the source virtual machine disk(s) later
- Check if Azure VM guest agent is installed and running
- Configure the migrated VMs’ boot diagnostics to a dedicated storage account
- (If licensed) Azure Security agent will be installed via Azure Security Center automatically after a while
- Move the paging file to the temp disk
- The temp disk might be assigned to a different letter other than D:
- SQL server: Consider moving the TempDB to the temporary storage drive:
- Uninstall VMware tools and remove the VMware network interface (vmxnet3)
- Agent-based migration:
- Uninstall Mobility Service (aka. Microsoft azure site recovery mobility service/master target server)
- Windows: In the Control Panel of the machine, select Programs. Select Microsoft Azure Site Recovery Mobility Service/Master Target server > Uninstall
- Linux: Sign in as a root user, run: /usr/local/ASR/uninstall.sh -Y
- Uninstall Mobility Service (aka. Microsoft azure site recovery mobility service/master target server)
- Consider to configure Azure native backup/replication, updates and monitoring
- Deploying updates from on-prem SCCM/WSUS server or backing up Azure VM to on-premise may be sub-optimal
Me tech notes 