CentOS 7 Azure Tips

Possible problems you will face

In my experience, moving a VMware or HyperV virtual machine to Azure can become quite the headache compared to non-RHEL based distributions. When I first started helping customers troubleshoot CentOS 7 we were running into issues with the root filesystem not mounting, NIC IP address assignment, and installing the proper HyperV drivers into the initramfs. Luckily, we were able to work through all the issues and now by following the guidance below, it is pretty easy to get an on-premises CentOS VM into Azure.


This tips and tricks page will assume that you are using Zerto to migrate an on-premises VMware VM into Azure. It is entirely possible that these same steps will apply if you are using a different tool, but I have not tested any other tool and have no intention of doing so.

If you are only looking to use Azure as a Disaster Recovery platform, and plan to continue running your VM’s in VMware or HyperV that is perfectly fine. These steps simply prepare a VM to run in Azure, if that never happens, the modification will remain harmless while running on VMware. It is MUCH easier to do this before a failover than it is after.

I also assume that if you have found this page, then you have probably seen this Microsoft article: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/create-upload-centos

That article is great if you are trying to build your own custom CentOS “golden image” that you can then create templates from in Azure. It is also a HORRIBLE guide for migrating a production VM to Azure, why?, because several of the steps will absolutely thrash a production VM. Most of the steps in this guide were taken from that page, but the steps that were harmful or unneeded were left out.

The Tips

On the production virtual machine, the one running in VMware that you are planning to failover or move to Azure, you will want to do the following steps.

Add the OpenLogic Yum repository

While this step is technically optional, it will allow you to get the OpenLogic security patches.

Use VI or nano to add the following to your /etc/yum.repos.d/CentOS-Base.repo file

name=CentOS-$releasever – openlogic packages for $basearch

Next, run the following commands to get things updated

[bash]yum clean all yum -y update[/bash]

Check for errors in the output, make sure all goes well.

Modify Grub Options

These steps will enable a serial console so if something goes wrong you can leverage the Microsoft Serial Console for troubleshooting. In my opinion, you should NOT skip this step.

User VI or nano to edit /etc/default/grub. Look for the line that starts with “GRUB_CMDLINE_LINUX”

Remove the following options

[bash]rhgb quiet crashkernel=auto[/bash]

These options told grub to use the graphical bootloader and to use verbose kernel output to the console. Microsoft says they are not used for public cloud VMs. Crashkernel consumes about 128MB of ram, it can be left according to Microsoft, but they recommend removing it to save RAM.

Now add these options

[bash]rootdelay=300 console=ttyS0 console=tty0 earlyprintk=ttyS0[/bash]

These options tell grub to wait for 300 seconds for the root volume and turns on both the local console and serial console for boot output messages.

Save and exit your text editor.

Now run this command to update Grub.

[bash]grub2-mkconfig -o /boot/grub2/grub.cfg[/bash]

Adding HyperV drivers to the initramfs

For Linux to work properly in HyperV as well as Azure you need three modules: hv_bus, hv_netvsc, and hv_storvsc.

To install these into a VM that is running on VMware we need to modify the dracut config file and then run dracut to update the initramfs.

Using VI or nano edit /etc/dracut.conf; add the following line into the file then save the file.

[bash]add_drivers+=" hv_vmbus hv_netvsc hv_storvsc nvme ena xen_blkfront xen_netfront mptbase mptscsih mptspi "[/bash]

It is very important to preserve the spaces as well as using the proper ” ” marks. If you use the Azure configuration document the double quotes that they use are interpreted improperly and will cause the drivers to not be loaded.

Now run dracut with the following command.

[bash]dracut -force -v[/bash]

Here is a HUGE initramfs side note/tip too

The dracut command above will rebuild initramfs for the currently running kernel version. HOWEVER! If you ran yum -y update above and it installed a new kernel, and you havent rebooted, dracut will build for the WRONG kernel. (It will build for the currently running kernel… not the new kernel that will be used on the next reboot)

You have two options.

1.) reboot the machine before running the dracut command

2.) tell dracut which version of the kernel to build for

If rebooting is not an option my recommendation is to use cat your grub file to see what version of the kernel are installed.

[bash]cat /boot/grub2/grub.cfg | grep initrd16[/bash]

then run

[bash]uname -a[/bash]

Your output will be something like this:

Output showing kernel versions in grub2 as well as the current running kernel

If the kernel version from the uname command (3.10.0-862.9.1.e17.x86_64 in my case) is also listed as the top line from the first command, dracut will build the initramfs for the proper kernel.

If they are not the same then you can force dracut to build for the default kernel by using this command (modify as needed for your kernel)

[bash]dracut -f /boot/initramfs-3.10.0-862.el7.x86_64.img 3.10.0-862.el7.x86_64[/bash]

If you don’t build for the default kernel, your failover test won’t work as you won’t have the Hyper-V drivers in the default kernel.

Check to see if Hyper-V modules are loaded

If you are able to reboot the VM after running the dracut command to update initramfs, you should then check to see if the Hyper-V modules have been loaded.

[bash]lsinitrd | grep hv[/bash]

You should see something like the following:

All three HyperV kernel modules are now loaded

If those commands worked you should be good to go for failover or migration. I recommend performing a test failover into Azure just to double check, and I would also recommend running a test failover after each kernel upgrade just to make sure all is still working well.

Testing in Azure

Once you have your machine prepped, create a VPG to Azure, and then kick off a test failover.

After the VM is listed in your Virtual Machine inventory click it and go to Boot Diagnostics then the Serial Log tab

Azure Serial Log output, available since we turned on the serial console

You can scroll through the serial output, and look for any issues.

Next Steps

You will probably notice that I did not install the WAAgent into the VM, it is technically not needed to get the VM up and running in Azure. Therefore in my opinion, it can be installed later after you have migrated or failed over. For a Zerto customer who only plans to use Azure while their production site is offline, there may be no reason to install it at all.

Comments are enabled, feedback is appreciated. Let me know if your mileage varies.

3 Responses to "CentOS 7 Azure Tips"

  1. sorry I put the question in another article it should be here

    hi great article I was doing some failover tets today and we had the CentOs issue not booting

    one question is it OK If I install the VM Agent before the failover os it’s all always there?


Leave a Reply