ASR Replication appliance can't add Linux VMs

Question

ASR Replication appliance can't add Linux VMs

Jan Claes 85

We have an on-premises environment, which is no VMware or Hyper-V, so we need to use agent-based migration.

All the VMs (Windows and Linux) are successfully added to the Azure Migrate appliance:

User's image

But when trying to add them to the ASR appliance, we get the following error, using the same credentials. Both appliances are on the same address space, not FW is blocking the connection.

User's image

Arno Vanhoutte 0 Reputation points

2026-04-23T07:34:32.54+00:00
Hey,

I am following this topic up. and fixed the issue with the instructions provided.

Now we have the following error:

What have i already done:

Downgrade the kernel version of the machine to match the OS/Kernel version: https://learn.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-support-matrix#ubuntu-kernel-versions

check connectivity outboud to MS -> OK.

Check if the package is hanging on the linux vm, this isn't the case.

i have seen some posts about manually installing the Mobility Service, but can't seem to find a way to download the specific Mobility Service version, and a "how-to" kb.

Are there any steps i am looking over to see whats wrong in this case?

2 answers

Your answer

Arno Vanhoutte 0 Reputation points

2026-04-23T07:34:32.54+00:00

Hey,

I am following this topic up. and fixed the issue with the instructions provided.

Now we have the following error:

What have i already done:

Downgrade the kernel version of the machine to match the OS/Kernel version: https://learn.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-support-matrix#ubuntu-kernel-versions

check connectivity outboud to MS -> OK.

Check if the package is hanging on the linux vm, this isn't the case.

i have seen some posts about manually installing the Mobility Service, but can't seem to find a way to download the specific Mobility Service version, and a "how-to" kb.

Are there any steps i am looking over to see whats wrong in this case?

Answer 1

Hello Jan Claes,

Thank you for reaching out to the Microsoft Q&A forum.

When investigated it looks like the ASR replication appliance is choking when it tries to pull the BIOS GUID from your Linux servers. ASR uses that GUID to uniquely identify physical (or agent-based) machines, and behind the scenes it runs something like:

sudo dmidecode -s system-uuid

If that command fails or returns nothing, you’ll see the “Failed to fetch BIOS GUID…” error.

Here’s what to check/fix on each Linux box:

dmidecode is installed ° On RHEL/CentOS: sudo yum install -y dmidecode ° On Ubuntu/Debian: sudo apt-get install -y dmidecode
1. The LinuxRoot credential can actually run dmidecode as root ° Open /etc/sudoers.d/asr-linuxroot (or use visudo) and ensure: LinuxRoot ALL=(root) NOPASSWD: /usr/sbin/dmidecode ° Verify: sudo -l (should list dmidecode with NOPASSWD) sudo dmidecode -s system-uuid (should print a GUID)
2. Python & other agent pre-reqs are in place ° Python 2.7+ installed (python --version) ° nc, uuid-dev/libuuid and parted packages installed
3. No security policies blocking DMI access ° If SELinux/AppArmor is enforcing, try a quick test by temporarily disabling it or adjusting policies to allow dmidecode to read /dev/mem or the DMI sysfs entries
4. Confirm the server really has a valid BIOS UUID ° Look at /sys/class/dmi/id/product_uuid – if that’s empty or all zeros, ASR can’t use it

Once you’ve installed dmidecode, given the LinuxRoot user passwordless sudo rights for it, and confirmed you can manually fetch the system-uuid, re-try “Add physical server” in the replication appliance. It should move past discovery and let you install the Mobility service.

If it still fails, please let us know:

• Linux distro and version • Exact output of sudo dmidecode -s system-uuid • Any errors from sudo dmidecode (stdout/stderr) • Whether these are truly bare-metal machines or nested VMs on a non-Hyper-V/VMware hypervisor

Hope this gets you unstuck!

References

Linux server migration prerequisites – Azure Site Recovery https://learn.microsoft.com/azure/site-recovery/linux-physical-server-migration-prerequisites
Deploy and configure the process server (the ASR appliance) https://learn.microsoft.com/azure/site-recovery/deploy-process-server
Troubleshoot physical server discovery errors https://learn.microsoft.com/azure/site-recovery/troubleshoot-physical-server-discovery
Install Mobility service for Linux (agent-based replication) https://learn.microsoft.com/azure/site-recovery/site-recovery-vmware-physical-configure-lifecycle#install-the-mobility-service
Azure Migrate agent-based discovery for Linux servers https://learn.microsoft.com/azure/migrate/tutorial-server-discovery

