OpenVZ

Video: Alpine Linux-based LiveCD with OpenVZ kernel / tools

| | |

I recently encountered an Alpine Linux developer in the #openvz Freenode IRC channel who was working on an Alpine Linux-based LiveCD that uses the OpenVZ Legacy stable kernel and tools. If you aren't familiar with Alpine Linux (and I wasn't prior), it is a very minimal Linux distro that uses BusyBox. The LiveCD shafire (his IRC nick) created is ~ 100MB in size. Since I know OpenVZ very well, shafire asked me to lend a hand with testing.

I recorded a screencast that shows using the LiveCD from start to finish. Being very small, and needing storage space for containers, besides the LiveCD you really need a disk partition for permanent storage. The video shows booting the CD, a few manual steps that are needed to get a proper environment established, creating two containers, starting them, entering them and running some simple commands, shutting them down, and shutting down the host. I did all of the testing using a KVM virtual machine which made it easy for video capture. The video runtime is about 11 minutes and there was no editing of the video... everything is absolutely in real-time with no speedups. It is just THAT fast. :)

The embedded video is in webm/vp9 format and should play fine in contemporary versions of Firefox and Google Chrome. If you are using another browser and can't play the video, feel free to use the link under the video to download it and play with a recent version of the VLC media player. Looks like some video feeds that pick up my blog (planet.openvz.org for example) aren't embedding it properly so in that case, use the link under the video. That should work.

If you prefer to download and play in local media player, here's the direct URL:
alpine-based-openvz-livecd-demo.webm

For those interested in screencast creation and video conversion stuff, I used vokoscreen to capture my screen. It natively output a 175.9 MB .mkv file. I used ffmpeg to convert it to a webm file (vp9 video codec, no audio). The resolution is > 480p and the quality is very good... but amazingly, the filesize for the 11 minute video is only 1.7 MB. I guess ffmpeg / vp9 are awesome at comrpession of this genre of video. I set an upper limit of 200 Kbit for the video bitrate but using a variable bitrate it was able to greatly reduce the bitrate for the bulk of the video.

OpenVZ / Virtuozzo 7 Beta First Impressions

| | |

Odin and the OpenVZ Project announced the beta release of a new version of Virtuozzo today. This is also the next version of OpenVZ as the two are merging closer together. See their release announcement.

There will eventually be two distinct versions... a free version and a commercial version. So far as I can tell they currently call it Virtuozzo 7 but in a comparison wiki page they use the column names Virtuozzo 7 OpenVZ (V7O) and Virtuozzo 7 Commercial (V7C). The original OpenVZ, which is still considered the stable OpenVZ release at this time based on the EL6-based OpenVZ kernel, appears to be called OpenVZ Legacy.

Odin had previously released the source code to a number of the Virtuozzo tools (mailing list post) and followed that up with the release of spec-like source files used by Virtuozzo's vztt OS Template build system. The plan is to migrate away from the OpenVZ specific tools (like vzctl, vzlist, vzquota, and vzmigrate) to the Virtuozzo specific tools although there will probably be some overlap for a while.

The release includes source code, binary packages and a bare-metal distro installer DVD iso.

Bare Metal Installer

I got a chance to check out the bare-metal installer today inside of a KVM virtual machine. I must admit that I'm not very familiar with previous Virtuozzo releases but I am a semi-expert when it comes to OpenVZ. Getting used to the new system is taking some effort but will all be for the better.

I didn't make any screenshots yet of the installer... I may do that later... but it is very similar to that of RHEL7 (and clones) because it is built by and based on CloudLinux... which is based on EL7.

CloudLinux Confusion

What is CloudLinux? CloudLinux is a company that makes a commercial multi-tenant hosting product... that appears to provide container (or container-like) isolation as well as Apache and PHP enhancements specifically for multi-tenant hosting needs. CloudLinux also offers KernelCare-based reboot-less kernel updates. CloudLinux's is definitely independent from Odin and the CloudLinux products are in no way related to Virtuozzo. Odin and CloudLinux are partners however.

