Since I'm such a big container fan (been using them on Linux since 2005) and I recently blogged about Docker, LXC, and OpenVZ... how could I pass up posting this? Some Canonical guys gave a presentation at the recent OpenStack Summit on "LXD vs. KVM". What is LXD? It is basically a management service for LXC that supposedly adds a lot of the features LXC was missing... and is much easier to use. For a couple of years now Canonical has shown an interest in LXC and has supposedly be doing a lot of development work around them. I wonder what specifically? They almost seem like the only company who is interested in LXC.. or at least they are putting forth a publicly noticeable effort around them.
Why Should You Care?
If Canonical can actually deliver on their LXD roadmap it is possible that it will be a suitable substitute for OpenVZ. The main "problem" with OpenVZ is that it is not in the mainline kernel, whereas LXC is. In practice you have to purposefully make an OpenVZ host (currently recommended on RHEL6 or clone) but with LXC/LXD any contemporary Linux system should be able to do full-distro containers... aka containers everywhere for everyone.
How About a Roadmap
Where is LXD now? Well, so far it seems to be mostly a technology preview available in Ubuntu 15.04 with the target "usable and production ready" release slated for the next Ubuntu LTS release (16.04)... which if you weren't familiar with their numbering scheme is 2016 April.
That's about a year away, right... so what do they still have left to do? If you go to about 23:30 in the video you'll get to the "Roadmap" section. They have work to do on storage, networking, resource management and usage reporting, and live migration. A bit of that falls within the OpenStack context... integrating with various OpenStack components so containers will be more in parity with VMs for OpenStack users... but still, that's quite a bit of work.
The main thing I care about absolutely being there is isolation and resource management which are really the killer features of OpenVZ. So far as I can tell, LXD does not offer read-only base images and layering like Docker... so that would be an area for improvement I would suggest. BTW they are using CRIU for checkpointing and live migration... thanks Parallels/OpenVZ!
Certainly LXD won't really make it no matter how good it is until it is available in more Linux distributions than just Ubuntu. In a video interview a while back (which I don't have the link handy for at the moment) Mark Shuttleworth stated that he hopes and expects to see LXD in other distributions. One of the first distros I hope to see with LXD is Fedora and that's the reason I tagged this post appropriately.
Broadening the Echosystem
Historically I've been a bit of an anti-Canonical person but thinking more about it recently and taking the emotion out of it... I do wish Ubuntu success because we definitely need more FLOSS companies doing well financially in the market... and I think Red Hat (and OpenVZ) will have an incentive to do better. Competition is good, right? Anyway, enjoy the video. BTW, everything they tout as a benefit of LXD over KVM (density, speed of startup, scalability, etc) is also true of OpenVZ for almost a decade now.
For those with iFrame issues, here's the YouTube link: LXD vs. KVM
Containers Should Contain
Let's face it, Docker (in its current form) sucks. Why? Well, ok... Docker doesn't totally suck... because it is for applications and not a full system... but if a container doesn't contain, it isn't a container. That's just how language works. If you have an airplane that doesn't fly, it isn't an airplane, right? Docker should really say it is an "Uncontainer" or "Uncontained containers"... or better yet, just use a different word. What word? I'm not sure. Do you have any suggestions? (Email me: firstname.lastname@example.org)
What is containment? For me it is really isolation and resource control. If a container doesn't do that well, call it something else. OpenVZ is a container. No, really. It contains. OpenVZ didn't start life using the word container. On day one they were calling them "Virtual Environments" (VEs). Then a year or two later they decided "Virtual Private Server" (VPS) was the preferred term. Some time after switching to VPS, VPS became quite ambiguous and used by hosting companies using hardware virtualization backends like Xen and VMware (KVM wasn't born yet or was still a baby). Then OpenVZ finally settled on the word "container".
If you want a fairly good history of the birth and growth of OpenVZ over the years, see Kir's recent presentation.
Hopefully LXD will live up to "container" but we'll have to wait and see.
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.
Red Hat's Dan Walsh is *THE* SELinux expert. He gave a presentation on Docker container security at the recent DockerCon 14. If you have any interest in containers or Docker, this is probably worth viewing. Enjoy!
Kir Kolyshkin from the OpenVZ Project talks about Linux Containers:
It seems I've had a lot of questions about OpenVZ container migration lately on the #openvz IRC channel on the Freenode IRC network. While I made a silent screencast on that topic a few years ago, I thought it was time for a refreshed one so here it is. Enjoy.
What is an OpenVZ container? It is a form of virtualization where you can create a type of a virtual machine called a container that is basically a strongly isolated chroot environment with device and resource management features.
What is migration? It is the ability to easily move a container from one physical OpenVZ host to another. Live / online migration allows for no downtime and maintains existing network connections. Offline migration stops the container on the original host and starts it up on the destination host and as a result the containers uptime is reset and existing network connections are dropped. Watch the screencast for all of this in action.
You can also download this directly if desired. right-click, save link as:
openvz-vzmigrate.webm (12.8 MB)
I like to do some walking on Sundays. Walking is what us older people do for exercise. When I walk, I like to listen to audiocasts. One of the programs I've been listening to with some regularity is FLOSS Weekly and the program this week was about OpenShift.
OpenShift is a Platform as a Service (Paas) product that is, as you would expect, built on top of Linux. What is PaaS? System Admins / DevOps are constantly deploying web-based applications. They all use a web server, a database, a scripting language / runtime environment, etc. PaaS automates most of the common tasks needed so you don't have to do the same thing over and over... and can concentrate more on your application.
OpenShift has been available for awhile now as a developer preview service run by Red Hat on top of Amazon Web Services (AWS). Supposedly the current level of service will always be free but they plan to charge for higher levels.
A few weeks ago they released OpenShift as open source project (OpenShift Origin) with an Apache license and no code contributer agreement needed.
Turns out that they have various combinations of things available such as several databases to pick from, several scripting languages, etc. Those things are called "cartridges". Some of the cartridges they have are:
Databases: MySQL, PostgreSQL, and mogoDB
Language runtimes: Node.js, Perl, PHP, Python, Ruby, and Java / JBoss
Frameworks: CodeIgniter, CakePHP, Ruby on Rails, Django, Perl Dancer, Flask, Sinatra, Tornado
Need a libary of web-applications to pick from? OpenSift has "quick-starts" which are pre-packaged web-applications. Included are such things as WordPress, phpMyAdmin and Jenkins.
Another concept they have is a "gear". A gear is really an LXC container. Why they needed to create a new term (gear) rather than just calling it a container, I don't know. So it appears that Red Hat is using Linux native containers (LXC) in a product now... so I hope they'll get more into containers... since I'm a big container (mostly OpenVZ) fan. Dependong on how heavy a particular cartridge is, it may or may not be deployed inside its own gear. They easily fit serveral dozens to a hundred or more gears on each cloud-based virtual machine. While Red Hat runs their service on top of AWS, users are free to create their own setups on top of whatever virtualization platform they want.
OpenShift is written in Ruby but also uses some shell scripts for cartridge and gear operations. What OpenShift does could probably be mimiced with containers that use a large set of OS / Application Templates but the unique feature that makes OpenSift stand out is that it uses git for deployment.
I'm not familiar enough with Ubuntu Development to know just how far this might go but at the very least it appears that some Ubuntu developers have identified as a goal to make LXC usable for production stuff and to put it on par with KVM.
The linux container tools (http://lxc.sourceforge.net) raised some interest for the community but there are crucial functionalities which are missing. The purpose of the session is to identify these missing functionalities and prioritize them in order to have a ready for production component for the Natty server delivery.
Make the use of containers for service segregation on par with KVM in terms of functionality and transparancy.
Joe is a system administrator who wants to start a temporary image to run postfix. To save on resources he runs it using a container. He wants to be able to update the image without fear of updates un-doing hacks needed for containers.
Jane is a system administrator who wants to be able to mix containers with KVM VMs through libvirt. She wants libvirt to auto-start containers, and virt-manager to cleanly shut down the containers.
So far I see identification of problems and need for various features... and a LOT of "todo" lists. I hope they get a significant chunk of that accomplished... so that it can filter back upstream and be used by other distros too.
I'm a long time reader and subscriber to LWN (Linux Weekly News). LWN is probably the best Linux news site out there with regards to covering kernel development and I often find myself eating up considerable amounts of time sifting through their articles. This week they had an article covering some recent progress in the mainline kernel on checkpointing and restoring of processes and containers of processes... and I wrote a somewhat lengthy response that I decided to share here. I would link to the LWN's original article but it won't be anonymously accessible until next week.