Aug 212010
A special thanks to the 35+ attendees who came out on Thursday 08/19/2010 for the GOLUM restart meeting, and a very special thank you to Scott Dowdle from Montana Linux for his presentation on OpenVZ.
As a result of the restart meeting we will now be meeting on last Tuesday of every month at Southwest Tennessee Community College Macon Campus (a special thanks to the STCC for taking the meetings on as a sponsored event).
In addition the Committee to review GOLUM’s existing by-laws and structure consists of:
- Jim Greer (Founder)
- Brian Scurlock
- Richard Shaw
- Wayne Morris
- Rob Mitchell
See everyone on September 28th!
5 Responses to “Restart Meeting Revisited”
Sorry, the comment form is closed at this time.
Just a few follow-up links related to my presentation:
The very complete yet somewhat dated (doesn’t include information about checkpointing, migration, and the veth device) OpenVZ Guide is available as a PDF:
http://download.openvz.org/doc/OpenVZ-Users-Guide.pdf
I wrote a HOWTO for the CentOS wiki that is more up-to-date:
http://wiki.centos.org/HowTos/Virtualization/OpenVZ
Here is my blog posting about the OpenVZ experiment I did. The first phase was over 600 containers and the second try was 1,000 (mentioned in the comments):
http://www.montanalinux.org/openvz-experiment.html
I did a screencast that shows live migration of a container that has a GUI desktop environment installed and connected to via VNC:
http://www.montanalinux.org/openvz-live-migration-demo.html
If you missed my presentation or you’d like to share it with someone who didn’t attend, here is a video from a previous presentation I did at the 2009 Utah Open Source Conference:
http://www.montanalinux.org/utosc2009-openvz-video.html
Here’s a screencast Intro to OpenVZ that I did some time ago:
http://www.montanalinux.org/openvz-brief-intro.html
Here are some links to virtualization related interviews I’ve conducted for anyone who might be interested.
Interview: OpenVZ Project Manager Kir Kolyshkin
http://www.montanalinux.org/openvz-kir-interview.html
Interview: Martin Maurer from Proxmox VE
http://www.montanalinux.org/proxmox-ve-martin-interview.html
Interview: Linux-VServer Project Leader Herbert Pötzl
http://www.montanalinux.org/linux-vserver-interview.html
Interview: Red Hat on Red Hat Enterprise Virtualization
http://www.montanalinux.org/interview-red-hat-rhev.html
Scott, thanks again for the presentation. Here are a few follow up questions I have about OpenVZ.
1. What is the involvement of Parallels in the OpenVZ project?
2. Who exactly creates the OS templates?
3. Are the OS templates audited for security vulnerabilities eg infected packages from rouge developers?
4. What methods (if any) are available for “hot” or “live” backups of a running OpenVZ VM?
5. Are there any specific advantages of using OpenVZ versus VMware Server?
6. Is OpenVZ more like LXC or more like VMware Server/KVM?
Thanks, Rich
1. Parallels is the “sponsor” of the OpenVZ Project. What that means is that they are the primary developers and maintainers of the OpenVZ kernel patch, the website and development infrastructure, etc. Since OpenVZ was released 4 years after the initial release of Virtuozzo, it was rather big and mature. As a result, it has been been rather difficult for outsiders to get involved with OpenVZ kernel development. That doesn’t mean that Parallels doesn’t want outside involvement, they encourage it. There have been a number of external contributions to vzctl and the community is very involved in support, bug reporting, and testing.
2) There are two varieties of OS Templates for download from the OpenVZ website. Official OS Templates provided by the project (http://download.openvz.org/template/precreated/) and those provided by the community (http://download.openvz.org/template/precreated/contrib/).
The official ones are made by a proprietary OS Template build system shared with the Parallels Virtuozzo Containers product and are signed with the OpenVZ project key.
The contributed ones are made by community members. In the header for the contrib download page is some text that tells who/where most of the contributed OS Templates came from. For example, I have contributed OS Templates for Fedora and CentOS and I sign them with my GPG key. I also have write access to the contrib directory and have accepted a number of contributed submissions and edited the header to include the contributor information. Many of the contributions I have personally tested but some of them I haven’t.
Regarding OS Template build systems, OpenVZ ships with vzpkg (only for RPM-based distros) which has unfortunately suffered from bit-rot and is no longer maintained… but anyone can pick if the ball if they want. As I mentioned in my presentation, there is an alternative build system that was written by Robert Nelson (vzpkg2 & pkgcache). It can build both rpm and deb based distros and the only work that appears to be needed are some tweaks to post-install scripts. I wish someone in the community would pick up vzpkg2 maintain it but so far that hasn’t happened.
Oh, also… some hosting service providers that offer OpenVZ-based products roll their own OS Templates as well.
3) OS Templates are similar to distribution respins… where they are primarily just stock distro packages with some minor modifications. I’m not aware of any distros or distro spinoffs that have an automated system that scan them for infected packages. Why not? Because they mainly all used GPG signing keys to verify the authenticity and validity of the packages and iso disk images they provide. which is also what the OpenVZ project does. Many of the contributed OS Templates are signed by their contributors. I sign the OS Templates I contribute. It is a web of trust.
It wouldn’t be that hard to double-check an OS Template though as the major package managers make it a somewhat reasonable prospect. For example, you could make a list of all of the files in the OS Template and ask the package manager which files came from what packages and then use the distro’s package manager to verify all of the packages. Package managers can tell you if any of the files have been altered… if their checksums have changed, if their ownership or permissions have changed, etc. What you’d be left with then (and would want to examine) are all of those files NOT provided by a distro package… which should be a very short list.
I have yet to hear of a rogue OS Template having come from the openvz.org website. Of course that doesn’t mean it isn’t possible so the community remains vigilant.
There are also many wiki articles on how to create OS Templates from scratch if one is so inclined. Many distros have included tools that do most of the work for you (like debootstrap and feboostrap).
4) Backing up a container is very similar to backing up a physical machine. You can use tools like rsync on the live system, but there are certain services (like databases for example) what need a little help… and often offer their own backup utilities.
There is a third party package made by the Proxmox VE guys named vzdump that offers a number of backup methods. I haven’t used vzdump myself but it is my understanding that it can use checkpoint / restore or LVM snapshoting (if you used LVM partitions for your containers) for live backups. For my own backups I just do rsync with periodic container shutdown and a second-pass rsync. That works fine for me because I don’t have a strict uptime QoS I have to keep. If I did, I’d definitely look into vzdump.
5) That is a pretty broad question… and you could have easily chosen any virtualization product on the market instead of VMware and it would still be a valid question. As I said during my presentation… there are a number of virtualization products… none of them suck… and they all seem to have their own niches.
I wasn’t clear if you were asking about VMware Server (the free offering from VMware) or the entire line of VMware products. VMware is one of the oldest and has the largest marketshare. There are things that VMware can do that OpenVZ can’t. The most obvious is that VMware lets you run different OSes whereas OpenVZ is only for Linux on Linux. VMware also has a very layered approach where they layer on additional features for additional costs. You want high availability, they have an add-on for that. You want storage management, they have an add-on for that.
Containers do have their own distinct advantages with regards to scalability and density. I’d say container simplicity and transparency is a feature that you won’t find in many other virt products. Since containers and their mechanisms are easy to understand, it is fairly easy to develop custom management / monitoring apps.
There are a few “control panel” systems (some free, some commercial) available for OpenVZ and the GUI management apps provided with Parallel’s Virtuozzo Container’s product is on par with VMware’s management apps and others. For myself I find the command-line vzctl provided by OpenVZ to be user-friendly enough for me (I love the command line) and very serviceable.
There are some complex use cases that I would rather NOT use containers for. There are some simple use cases that I would NOT want to use a full-blown machine VM for. I’m just glad there is a wide selection of virt products to choose from, each with their own strengths and weaknesses, providing lots of competition in the market.
6) OpenVZ is OS Virtualization aka containers… so it is definitely more like LXC than machine virt products like VMware and KVM.
If and when LXC is fully completed in the mainline kernel, I think Parallels would be happy to see OpenVZ retire. In fact, several Parallels employees have told me personally that they would prefer containers to be part of the mainline so they don’t have to continue to do the hard work of maintaining OpenVZ. They would rather concentrate on GUI management applications.
Some wonder why Parallels doesn’t just get OpenVZ added to the mainline kernel?!? I’m sure they’d just love to do that but it is basically impossible to get a large, mature, and intrusive (after all it touches many subsystems) patch accepted by the mainline kernel developers. The way mainline kernel development works is they want things added slowly over time, with small, incremental patches that are not very disruptive.
There are a number of significant third-party patches that tried to make their way into the mainline only to fail because they had the attributes of OpenVZ… huge, mature, and disruptive. Who can name some? I would but I want to encourage participation in this thread.
LXC has quite a number of contributors and they all have their own particular goals. LXC does what it does quite well and I would like to see it add the few features it is still missing… as well as get one or more all-in-one type management tools like vzctl. If and when that happens, I’ll be switching to LXC. Until such time though, I’ll stick with OpenVZ. I have played with LXC some and I have several friends who use it for a few use cases. LXC is definitely the future of Linux containers.
Thanks Scott! Answered all my questions.