Why is the distro based on CloudLinux and does one need a CloudLinux subscription to use it? Well it turns out that Odin really didn't want to put forth all of the effort and time required to produce a completely new EL7-clone. CloudLinux is already an expert at that... so Odin partnered with CloudLinux to produce a EL7-based distro for Virtuozzo 7. While CloudLinux built it and (I think) there are a few underlying CloudLinux packages, everything included is FOSS (Free and Open Source Software). It DOES NOT and WILL NOT require a CloudLinux subscription to use... because it is not related to CloudLinux's product line nor does it contain any of the CloudLinux product features.

The confusion was increased when I did a yum update post-install and if failed with a yum repo error asking me to register with CloudLinux. Turns out that is a bug in this initial release and registration is NOT needed. There is a manual fix of editing a repo file in /etc/yum.repos.ed/) and replacing the incorrect base and updates URLs with a working ones. This and and other bugs that are sure to crop up will be addressed in future iso builds which are currently slated for weekly release... as well as daily package builds and updates available via yum.

More Questions, Some Answers

So this is the first effort to merge Virtuozzo and OpenVZ together... and again... me being very Virtuozzo ignorant... there is a lot to learn. How does the new system differ from OpenVZ? What are the new features coming from Virtuozzo? I don't know if I can answer every conceivable question but I was able to publicly chat with Odin's sergeyb in the #openvz IRC channel on the Freenode IRC network. I also emailed the CloudLinux folks and got a reply back. Here's what I've been able to figure out so far.

Why CloudLinux? - I mentioned that already above, but Odin didn't want to engineer their own EL7 clone so they got CloudLinux to do it for them and it was built specifically for Virtuozzo and not related to any of the CloudLinux products... and you do not need a subscription from Odin nor CloudLinux to use it.

What virtualization does it support? - Previous Virtuozzo products supported not only containers but a proprietary virtual machine hypervisor made by Odin/Parallels. In Virtuozzo 7 (both OpenVZ and Commercial so far as I can tell) the proprietary hypervisor has been replaced with the Linux kernel built-in one... KVM. See: https://openvz.org/QEMU

How about libvirt support? - Anyone familiar with EL7's default libvirtd setup for KVM will be happy to know that it is maintained. libvirtd is running by default and the network interfaces you'd expect to be there, are. virsh and virt-manager should work as expected for KVM.

Odin has been doing some libvirt development and supposedly both virsh and virt-manager should work with VZ7 containers. They are working with upstream. libvirt has supposedly supported OpenVZ for some time but there weren't any client applications that supported OpenVZ. That is changing. See: https://openvz.org/LibVirt

Command line tools? - OpenVZ's vzctl is there as is Virtuozzo's prlctl.

How about GUIs or web-based management tools? - That seems to be unclear at this time. I believe V7C will offer web-based management but I'm not sure about V7O. As mentioned in the previous question, virt-manager... which is a GUI management tool... should be usable for both containers and KVM VMs. virsh / virt-manager VZ7 container support remains to be seen but it is definitely on the roadmap.

Any other new features? - Supposedly VZ7 has a fourth-generation resource management system that I don't know much about yet. Other than the most obvious stuff (EL7-based kernel, KVM, libvirt support, Virtuozzo tools, etc), I haven't had time to absorb much yet so unfortunately I can't speak to many of the new features. I'm sure there are tons.

About OS Templates

I created a CentOS 6 container on the new system... and rather than downloading a pre-created OS Template that is a big .tar.gz file (as with OpenVZ Legacy) it downloaded individual rpm packages. It appears to build OS Templates on demand from current packages on-demand BUT it uses a caching system whereby it will hold on to previously downloaded packages in a cache directory somewhere under /vz/template/. If the desired OS Template doesn't exist already in /vz/template/cache/ the required packages are downloaded, a temporary ploop image made, the packages installed, and then the ploop disk image is compressed and added to /vz/template/cache as a pre-created OS Template. So the end result for my CentOS 6 container created /vz/template/cache/centos-6-x86_64.plain.ploopv2.tar.lz4. I manually downloaded an OpenVZ Legacy OS Template and placed it in /vz/template/cache but it was ignored so at this time, I do not think they are compatible / usable.

