How to Migrate an OpenVZ 6 Container to a KVM Server Hassle-Free

Anyone who has ever needed to transfer an OpenVZ container to a server with full KVM virtualization has encountered some problems.

• Most of the information is simply outdated and was relevant for operating systems that have long since reached their EOL cycle.
• Different operating systems always provide different information, and potential errors during migration are rarely considered.
• There are times when you have to deal with configurations that just won't work after the migration.

When transferring one server, you can always fix something on the fly, but what do you do when migrating an entire cluster?

In this article, I will try to explain how to properly migrate an OpenVZ container to KVM with minimal downtime and a quick resolution of all issues.

A brief overview: what is OpenVZ and what is KVM?

We won’t delve into the terminology; instead, let's say this in broad terms:

OpenVZ — virtualization at the operating system level, which can even be deployed on a microwave, as there is no need for CPU instructions or virtualization technologies on the host machine.

KVM — full virtualization which utilizes the full power of the CPU and can virtualize anything, in any way, cutting through in all directions.

Contrary to the common belief that in the hosting providers OpenVZ environment overselling occurs but not in KVM — fortunately for the latter, KVM is currently oversold just as much as its counterpart.

What are we going to migrate?

As test cases for migration, we had to use the entire forest of operating systems available on OpenVZ: CentOS (versions 6 and 7), Ubuntu (14, 16, and 18 LTS), Debian 7.

It was assumed that on the majority of OpenVZ containers, some form of LAMP was already running, and some even had very specific software. Most often, these were configurations with the ISPmanager or VestaCP control panel (often not updated for years). Their requirements for migration must also be taken into account.

Migration is carried out while preserving an IP address the transferable container; we will assume that the IP address that belonged to the container is retained on the VM and will work without problems.

Before migration, let’s make sure we have everything in order:

• An OpenVZ server with full root access to the host machine, the ability to stop/mount/start/delete containers.
• A KVM server with full root access to the host machine, along with all that entails. It is assumed that everything is already set up and ready to go.

Let's begin the transfer

Before we start the transfer, let's define the terms that will help avoid confusion:

KVM_NODE — KVM host machine
VZ_NODE — OpenVZ host machine
CTID — OpenVZ container
VM — KVM virtual server

Preparation for the transfer and creation of virtual machines.

Step 1

Since we need a destination for the container transfer, we will create one VM with a similar configuration on KVM_NODE.
Important! You need to create the VM on the same operating system that is currently running on CTID. For example, if Ubuntu 14 is installed on CTID, then Ubuntu 14 must also be installed on the VM. Minor version mismatches are not critical, but major versions must be the same.

After creating the VM, we will update the packages on both CTID and the VM (do not confuse with OS updates — we don’t update the OS, we only update the packages and, if needed, the OS version within the same major version).

For CentOS, this process looks harmless:

# yum clean all
# yum update -y

And equally harmless for Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Step 2

We install on CTID, VZ_NODE and VM utility rsync:

CentOS:

# yum install rsync -y

Debian, Ubuntu:

# apt-get install rsync -y

We do not install anything else on either.

Step 3

We stop CTID to VZ_NODE with the command

vzctl stop CTID

We mount the image CTID:

vzctl mount CTID

We go to the folder /vz/root/CTID and execute

mount --bind /dev dev && mount --bind /sys sys && mount --bind /proc proc && chroot .

Under chroot, we create the file /root/exclude.txt — it will contain the list of exceptions that will not be transferred to the new server.

/boot
/proc
/sys
/tmp
/dev
/var/lock
/etc/fstab
/etc/mtab
/etc/resolv.conf
/etc/conf.d/net
/etc/network/interfaces
/etc/networks
/etc/sysconfig/network*
/etc/sysconfig/hwconf
/etc/sysconfig/ip6tables-config
/etc/sysconfig/kernel
/etc/hostname
/etc/HOSTNAME
/etc/hosts
/etc/modprobe*
/etc/modules
/net
/lib/modules
/etc/rc.conf
/usr/share/nova-agent*
/usr/sbin/nova-agent*
/etc/init.d/nova-agent*
/etc/ips
/etc/ipaddrpool
/etc/ips.dnsmaster
/etc/resolv.conf
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-ens3

