A central hub of Azure cloud migration services and tools to discover, assess, and migrate workloads to the cloud.
For physical, AWS, and GCP migrations that use the physical-server workflow, replication requires the Mobility service to be installed on the source machine.
For GCP VMs, the push installation method built into Azure Site Recovery is not currently supported. The Mobility service must be preinstalled on the source GCP VM before replication is started.
For AWS EC2, the accepted guidance in Microsoft Q&A is that manual installation can fail because the generic Mobility Service agent is the wrong agent for EC2 scenarios. The recommended approach is to use the Azure Migrate workflow to discover the AWS VM and let Azure Migrate handle the Mobility Service installation during replication.
Since discovery succeeded but replication fails at Mobility agent installation, check these items:
- Confirm the migration path
- For physical servers and the physical-server-style workflow, install the Mobility service on the source machine before replication.
- For GCP VMs, preinstall and register the Mobility service agent with the replication appliance before starting replication.
- For AWS EC2, use the Azure Migrate workflow for EC2 rather than manually installing a generic agent.
- Verify the source machine is registered correctly
- Make sure the Mobility Agent is installed on the source VM and is registered to the Configuration Server / replication appliance.
- Check connectivity between source machine and replication appliance
- Ensure firewall and network rules allow a path between the replication appliance and the source machines.
- For replication progress issues, ensure the replication appliance has TCP 9443 and HTTPS 443 enabled for data transport.
- For Linux source discovery/connectivity issues, ensure port 22 is enabled.
- Check appliance health
- Verify the replication appliance meets requirements.
- Ensure there are no stale duplicate versions of the replication appliance connected to the same project.
- If appliance registration is affected, verify proxy settings are not blocking registration.
- For Linux installation/authentication issues
- If discovery or BIOS GUID collection fails, use root login rather than a pseudo user.
- For GCP, if root cannot be used, ensure the required capabilities are set on the user as described in the support matrix referenced by the product documentation.
- For GCP manual install path
- Extract the installer tarball to a local folder.
- Run the installer:
sudo ./install -r MS -v VmWare -q -c CSLegacy - Register the agent with the replication appliance:
/usr/local/ASR/Vx/bin/UnifiedAgentConfigurator.sh -i <replication appliance IP address> -P <Passphrase File Path>
If the failing machines are AWS EC2 Ubuntu 22/24, changing the kernel alone is not the key fix based on the available guidance. The supported path is to use Azure Migrate’s EC2 migration workflow and avoid manually installing the generic Mobility agent.
References:
- Discover, assess, and migrate Amazon Web Services (AWS) EC2 instances to Azure
- Discover, assess, and migrate Google Cloud Platform (GCP) VMs to Azure
- Migrate machines as physical servers to Azure
- Problem with installing the mobility Service on an EC2 Linux MAchines - Microsoft Q&A
- Unable to discove /connect to my physical linux Server on ASR Replication - Microsoft Q&A