The only OS Template available at time of writing was CentOS 6 but I assume they'll eventually have all of the various Linux distros available as in the past... both rpm and deb based ones. We'll just have to wait and see.

As previously mentioned, Odin has already released the source code to vztt (Virtuozzo's OS Template build system) as well as some source files for CentOS, Debian and Ubuntu template creation. They have also admitted that coming from closed source, vztt is a bit over-complicated and not easy-to-use. They plan on changing that ASAP but help from the community would definitely be appreciated.

How about KVM VMs?

I'm currently on vacation and only have access to a laptop running Fedora 22... that I'm typing this from... and didn't want to nuke it... so I installed the bare-metal distro inside of a KVM virtual machine. I didn't really want to try nested KVM. That would definitely not have been a legitimate test of the new system... but I expect libvirtd, virsh, and virt-manager to work and behave as expected.

Conclusion

Despite the lack of perfection in this initial release Virtuozzo 7 shows a lot of promise. While it is a bit jarring coming from OpenVZ Legacy... with all of the changes... the new features... especially KVM... really show promise and I'll be watching all of the updates as they happen. There certainly is a lot of work left to do but this is definitely a good start.

I'd love to hear from other users to find out what experiences they have.

Congrats Odin and OpenVZ! I only wish I had a glass of champagne and could offer up a respectable toast... and that there were others around me to clank glasses with. :)

This article is translated to the Bosnian language by Vlada Catalic.


Video: Fedora 22 MATE Desktop OpenVZ container on release day

| |

If you didn't notice, Fedora 22 was released today. Today I refreshed the Fedora 22 OS Template I made for OpenVZ and uploaded it to contrib. For fun, I thought I'd build a MATE Desktop GUI container right in front of your eyes... and then connect to it via x2go.

Installing a desktop environment in a container can be fraught with danger for the uninitiated. The problem? Well, it always drags in NetworkManager, a graphical login manager, and various other packages / services that aren't really appropriate for a container. With a handful of systemd statements though, it is an easy fix. Watch and I'll show you how. Enjoy!

For those with iFrame issues, here's a direct link to the webm video:
openvz-fedora22-mate-container.webm

You can pretty much use the same recipe for other desktop environments. The only thing you want to avoid are desktop environments that require accelerated 3D because those won't work over x2go. Which desktops use that? GNOME and Plasma 5... Cinnamon probably... and if you were on Ubuntu, Unity. XFCE, MATE, OpenBox, LXQT, etc work fine... although I haven't tried them all.

OpenVZ Survey Answers

| | |

One of the Virtuozzo folks sent a link to an OpenVZ survey that I filled out. It requires a Google account. I do have one but I try to avoid using it as much as possible.

Just wanted to share my answers to the, "What features are absent in OpenVZ from your point of view?" question.

1) Base images and layering like that of Docker. Docker mostly sucks but the ease and speed of deployment is amazing. The OpenVZ container creation tools... can they be adapted to use a pre-existing ploop image as a read-only base image?

2) Application containers. While I don't have a personal need for them quite yet I can definitely see how they are handy for developers as well as those into fleet computing.

3) qcow2 disk images are very popular with KVM. It isn't clear to me what benefits ploop offers over qcow2 or vice-versa. It would be nice if OpenVZ could use or convert qcow2 disk images.

4) Better OS Template tools. OpenVZ's vzpkg tool bit-rotted because there weren't enough developer resources to keep it alive. As a result OpenVZ's official OS Templates have been being built with the proprietary Virtuozzo tools for some time. I understand that is changing in the not too distant future with the public release of more of Virtuozzo's tools. I'm not familiar with those so I don't know how good they are... but yes, more attention to OS Template creation and management tools is needed. This is especially true if and when OpenVZ adds application containers and/or disk layering features.