We connect to KVM_NODE and start our VM, so that it is operational and accessible over the network.

Now everything is ready for the transfer. Let's go!

Step 4

While still under chroot, we execute

rsync --exclude-from="/root/exclude.txt" --numeric-ids -avpogtStlHz --progress -e "ssh -T -o Compression=no -x" / root@KVM_NODE:/

The rsync command will perform the transfer, and we hope the flags are clear — the transfer is conducted while preserving symlinks, permissions, owners, and groups, and encryption is turned off for greater speed (a faster cipher could have been used, but that’s not so critical in this task), with compression also disabled.

After the rsync command completes, we exit chroot (by pressing ctrl+d) and execute

umount dev && umount proc && umount sys && cd .. && vzctl umount CTID

Step 5

We will perform some actions that will help us in launching the VM after the transfer from OpenVZ.
On servers with Systemd we execute a command that will help us log into the regular console, perhaps via VNC on the server screen

mv /etc/systemd/system/getty.target.wants/getty@tty2.service /etc/systemd/system/getty.target.wants/getty@tty1.service

On servers CentOS 6 and CentOS 7 we will definitely install a fresh kernel:

yum install kernel-$(uname -r)

The server can boot from it, but it may stop working or be removed after migration.

On the server CentOS 7 you need to apply a small fix for PolkitD, otherwise the server will enter an eternal boot loop:

getent group polkitd >/dev/null && echo -e "e[1;32mpolkitd group already exists e[0m" || { groupadd -r polkitd && echo -e "e[1;33mAdded missing polkitd group e[0m" || echo -e "e[1;31mAdding polkitd group FAILED e[0m"; }

getent passwd polkitd >/dev/null 
&& echo -e "e[1;32mpolkitd user already exists e[0m" || { useradd -r -g polkitd -d / -s /sbin/nologin -c "User for polkitd" polkitd && echo -e "e[1;33mAdded missing polkitd user e[0m" || echo -e "e[1;31mAdding polkitd user FAILED e[0m"; }

rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm verification passed e[0m" || { echo -e "e[1;33mResetting polkit* rpm user/group ownership & perms e[0m"; rpm --setugids polkit polkit-pkla-compat; rpm --setperms polkit polkit-pkla-compat; }

On all servers, if mod_fcgid for Apache was installed, we will apply a small fix for permissions; otherwise, websites using mod_fcgid will crash with a 500 error:

chmod +s `which suexec` && apachectl restart

And finally, this will be useful for Ubuntu and Debian distributions. This OS can enter an eternal boot with the error

looping too fast. throttling execution a little

unpleasant, but easily fixed depending on the OS version.

At Debian 9 The fix looks like this:

we execute

dbus-uuidgen

if we get an error

/usr/local/lib/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.10.8′ not found

we check for the presence of LIBDBUS

ls -la /lib/x86_64-linux-gnu | grep dbus
libdbus-1.so.3 -> libdbus-1.so.3.14.15 
libdbus-1.so.3.14.15 <-- we need this
libdbus-1.so.3.14.16

if everything is fine, we execute

cd /lib/x86_64-linux-gnu
rm -rf libdbus-1.so.3
ln -s libdbus-1.so.3.14.15 libdbus-1.so.3

If it doesn't help — we try the second option.

The second option for solving the issue with throttling execution a little is suitable for practically all Ubuntu and Debian distributions.

We execute

bash -x /var/lib/dpkg/info/dbus.postinst configure

And for Ubuntu 14, Debian 7 additionally, we execute:

adduser --system --home /nonexistent --no-create-home --disabled-password --group messagebus

rm -rf /etc/init.d/modules_dep.sh 

What did we do? We restored the messagebus that was missing for launching Debian/Ubuntu and removed modules_dep, which came from OpenVZ and interfered with the loading of many kernel modules.

Step 6

We restart the VM, check in VNC how the boot is going, and ideally — everything will boot without problems. However, some specific issues may arise after migration — but these are beyond the scope of this article and will be fixed as they come up.

I hope this information will be useful! 🙂

Source: habr.com