Siva shunmugam Nadessin 9,625 Reputation points Microsoft External Staff Moderator

2026-04-22T17:53:57.9033333+00:00

Hello Jan Claes,

Just checking in to see if the solution shared above help you to resolve your issue. please reach out to us If you have any further questions.

Thanks

Answer 2

For agent-based migration of non-VMware/non-Hyper-V machines, the Azure Migrate appliance and the ASR replication appliance have different roles and requirements. Discovery in the Azure Migrate appliance working for both Windows and Linux does not guarantee that the ASR replication appliance can push-install the Mobility service and add those same machines for replication.

Key points and checks:

Use the correct appliance for agent-based migration
- For agent-based migration of physical or other non-VMware/non-Hyper-V machines, the replication appliance is required. It coordinates replication and includes the process server that push-installs the Mobility service on each source machine.
- The replication appliance must not be installed on any source machine or on the Azure Migrate discovery appliance.
- If both appliances are present in the same environment, ensure they are on different servers.
Verify replication appliance deployment and prerequisites
- If VMware is not available, the replication appliance must be set up using the software installer from the Azure Migrate hub, not the OVA template.
- Ensure the replication appliance meets all required hardware and software prerequisites before attempting to add machines.
Network and port requirements between Linux VMs and replication appliance
- For agent-based migration, the Mobility service on each VM communicates with the replication appliance and process server using:
  - HTTPS 443 inbound to the replication appliance (for replication management).
  - HTTPS 9443 inbound to the process server (for replication data). This port can be modified, but whatever is configured must be open.
- Confirm:
  - Linux VMs can reach the replication appliance on these ports.
  - Any local firewall on the Linux VMs allows outbound connections to the replication appliance on 443 and 9443.
Credentials and permissions for push installation on Linux
- For Linux VMs, the push installation of the Mobility service requires root credentials on the source Linux server.
- In the Azure Migrate/ASR configuration:
  - Ensure the Linux credentials configured for the replication appliance are root (or equivalent) and valid.
  - Avoid unsupported special characters in SSO passwords (non-ASCII, &, ;, ", ', ^, \, %, <, >, £), as these can cause authentication/SSO issues.
Differences between discovery and replication
- The Azure Migrate appliance (discovery) can list machines even if:
  - Mobility service is not installed.
  - Required replication ports are blocked.
- The ASR replication appliance, however, must:
  - Reach the VM over the required ports.
  - Successfully authenticate with the provided credentials.
  - Push-install and start the Mobility service.
- An error when adding Linux VMs to the ASR appliance typically indicates a failure in one of these steps (connectivity, credentials, or OS prerequisites).
OS preparation and support
- Ensure the Linux OS versions are supported for agent-based migration and that any required changes for running in Azure (kernel/LIS, fstab, device map, network interfaces) are in place or can be applied automatically during migration.
- For agent-based VMware vSphere migration, Azure Migrate automatically updates several Linux settings (kernel LIS, fstab, udev rules, network interfaces, Azure VM agent). For physical/other environments, confirm that the same prerequisites are satisfied or that the Mobility service can apply them.
Practical next steps
- Confirm the replication appliance is correctly registered to the Azure Migrate project and Recovery Services vault.
- Verify that the replication appliance and Azure Migrate appliance are on separate machines.
- From the replication appliance, test connectivity (ping/SSH if applicable) to the Linux VMs and verify ports 443 and 9443 are reachable.
- Re-enter Linux root credentials in the replication appliance configuration, ensuring no unsupported special characters.
- Retry adding a single Linux VM to narrow down whether the issue is global (appliance/ports/credentials) or specific to certain machines.

If Windows VMs add successfully but Linux VMs fail, focus on Linux-specific items: root access, SSH/remote access configuration, and any local firewall or security controls on the Linux hosts that might block the push install or communication with the replication appliance.

References:

Share via

ASR Replication appliance can't add Linux VMs

2 answers

Your answer