How to move an OpenVZ 6 container to a KVM server without a headache

Everyone who needed to transfer an OpenVZ container to a server with full KVM virtualization at least once in their life faced some problems:

• Most of the information is corny outdated and was relevant for the long-past EOL OS cycle
• Different OSes always provide different information, and never consider possible errors during migration.
• Sometimes you have to deal with configurations that now and then do not want to work after migration

When you transfer 1 server, you can always fix something on the go, but when you transfer an entire cluster?

In this article I will try to tell you how to correctly migrate an OpenVZ container to KVM with minimal downtime and a quick solution to all problems.

A small educational program: what is OpenVZ and what is KVM?

We will not delve into the terminology, but let's say in general terms:

OpenVZ - virtualization at the operating system level, you can even deploy it on a microwave, since there is no need for CPU instructions and virtualization technologies on the host machine.

KVM - full-fledged virtualization that uses the full power of the CPU and is able to virtualize anything, however you like, cut up and down.

Contrary to popular belief that OpenVZ oversells among hosting providers, but KVM does not - fortunately for the latter, KVM now oversells no worse than its brother.

What will we carry?

As test subjects for transfer, I had to use the entire forest of operating systems that are available on OpenVZ: CentOS (6 and 7 versions), Ubuntu (14, 16 and 18 LTS), Debian 7.

It was assumed that on most of the OpenVZ containers some kind of LAMP is already running, and some even have some very specific software. Most often, these were configurations with the ISPmanager control panel, VestaCP (and most often, not updated for years). It is necessary to take into account their requests for transfer.

Migration is carried out while maintaining the IP address of the container being transferred, we will assume that the IP that the container had is stored on the VM and will work without problems.

Before the transfer, make sure that we have everything on hand:

• OpenVZ server, full root access to host machine, ability to stop/mount/start/delete containers
• KVM server, full root access to the host machine, with all the consequences. It is assumed that everything is already configured and ready to go.

Getting Started with Transfer

Before starting the transfer, let's define the terms that will allow us not to get confused:

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

Prepare for migration and create virtual machines.

Step 1

Since we need to transfer the container somewhere, we will create VM with a similar configuration to KVM_NODE.
Important! You need to create a VM on the 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 versions are not important and their mismatch is not so critical, but major ones should be the same.

After creating the VM, we will update the packages on the CTID and on the VM (not to be confused with updating the OS - we do not update it, we only update the packages and, if it arrives, the OS version within the main version).

For CentOS, this process looks harmless:

# yum clean all
# yum update -y

And no less harmless for Ubuntu, Debian:

# apt-get update
# apt-get upgrade

Step 2

Install on CTID, VZ_NODE и VM utility Rsync:

CentOS:

# yum install rsync -y

Debian,Ubuntu:

# apt-get install rsync -y

We do not install anything else either there or there.

Step 3

We make a stop CTID on VZ_NODE the team

vzctl stop CTID

Mounting the image CTID:

vzctl mount CTID

Go to the /vz/root/ folderCTID and perform

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

Under the root, we create the file /root/exclude.txt - it will contain a list of exclusions that will not get 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 VMto make it work and be available over the network.

Now everything is ready for transfer. Go!

Step 4

Still under the spell, 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, we hope that the keys are clear - the transfer is carried out with the preservation of symlinks, access rights, owners and groups and encryption is disabled for greater speed (you could use some faster cipher, but this is not so important within the framework of this task) , as well as disabled compression.

After the completion of rsync, we exit from under the chroot (by pressing ctrl + d) and execute

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

Step 5

Let's take a few steps to help us start the VM after migrating from OpenVZ.
On servers with Systemd let's execute a command that will help us log in to a regular console, for example, through the server's VNC screen

mv /etc/systemd/system/getty.target.wants/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

On servers 6 CentOS и 7 CentOS be sure to install a fresh kernel:

yum install kernel-$(uname -r)

The server can be downloaded from it, but after the transfer it may stop working or be deleted.

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

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

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

rpm -Va polkit* && echo -e "e[1;32mpolkit* rpm verification passede[0m" || { echo -e "e[1;33mResetting polkit* rpm user/group ownership & permse[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 perform a small fix with permissions, otherwise sites using mod_fcgid will crash with a 500 error:

chmod +s `which suexec` && apachectl restart

And lastly, it will come in handy for Ubuntu, Debian distributions. This OS may fall into an eternal boot with an error

looping too fast. throttling execution a little

unpleasant, but easily fixed, depending on the OS version.

On the Debian 9 fix looks like this:

perform

dbus-uuidgen

if we get an error

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

check for 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 <-- нужен этот
libdbus-1.so.3.14.16

if everything is ok, 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, try the second option.

The second solution to the problem with throttling execution a little suitable for almost all Ubuntu and Debian distributions.

perform

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

And for Ubuntu 14, Debian 7 additionally perform:

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

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

What have we done? Restored messagebus, which was missing to run Debian/Ubuntu and removed modules_dep, which came from OpenVZ and interfered with the loading of many kernel modules.

Step 6

We reboot the VM, check in VNC how the download is going, and ideally, everything will boot without problems. Although there may be some specific issues after the migration, they are beyond the scope of this article and are fixed as they arise.

I hope this information is helpful! 🙂

Source: habr.com