5) Better integration with LXC in the mainline kernel. I think LXC and Docker could be a stepping stone to OpenVZ / Virtuozzo... if the OpenVZ tools worked reasonably well with LXC in the mainline kernel... and it was clear to the user what features they could gain if they moved up to OpenVZ and/or Virtuozzo.

6) An entry-level web panel. OpenVZ Web Panel seems somewhat popular but I've always been turned off by its reliance on Ruby... and unsure of its security-related testing. The recent Packt Publishing book, "OpenVZ Essentials" by Mark Furman spends half of the book covering OpenVZ Web Panel. It would be nice if OWP was adopted in some way or replaced with something similar to offer an entry-level web-based management system like VMware does with ESXi. If considered, I'd strongly recommend that there is a clear differentiation between the features in the entry-level web-panel and those commercially offered. I know a few companies are selling OpenVZ compatible web-interfaces... like SolusVM, Proxmox VE, etc.

7) More modern kernel support... but that is in-the-works.

Containers Reloaded

| | | |

I've been busy lately trying to learn more about Docker. I'm not much of a fan of "application containers" and still prefer a full-blown "distro container" like that provided by LXC (good) or OpenVZ (better)... but I have to admit that the disk image / layering provided by Docker is really the feature everyone loves... which provides almost instantaneous container creation and start-up. If OpenVZ had that, it would be even more awesome.

OpenVZ certainly has done a lot development over the past couple of years. They realized that simfs just wasn't cutting it and introduced ploop storage... and then made that the default. ploop is great. It provides for instant snapshots which is really handy for doing zero-downtime backups. I wonder how ploop differs these days from qcow2? I wonder how hard it would be to add disk layering features like Docker to OpenVZ with ploop snapshots?

Applications Containers In the Beginning

Ok, so Docker has taken off but I really can't figure out why. I mean Red Hat introduced OpenShift some time ago. First it was a service, then a product, and lastly a open source product that you can deploy yourself if you don't need support. A couple of years ago I attended an OpenShift presentation and at that time it provided "Gears" which were basically chrooted processes with a custom SELinux policy applied... and cgroup resource management? Something like that. While (non-OpenVZ) containers don't contain, with the SELinux added, OpenShift gears seemed to be secure enough.

OpenShift offered easy deployment via some git-based scheme (if I remember correctly) and a bunch of pre-packaged stacks, frameworks, and applications called "cartridges" which I see as functionally equivalent to the Docker registry.. It didn't have the disk image layering and instant startup of Docker so I guess that's was a minus.

These days I guess OpenShift is going to or has shifted to using Docker.

Docker Crawls Before It Can Walk

Docker started off using aufs but that was an out-of-tree filesystem that isn't going to make it into mainline. Luckily Red Hat helped by adapting Docker to use device mapper-based container storage... and then btrfs-based container storage was added. What you get as default seems to depend on what distro you install Docker on. Which of the three is performant and which one(s) sucks... again that depends on who you talk to and what the host distro is.

Docker started off using LXC. I'm not sure what that means exactly. We all know that LXC is "LinuX native Containers" but LXC seems to vary greatly depending on what kernel you are running and what distro you are using... and the state of the LXC userland packages. Docker wised up there and decided to take more control (and provide more consistency) and created their own libcontainer.

The default networking of Docker containers seems a bit sloppy. A container gets a private network address (either via DHCP or manually assigned, you pick) and then if you want to expose a service to the outside world you have to map that to a port on the host. That means if you want to run a lot of the same service... you'll be doing so mostly on non-standard ports... or end up setting up a more advanced solution like a load balancer and/or a reverse proxy.

