Troubleshooting for Converting to Azure Resource Manager

Linux VMs Do Not Boot or Are Unreachable After Conversion or Replication to Azure

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.

Causes

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

(UNIX VM conversions) Kernel on VM has not been upgraded.
(RHEL 7.x) Missing required drivers.
(RHEL 7.x) Incorrect Classless Inter-Domain Routing (CIDR) subnet range configuration makes VMs unreachable.
(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 Microsoft article Prepare a Red Hat-based virtual machine for Azure.

Resolutions

UNIX VM conversions: Upgrade kernel on VM

Upgrade the kernel on the VM as follows:

Check "uname -r" output, and note the kernel version number being used for current boot.
Check "ls /boot/initram*" and determine if any latest kernel (that is, initramfs image) is present with a higher kernel version number than what is currently used (see Step 1, above). If so, reboot to update kernel.
Check "uname -r" ouptut and confirm it is using the latest kernel version number.
Install Hyper-V drivers.
Recut the initramfs.
Perform a full backup on the VM.
Restore VM to Azure.

RHEL 7.x: Install required drivers

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.

Check whether required Hyper-V kernel modules are present:
```
lsmod | grep -i hv
```
Identify the current kernel version:
```
uname -r
```

Create a backup of the current initramfs:

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

Edit the dracut.conf file:
```
vi /etc/dracut.conf
```
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
```
Go to the boot folder:
```
cd /boot
```
Recut the initramfs:
```
dracut -f -v
```
Verify that the size has changed:
```
ls -l
```
Perform a new full backup of the source VM and repeat the replication operation.
Verify that the destination VMs start.

RHEL 7.x: Ensure the network mask for destination subnet matches network mask for source subnet, and reconfigure CIDR range for subnets

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.
If necessary, reconfigure the CIDR range for the subnets in Azure.
Perform a new full backup of the source VM and repeat the replication operation.
Verify that destination VMs are reachable.

RHEL 5.x: Change mounting of boot volume to be UUID-based

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

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.

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

SUSE: Recut the initrd image with required kernel drivers for Hyper-V hardware on source machine

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.

Identify the current kernel version:
```
uname -r
```
Check whether required drivers are already a part of the initrd image for the guest VM:
```
lsinitrd | grep -i hv
```
Go to the boot folder:
```
cd /boot
```

Take a backup of the initrd image:

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

Insert the drivers and recut the initrd image:

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

Check whether Hyper-V kernel modules got installed succesfully:
```
lsinitrd | grep -i hv
```
Verify that the size has changed:
```
ls -l
```
Perform a new full backup of the source VM and repeat the replication operation.
Verify that the destination VMs start.