Possible problems you will face
In my experience, moving a VMware based CentOS virtual machine to Azure can become quite the headache compared to
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.
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.
Remove persistent network rules
Run the following commands
[bash]sudo ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules rm -f /etc/udev/rules.d/70-persistent-net.rules chkconfig network on[/bash]
These commands will tell Linux not to reserve network names for certain network cards. Basically that eth0 card you have in your Linux VM while it’s on Windows will prevent the Azure network card from getting the eth0 name… running these commands makes Linux say “hey whatever network card I find first…. he gets eth0”.
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
[bash][openlogic] name=CentOS-$releasever – openlogic packages for $basearch baseurl=http://olcentgbl.trafficmanager.net/openlogic/$releasever/openlogic/$basearch/enabled=1 gpgcheck=0[/bash]
Using Vi or nano, add the following line to /etc/yum.conf
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.
if possible, reboot the VM after these steps to make sure that if a new kernel was installed, it is the running kernel before continuing.
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 /boot/grub/grub.conf. Look for the line that starts with “kernel” under your default Kernel boot option… see screenshot below
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.
Configure agetty serial console
The configuration above will enable all of the kernel boot debug to go to the serial console. If you want an interactive login prompt to also be on the serial console after boot up, you need to do this step too.
Use a text editor to create a file at /etc/init/ttyS0.conf
Then paste in the following text
[bash]#This service maintains a agetty on ttyS0. stop on runlevel [S016] start on  respawn exec agetty -h -L -w /dev/ttyS0 115200 vt102[/bash]
Install the Zerto RHEL 6 Re-IP Helper Script
CentOS 6 is very different than CentOS 7 and requires a helper script. This script changes the networking configuration files from Static to DHCP sot hat Azure can assign the proper IP address upon boot in Azure. The script needs to be installed while the machine is on-prem.
[bash]yum install git git clone https://github.com/Zerto-TA-Public/rhel-cloud-reip cd rhel-cloud-reip/ mkdir -p /tmp/reip<br/>cp * /tmp/reip/ cd /tmp/reip/ ./reipinstaller.sh[/bash]
Check to see if Hyper-V modules are loaded
If you are able to reboot the VM after running all the commands above, you should check to see if the Hyper-V modules have been loaded.
[bash]lsinitrd | grep hv[/bash]
You should see something like the following:
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.
You can scroll through the serial output, and look for any issues.
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.