Want to run more than one application / service inside of your Docker container? Good luck. Docker was really designed for a single application and as a result a Docker container doesn't have an init system of its own. Yeah, there are various solutions to this. Write some shell scripts that start up everything you want... which is basically creating your own ghetto init system. That seems so backwards considering the gains that have been made in recent years with the switch to systemd... but people are doing it. There is something called supervisor which I think is a slight step up from a shell script but I don't know much about it. I guess there are also a few other solutions from third-parties.

Due to the complexity of the networking and the single-app design... and given the fact that most web-services these days are really a combination of services that are interconnected, a single Docker container won't get you much. You need to make two or three or more and then link them together. Links can be private between the containers but don't forget to expose to the host the port(s) you need to get your data to the outside world.

While there are ways (hacks?) that make Docker do persistent data (like mapping one or more directories as "volumes" into the container or doing a "commit"), Docker really seems more geared toward non-persistent or stateless use.

Docker Spaghetti

Because of all of these complexities, which I really see as the result of an over-simplified Docker design, there are a ton of third-party solutions. Docker has been trying to solve some of these things themselves too. Some of Docker's newer stuff has been seen by some (for example CoreOS) as a hijacking of the original platform and as a result... additional, currently incompatible container formats and tools have been created. There seems to be a new third-party Docker problem solver start-up appearing weekly. I mean there are a ton of add-ons... and not many of them are designed to work together. It's kind of like Christianity denominations... they mostly believe the same stuff but there are some important things they disagree on. :)

Application Containers Are Real

Ok, so I've vented a little about Docker but I will admit that application containers are useful to certain people... those into "livestock" virtualization rather than "pet" virtualization aka "fleet computing". Those are the folks running big web-services that need dozens, hundreds or thousands of instances of the same thing serving a large number of clients. I'm just one one of those folks so I prefer the more traditional full-distro style of containers provided by OpenVZ.

Working On Fedora 22

I've already blogged about working on my own Fedora 22 remix but I've also made a Fedora 22 OpenVZ OS Template that I've submitted to contrib. Yeah, it is pre-release but I'll update it over time... and Fedora 22 is slated for release next week unless there are additional delays.

Like so many OpenVZ OS Templates my contributed Fedora 22 OS Template doesn't have a lot of software installed and is mainly for use as a server. For my own use though I've added to that with the MATE desktop, x2goserver, Firefox, LibreOffice, GIMP, Dia, Inkscape, Scribus, etc. It makes for a pretty handy yet light desktop environment. It was a little tricky to build because adding any desktop environment will drag in NetworkManager which will overpower ye 'ole network service and break networking in the container upon next container start. So while building it "vzctl enter" access from the OpenVZ host node was required. With a handful of systemctl disable / mask commands it was in working order again. Don't forget to change the default target back to multi-user from graphical... and yeah, you can turn off the display manager because you don't need that since x2go is the access method of choice.

BTW, there was a libssh update that broke x2go but they should have that fixed RSN.

Multi-purpose OS Templates

I also decided to play with LXC some on my Fedora 22 physical desktop. I found a libvirt-related recipe for LXC on Fedora. Even though it was a little dated it was very helpful.

The yum-install-in-chroot method of building a container filesystem really didn't work for me. I guess I just didn't have a complete enough package list or maybe a few things have changed since Fedora 20. I decided to re-purpose my Fedora 22 OpenVZ OS Template. I extracted it to a directory and then edited a few network related files (/etc/sysconfig/network, removed /etc/sysconfig/network-scripts/ifcfg-venet*, and added an ifcfg-eth0 file). I also chroot'ed into the directory and set a root password and created a user account that I added to the wheel group for sudo access.

