At Onlime Webhosting we chose ProxmoxVE as our favorite virtualization platform and are running a bunch of OpenVZ containers for many years now, with almost zero issues. We very much welcome the small overhead and simplicity of container based virtualization and wouldn’t want to move to anything else. ProxmoxVE added ZFS support by integrating ZFSonLinux back in Feb 2015 with the great ProxmoxVE 3.4 release – which actually would have deserved to bump its major version because of this killer feature.
Previously we have been running our OpenVZ containers on plain Debian Linux boxes. But with Debian Wheezy (7.0) the Debian community decided to no longer include a kernel which has been patched with the OpenVZ extensions. Switching to ProxmoxVE at that time was a piece of cake as ProxmoxVE was just a plain Debian Linux with a RHEL kernel, OpenVZ and KVM support, and some nice web interface to manage the containers and VMs. Actually, we never really needed the ProxmoxVE web interface (GUIs always suck!), but that one is quite lightweight and very well integrated. If you don’t like it, use the provided CLI tools – ProxmoxVE does not force you to use the web interface at all.
In 2014 I did a review for Proxmox High Availability (by PACKT publishing). But at Onlime, we never employed any cluster technologies to date. I was always looking for simple solutions without unnecessary complexity. ProxmoxVE with OpenVZ on ZFS pools was the perfect match. We are replicating our containers from one host node to another every 10mins with simple and super fast
zfs send|receive via a modified version of ZREP.
In ProxmoxVE 4, OpenVZ support was removed in favor of LXC. Both, KVM and LXC are built into any newer Linux kernel, so in the long term (and due to the nature of OpenVZ as a huge kernel patch which is hard to maintain) it was clear we had to give up OpenVZ. Even though the OpenVZ developers are currently focusing on merging the OpenVZ and Virtuozzo source codebase and have just released OpenVZ 7.0 I don’t give OpenVZ a long future any more. In comparison to LXC, the tools for OpenVZ are still much more mature and powerful, but lately LXC made a lot of progress and having it perfectly integrated into ProxmoxVE is a great step forward. So, we have decided to migrate to LXC.
(Sorry about the long preface. You probably don’t care about history reading this blog post. I am getting to the point now…)
What I cannot believe and what prevented me to look into LXC on ProxmoxVE up to now is the clumsy migration path that ProxmoxVE suggests on ProxmoxVE Wiki: Convert OpenVZ to LXC. Basically they suggest to dump and restore a full container as follows:
pve3$ vzctl stop 100 && vzdump 100 -storage local
pve3$ scp /var/lib/vz/dump/vzdump-openvz-100.tar root@pve4:/var/lib/vz/dump/
pve4$ pct restore 100 /var/lib/vz/dump/vzdump-openvz-100.tar
Srsly? Do you guys only have containers with sizes below 1GB and don’t care about downtime at all? Real world looks different and I would not even go this migration path with a 5GB container. I don’t even want to think about those containers with ~ 1TB of data.
If you are running OpenVZ containers on ProxmoxVE, sure you have some easy solution to migrate your containers from one host node to another. As I said, we are using ZREP for container replication and have written a wrapper script that migrates a container to its failover host node. That’s what I suggest and please forget about live migration – it never really was working in OpenVZ (well, it was, but I am talking about a really stable solution that never fails) and LXC lacks any kind of hot/live migration. Doing a ZREP presync, stopping the container on the source host node, doing the main ZREP sync, finally starting the container on the destination host node is just a matter of seconds, usually causes a downtime of 10s up to 30s max (on a larger container).