6109R Development: First impressions
A few days into the development of 6109R I'd like to take the time to summarize my first impression and to lay out a roadmap.
In the last week I started to work in earnest in porting Aventurin{e} to EL7 and OpenVZ 7 in order to eventually release Aventurin{e} 6109R.
Download and Install:
So my first stop was the OpenVZ download page for OpenVZ 7. Surprisingly this time around OpenVZ 7 is only available as ISO image, so I went with that to get a feel. All in all I must say this install CD is well done and after struggling so much with the BlueOnyx 5209R install CD for CentOS 7 I really can see how much work and thought went into what they did. They also used Pungi to create their CD and had to heavily modify Anaconda to get the CD working. No surprises there.
Under the hood it became immediately clear that this is not CentOS 7.2. Instead it's "Virtuozzo Linux 7". It's a rebranded CentOS 7 with all the extras thrown in that OpenVZ needs. As before they cleanly split the YUM repository config files. There is one for the virtualization stuff, one for the OS and one for the "OS templates" called "factory".
I played a bit around with it and then ditched it to install a "clean" CentOS 7. On that I tried to "yum install" (or rather group-install) the dependencies needed to get OpenVZ 7 to run. That did not go exactly well. In fact there are dependencies of the virtualization stuff that only the "Virtuozzo Linux 7" repository satisfies. Even Epel comes up dry on some of the more exotic RPMs. Eventually I had to activate the "Virtuozzo Linux 7" repository to get past these obstacles. Even that didn't get me a working environment that was able to create VPS's, as some of the configuration changes that their install CD did weren't present on my YUM installed CentOS 7/OpenVZ chimera.
So I ditched that install and went back to installing OpenVZ 7 and "Virtuozzo Linux 7" off the provided CD.
For the longer haul this creates an interesting challenge, though: To me and at this time it isn't clear under which license "Virtuozzo Linux 7" is released. If I have to roll up 6109R using "Virtuozzo Linux 7" instead of CentOS7, then I might perhaps fall out of good graces with the makers of OpenVZ. I have absolutely no intention to violate their copyright and intellectual property, so I'll have to see what they allow and what not.
At the worst 6109R might only become available as add-on for the "Virtuozzo Linux 7" CD install of OpenVZ 7. Meaning: You install off their CD, add the Aventurin{e} 6109R YUM repository config and then do a "yum groupinstall aventurine" to get 6109R installed.
But like said: That's some food for thought for a later time. Let me get 6109R ready and working first and then we'll see what shall be done about the forms of installation. Ideally a custom 6109R install CD would be preferred, but the design phase will take into account that a "yum groupinstall" should also work cleanly and without problems.
First impressions of using OpenVZ 7:
I've been an avid reader of the OpenVZ mailing list, so some things didn't come as a surprise to me. The trusty shell commands "vzlist" and "vzctl" have been deprecated and got replaced with "prlctl". You can now create either traditional OpenVZ Containers as VPS, but also QEMU KVMs. All with the same shell tools as provided by OpenVZ. Which is really nice.
The command line options for creating containers have changed a lot. You no longer can set some of the 2ndary or tertiary parameters directly. "cat /proc/user_beancounters" still reports them, but they're set to unlimited. This streamlines container setup and management a little. On the other hand: A host of new configuration options were added to deal with CPU usage, attaching additional storage (even USB and CD-ROM devices) to containers. Or making additional disk partitions available to them. The network interface management for VPS's also got more flexible, IPv6 support works out of the box and a lot of other small and big improvements.
These apply across the board both for Containers and KVM's.
The old "VPSID" that we got so attached to? It's gone. VPS's now have a cryptic and unique UUID and can be addressed by a "name" which may contain letters and numbers and a few special characters. So you could now say: "prlctl destroy my_enemy", provided you had a VPS that was named "my_enemy". Yeah, I know. Silly example. ;-)
Another neat newness: "prlctl backup ...", which does a full backup of a running container first time around. And incremental backups every consecutive run. That's pretty slick.
The Ugly:
Less nice is that some really nifty things that used to work fine before have been deprecated. Simfs for example. They included it, but without working disk quota. Which makes it as useful as a fifth wheel. Or in other words: Unusable for us. That leaves "Ploop" as only usable filesystem for Containers for our purposes.
Eventually you might want to "vzmigrate" from OpenVZ 6 (legacy) to OpenVZ 7. There is a procedure for that, but it ain't pretty. The script for that seems to be only available via GIT at this time and it involves a lot of conversion of the migrated containers.
OS Templates: I'm torn on this. I like the new procedure, but I hate the consequences it dumps at us first time around. In short: OS templates that work under OpenVZ 6 do NOT work on OpenVZ 7. The good news is: OpenVZ brought back a working mechanism to create OS templates on the fly and it's even better than the one they originally had. The template directory contains subdirectories for different Linux OS's and their versions. Such as "centos" with subdirectories for version "6" and version "7". There are config files and script directories, which are then used to roll up a freshly created OS template right off the YUM repositories of the distribution. These templates can then be used for both Containers and KVM's. Of course you could also install an OS into a KVM by attaching a VNC console and an ISO off which you want to install.
But as you can imagine: I'm not exactly thrilled to build template caches for BlueOnyx 5209R, 5208R and 5207R. Let alone 5108R, 5107R and 5106R on top of that. Eventually I'll turn my eye to that (as I have to), but it doesn't mean that I have to like it.
How good is it?
As is OpenVZ 7 appears to me as a really great and mostly well rounded improvement over OpenVZ 6 (legacy). I find a lot of new features to my liking. Yet I'm disturbed and mildly upset about the amount of changes small and big which make this a rather rough transition. There are small annoyances such as that "vzlist" was able to poll each and every bloody VPS parameter (including the user_beancounters), while "prlctl" just can't and won't do that. When you peek at the -L parameters it shows a lot less options that you can poll. Likewise user_beancounters now shows parameters that no longer can be configured and are set to unlimited by default. "kmemsize", "dcachesize" and a couple of others. What's useful is that you can now limit IO throughput of VPS's and can set IO priority for VPS. That's actually slick. So I guess we have to take the good with the ugly.
Will I directly move my own VPS to 6109R once 6109R becomes available? I might move some. But I'll not jump at it head over heels. Not because I don't believe in it, but because the transition (i.e.: migration) is so ugly and I don't actually really need any of the improvements right away.
State of the GUI development:
After bringing the build environment and the SVN checkout aboard I needed to change only very little from 6108R to 6109R to get the basic GUI up. I "stole" some CentOS 7 related modules (base-admserv, i18n, base-apache) from the 5209R code tree and was directly good to go. After building "sausalito-devel-tools" and installing all dependencies I could directly roll up 6109R RPMs and pre-populate the development YUM repository with the RPMs.
That gave me a working 6109R GUI right out of the box. There was only a small issue with base-network, as the "Virtuozzo Linux 7" configures it slightly different from what we do for 5209R on EL7, but that was easy to fix.
Naturally the base-vserver module of 6108R doesn't work on 6109R, as it was designed with OpenVZ 6 in mind. It needs to "learn" the OpenVZ 7 tricks first. Which is rather easy, as all of the Container management functions have been offloaded into a separate library. I "just" need to adjust the respective functions in there. At this time Container creation already works, as it was the easiest to adjust.
It won't take long to port the Container management from OpenVZ 6 to OpenVZ 7. We do now have a few new options to configure (and a few old ones that no longer can be configured) this will require some tinkering and familiarizing with the OpenVZ 7 documentation. Likewise the backup mechanism needs to be entirely overhauled to make use of the new "prlctl backup" mechanism.
The easy part will be to get 6109R to the same level of functionality where 6108R is today. But it will not stop there. As we now can easily create and manage Containers and KVM's I'll also need to add a couple of new GUI pages that specifically deal with KVM's. Such as attaching/removing storage and devices and also setting up VNC access. We once used to have that for the KVM version of 6106R, but these pages need to be ported to the new GUI first.
Tentatively speaking I'd say that development of 6109R might wrap up sometime around the middle of 2017.
← Return - Development