After a minute or so for the minor modifications (and having left the chroot'ed environment) I did the virt-install command to create a libvirt managed LXC container using the new Fedora 22 directory / filesystem... and bingo bango that worked. I also added some GUI stuff and just like with OpenVZ I had to disable NetworkManager or it broke networking in the container. Anyway... running an LXC container is a like OpenVZ on a mainline kernel... just without all of the resource management and working security. Baby steps.

Containers Taken Too Far?

While hunting down some videos on Docker I ran into RancherVM. What is that? To quote from their description:

RancherVM is a new open source project from Rancher Labs that makes it simple to run KVM inside a Docker container.

What they heck? Run KVM VMs inside of Docker containers? Why would anyone want to do that? Well, so you can embed KVM VM disk images inside of Docker images... and easily deploy a KVM VM (almost) as easily as a Docker container. That kind of makes my head hurt just thinking about running a Windows 7 Desktop inside of a Docker container... but someone out there is doing that. Yikes!

-----
Thanks to Vlada Catalic for translating this article into Bosnian.

Video: FLOSS Weekly 334 - CRIU

| | |

Checkpoint and Restore In Userspace is a project I'm very interested in as it is associated with OpenVZ and will be used in the upcoming EL7-based OpenVZ kernel branch... which was recently released in beta. The FLOSS Weekly folks have two developers on from the project. Enjoy!

BTW, Kir gave me (and Donnie) a brand spanking new CRIU tee-shirt at LFNW. Thanks Kir!

Must get moose and squirrel!

Video: LFNW2015 - OpenVZ, Virtuozzo, and Docker

| |

There are a few bad spots in the video that I attribute to an SDcard going bad... and yeah, there is some hiss in the audio (internal mic rather than a wireless one)... but overall, very watchable. Enjoy!

OpenVZ: Past and Future

| |

Kir posted the following this evening on the OpenVZ blog:

Looking forward to 2015, we have very exciting news to share on the future on OpenVZ. But first, let's take a quick look into OpenVZ history.

Linux Containers is an ancient technology, going back to last century. Indeed it was 1999 when our engineers started adding bits and pieces of containers technology to Linux kernel 2.2. Well, not exactly "containers", but rather "virtual environments" at that time -- as it often happens with new technologies, the terminology was different (the term "container" was coined by Sun only five years later, in 2004).

Anyway, in 2000 we ported our experimental code to kernel 2.4.0test1, and in January 2002 we already had Virtuozzo 2.0 version released. From there it went on and on, with more releases, newer kernels, improved feature set (like adding live migration capability) and so on.

It was 2005 when we finally realized we made a mistake of not employing the open source development model for the whole project from the very beginning. This is when OpenVZ was born as a separate entity, to complement commercial Virtuozzo (which was later renamed to Parallels Cloud Server, or PCS for short).

Now it's time to admit -- over the course of years OpenVZ became just a little bit too separate, essentially becoming a fork (perhaps even a stepchild) of Parallels Cloud Server. While the kernel is the same between two of them, userspace tools (notably vzctl) differ. This results in slight incompatiblities between the configuration files, command line options etc. More to say, userspace development efforts need to be doubled.

Better late than never; we are going to fix it now! We are going to merge OpenVZ and Parallels Cloud Server into a single common open source code base. The obvious benefit for OpenVZ users is, of course, more features and better tested code. There will be other much anticipated changes, rolled out in a few stages.

As a first step, we will open the git repository of RHEL7-based Virtuozzo kernel early next year (2015, that is). This has become possible as we changed the internal development process to be more git-friendly (before that we relied on lists of patches a la quilt but with home grown set of scripts). We have worked on this kernel for quite some time already, initially porting our patchset to kernel 3.6, then rebasing it to RHEL7 beta, then final RHEL7. While it is still in development, we will publish it so anyone can follow the development process.

Our kernel development mailing list will also be made public. The big advantage of this change for those who want to participate in the development process is that you'll see our proposed changes discussed on this mailing list before the maintainer adds them to the repository, not just months later when the the code is published and we'll consider any patch sent to the mailing list. This should allow the community to become full participants in development rather than mere bystanders as they were previously.

Bug tracking systems have also diverged over time. Internally, we use JIRA (this is where all those PCLIN-xxxx and PSBM-xxxx codes come from), while OpenVZ relies on Bugzilla. For the new unified product, we are going to open up JIRA which we find to me more usable than Bugzilla. Similar to what Red Hat and other major Linux vendors do, we will limit access to security-sensitive issues in order to not compromise our user base.

Last but not least, the name. We had a lot of discussions about naming, had a few good candidates, and finally unanimously agreed on this one:

Virtuozzo Core

Please stay tuned for more news (including more formal press release from Parallels). Feel free to ask any questions as we don't even have a FAQ yet.

Merry Christmas and a Happy New Year!

Since Russia has 10 days of holidays in January, I really don't expect anything to be released until late January or more likely in February. One major change in the upcoming RHEL7-based Virtuozzo Core release is the move from the internal chkpoint code to CRIU. Although there are a lot more details and specifics to come, overall I see this as a very possitive move.

OpenVZ: Contributed OS Template of CentOS 7 Public QA

|

I wondered if I could make an OS Template of the CentOS 7 Public QA release... and I could. Here's more info copied and pasted from the email I sent to the OpenVZ Users Mailing list announcing its availability:

Greetings,

As you may already know, Red Hat released Red Hat Enterprise Linux 7 on Tuesday (June 10th). A while ago the two main CentOS developers got hired by Red Hat to work on CentOS because Red Hat is now the sponsor behind CentOS... like they are behind Fedora. Anyway... the CentOS folks are working hard and fast to try to get CentOS 7 out ASAP... although they are going to keep their high release quality standards (it's as good as RHEL and as bad as RHEL, hehe). Something new they are doing now is trying to be as transparent and public as possible. They have placed their build system in the open, all of the package code in git, etc.

On June 13th CentOS announced that they have made the initial built of (most of) the rpm packages for CentOS 7. On June 14th they announced the build-tree was fairly complete including a boot.iso that could be used for a network install. Anyway, for the full story, read http://seven.centos.org/.

I've been busy working with the "CentOS 7 Public QA" release making an installable LiveDVD (check) and making an OpenVZ OS Template (check). The later is what this email is about. I have uploaded "centos-7-pubqa-20140615.tar.xz" (and .asc GPG sig file) to the OpenVZ contributed OS Templates directory. A few notes:

1) CentOS 5 uses SysV init. CentOS 6 uses Upstart basically in SysV compatibility mode. CentOS 7 uses systemd. If you create a container from an OS Template named centos-{something} I think it'll use the current CentOS config scripts provided by vzctl... which probably won't work because of the big change in init systems. CentOS 7 is a LOT like the last few releases of Fedora that have also been systemd-based... so what I did on my OpenVZ host where I wanted to use this centos-7-pubqa-20140615.tar.xz contributed OS Template was... make a symlink in /vz/templace/cache/ named fedora-19-x86_64.tar.xz that points to centos-7-pubqa-20140615.tar.xz. Then when I used vzctl to create the container, I told it to use the fedora19 OS template. Of course if you already have an OS Template named fedora-19-x86_64.tar.* make the symlink named something else and refer to it appropriately. I asked for a clarification from Kir on that... because maybe I'm imagining the issue.

2) The current CentOS 7 Public QA build-tree does not provide /etc/yum.repos.d/centos*.repo files. Why? Because the location of the current build system and all of the rpm packages is in a temporary place and won't be finalized until the final release comes out. In my OS Template I created /etc/yum.repos.d/centos-7-public-qa-20140615.repo that refers to the *CURRENT* location of all of the packages. Doing that makes yum work... and you can install and remove software as desired. I'm sure they will be updating the build-tree and package location quite a bit between now and final release... so if the current location goes away or there is a newer build... you'll have to update the .repo file to point to wherever it needs to point. It was working fine when I uploaded it.

