Loading...

Linux VMs do not boot or are unreachable after conversion or replication to Azure

Azure VMs require Hyper-V drivers for the Hyper-V network and storage devices.

Symptom

After you convert Linux VMs to Azure or replicate Linux virtual machines from VMware to Azure, the virtual machines are not bootable or are not network accessible.

Cause

Depending on the version of Linux running on the guest VMs, the following factors might cause problems with the destination VM in Azure:

  • (CentOS/RHEL 7.x) Missing required drivers prevents the target VMs from starting.
  • (CentOS/RHEL 7.x) Incorrect Classless Inter-Domain Routing (CIDR) subnet range configuration makes VMs unreachable.
  • (CentOS/RHEL 5.x) Boot device that is configured for device or label-based mount prevents the target VMs from starting.
  • (SUSE) Linux VMs do not start or are unreachable after replication to Azure.

For more information, see the following Microsoft articles:

Resolutions

CentOS/RHEL 7.x VMs do not start after replication to Azure

The following drivers are required on the source VM:

  • hv_netvsc.ko
  • hv_storvsc.ko
  • hv_vmbus.ko

On the source VM, recut the initramfs with required kernel drivers for Hyper-V hardware on the source machine. This operation does not cause any disruption to the source machine.

  1. Check whether required Hyper-V kernel modules are present:

    lsmod | grep -i hv

  2. Identify the current kernel version:

    uname -r

  3. Create a backup of the current initramfs:

    cp /boot/<Current_Version>.img /boot/<Current_Version>.img.backup

  4. Edit the dracut.conf file:

    vi /etc/dracut.conf

  5. Uncomment the line that contains add-drivers, and then add the following drivers to the line, with spaces separating each module:

    hv_netvsc hv_storvsc hv_vmbus

  6. Go to the boot folder:

    cd /boot

  7. Recut the initramfs:

    dracut -f -v

  8. Verify that the size has changed:

    ls -l

  9. Perform a new full backup of the source VM and repeat the replication operation.
  10. Verify that the destination VMs start.

Target VMs start, but are not reachable

  1. Ensure that the network mask for the destination subnet matches the network mask for the source subnet.

    For example, if the source subnet has a /22 CIDR range and the destination subnet in Azure has a /24 subnet range, packets are not routed correctly to the outside because the mapping for the default gateway is incorrect.

  2. If necessary, reconfigure the CIDR range for the subnets in Azure.
  3. Perform a new full backup of the source VM and repeat the replication operation.
  4. Verify that destination VMs are reachable.

CentOS/RHEL 5.x VMs do not start after replication to Azure

CentOS/RHEL 5.x uses a label-based mount, but Azure requires a UUID-based mount for the boot device.

  1. On the source VMM, modify the /etc/fstab file to change the mounting of the boot volume to be UUID-based.

    The following example shows a label-based mount configuration:

    [root]# cat /etc/fstab.orig
    /dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
    LABEL=/boot             /boot                   ext3    defaults        1 2
    tmpfs                   /dev/shm                tmpfs   defaults        0 0

    The following example shows a UUID-based mount configuration:

    [root]# cat /etc/fstab
    /dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
    UUID=<UUID_value>             /boot                   ext3    defaults        1 2
    tmpfs                   /dev/shm                tmpfs   defaults        0 0

    where <UUID_value> represents the UUID for the destination VM.

  2. Perform a new full backup of the source VM and repeat the replication operation.
  3. Verify that the destination VMs start.

SUSE Linux VMs do not start or are unreachable after replication to Azure

Note: Depending on the SUSE OS version, the commands might vary.

The following drivers are required on the source VM:

  • hv_netvsc.ko
  • hv_storvsc.ko
  • hv_vmbus.ko

On the source VM, recut the initrd image with required kernel drivers for Hyper-V hardware on the source machine. This operation does not cause any disruption to the source machine.

  1. Identify the current kernel version:

    uname -r

  2. Check whether required drivers are already a part of the initrd image for the guest VM:

    lsinitrd | grep -i hv  

  3. Go to the boot folder:

    cd /boot

  4. Take a backup of the initrd image:

    cp initrd-$(uname -r) initrd-$(uname -r).backup

  5. Insert the drivers and recut the initrd image:

    mkinitrd -v -m "hv_vmbus hv_netvsc hv_storvsc" -f /boot/initrd-$(uname -r) $(uname -r)

  6. Check whether Hyper-V kernel modules got installed succesfully:

    lsinitrd | grep -i hv

  7. Verify that the size has changed:

    ls -l

  8. Perform a new full backup of the source VM and repeat the replication operation.
  9. Verify that the destination VMs start.

Last modified: 6/21/2021 7:40:26 PM