6110R Development started
Aventurin{e} 6110R development started
Since 2006 we have been using OpenVZ for all our virtualization needs. Which mostly center around the ability to create secure containerized Linux VPS's. Which are light weight (compared to VMs), easy to move between nodes, easy to manipulate from an administrator's perspective and very easy to back up.
However: The age of OpenVZ 7 and the inability of its makers to provide a worthy successor left us with no choice but to look elsewhere for the next version of Aventurin{e}: 6110R
This already had been a topic when we rolled up the OpenVZ 7 based Aventurin{e} 6109R. After all: The painting was on the wall. But back then we simply had no other options but to stick with OpenVZ 7 and ride it out. But now? That horse has ridden its last race and it's time to prepare it to ride into the sunset and on into retirement.
So: What's next?
In principle the first choice was LXD, but as initial studies in January and February of 2024 had already shown: There had been exciting changes within the LXD project. Basically Canonical (IP owner) ruffled the fur of the developers and they decided to bugger off and do a fork. That fork is called Incus and it took a while to mature. The latest Incus at this point is a v0.7 and it is already quite useful and working pretty well.So we started using it on a development server and started learning the basics.
Why Incus?
It quickly became clear that Incus can do what we need it to do for us. The networking features that Incus provides are plentiful and allow for such an amount of options and possibilities, that it can be overwhelming at times. It took us most of March and April to acquaint us with that and to explore all options. It also lead to an identified path of how we could best make use of it for our most typical usage cases. If we want Linux containers (and possibly VMs in the future), then Incus is pretty much our only viable choice. Unless we go down to straight up LXC and QEMU. Which Incus both uses anyway. And it provides a unified central management for it with many added features and a rock solid API interface. Why reinvent the wheel? Incus has all we need and then some.
But beyond that we also discovered: The BlueOnyx side of things had to change in order to make this work. For starters Incus instances can be limited in the amount of disk space they may use. But: What we (from the OpenVZ side) know as "2nd level disk quota" (i.e.: group- and user- disk quota INSIDE the instance) is NOT possible.
The development work:
So BlueOnyx needed a new mechanism to both tally as well as to limit the disk usage of Vsites and Users. Integrating that took most of May 2024.
Almost all of June 2024 was spent making sure that BlueOnyx 5210R and 5211R can run fine inside Incus instances AND that BlueOnyx 5211R can serve as a virtualization node for Incus. This meant a rewrite of our network handling stack inside BlueOnyx, but some other odds and sods also had to be adjusted, overhauled or straight up modified.
The whole of July was spent on coding around 40 GUI pages that make up Aventurin{e} 6110R in order to allow us to administer Incus.
Finally: The first week of August was spent to branch out. Instead of just running several development servers we really needed to put some actual load and productive instances onto Aventurin{e} 6110R virtualization nodes and do some stress testing. This provided us with a sigh of relief and a sense of accomplishment, because the result is quite worth it.
Our findings:
Aventurin{e} 6110R works very well and - compared to Aventurin{e} 6109R the new 6110R GUI is really fluid and fast. The underlying Incus v6.3.0? It is rock solid. We did find some minor issues in some GUI pages and the PKG installer during final testing, but these were quickly found and fixed.
All in all? Aventurin{e} 6110R is ready for usage.
← Return