3) RHEL7 is only offered in a 64bit flavor... and as a result... the OS Template is 64bit. It will not run on a 32bit OpenVZ host node. Don't even try it. It won't hurt anything but you'll get an error and if you don't know what the issue is, you'll probably go to IRC and bug people there about it... which would be a waste of everyone's time... but if you do do that... hopefully we'll be able to tell you what the problem is. The OS Template name I gave was already long enough and I didn't want to add x86_64 to it... because people would probably think there was a missing i686 build coming. There isn't.

4) How did I make this OS Template? It was rather simple. I created a CentOS 7 KVM virtual machine installing from the network media currently available. I did a minimal install. Then I rsync'ed the contents of VM's virtual disks to an OpenVZ host node. Then I made the minor changes needed... (not all but most) mentioned in the OpenVZ p2v wiki page. Then I tar.xz'ed it up and plopped it in /vz/template/cache... made a container out of it... and it worked first attempt. Then I cleaned it up by removing unneeded packages (grub2, kernel, firmware packages, unwanted services [firewalld, ipr*, etc], etc). Then I added a few things I like (httpd, screen, mc, nano, links, etc). Then I tested it. Then I made a new OS Template by tar.xz'ing up the container's directory. Then I made a new container out of the new OS Template and tested. Works pretty darn well. I'm sure there are some lingering dirs/files from packages I removed... and probably another handful or two of packages that could be removed to make it smaller but hey... it is ~98MB as a .tar.xz. Installed it takes up slightly less than 700MB. Not too bad for a first attempt.

If you have any comments or questions, just ask. Enjoy!

Update: One of the heads of the CentOS Project told me that he thought releasing such an OS Template was a little too "user facing" for a Public QA release and asked me to take it down, so I did. I'll continue to build the testing OS Templates until the QA version comes out at which point I should have a final CentOS 7 OS Template out on release day.


How about an OpenVZ CentOS Variant?

| |

I've used RHEL, CentOS and Fedora for many years... and as many of you already know... back in January, CentOS became a sponsored project of Red Hat. For the upcoming CentOS 7 release they are going beyond just the normal release that is an as-perfect-as-possible clone of RHEL. They have this concept of variants... where Special Interest Groups (SIGs) are formed around making special purpose builds of CentOS... spins or remixs if you will. I don't know a lot about it yet but I think I have the basic concept correct.

Looking at the numbers on http://stats.openvz.org/ I see:

Top  host   distros
-------------------
CentOS	     56,725
Scientific    2,471
RHEL	        869
Debian	        576
Fedora	        111
Ubuntu	         82
Gentoo	         54
openSUS          18
ALT Linux        10
Sabayon	          6

and

Top 10  CT  distros
-------------------
centos	    245,468
debian	    106,350
ubuntu	     83,197
OR	      8,354
gentoo	      7,017
pagoda	      4,024
scientific    3,604
fedora	      3,173
seedunlimited 1,965

Although reporting is optional, the popularity of CentOS as both an OpenVZ host and an OpenVZ container surely has to do with the fact that the two stable branches of the OpenVZ kernel are derived from RHEL kernels.

Wouldn't be nice if there were a CentOS variant that has the OpenVZ kernel and utils pre-installed? I think so.

While I have made CentOS remixes in the past just for my own personal use... I have not had any official engagement with the CentOS community. I was curious if there were some OpenVZ users out there who are already affiliated with the CentOS Project and who might want to get together in an effort to start a SIG and ultimately an OpenVZ CentOS 7 variant. Anyone? I guess if not, I could make a personal goal of building a CentOS and/or Scientific Linux 6-based remix that includes OpenVZ... as well as working on it after RHEL7 and clones are released... and after such time the OpenVZ Project has released a stable branch based on the RHEL7 kernel.

I will acknowledge up front that some of the top CentOS devs / contributors have historically been fairly nasty to OpenVZ users on the #centos IRC channel. They generally did not want to help someone using a CentOS system running under an OpenVZ kernel... but then again... their reputation is for being obnoxious to many groups of people. :) I don't think we should let that stop us.

Comments, feedback, questions?

Update: Wow, looking here, they already have OpenVZ listed as being of interest in their Virtualization SIG.

Syndicate content