Top.Mail.Ru
? ?

Entries by tag: openvz

Quite frequently, people ask me if OpenVZ is secure enough. They are thinking that because in OpenVZ everything is running under one single kernel (as opposed to, say Xen or VMware, where each partition runs each own kernel), this single kernel is a single point of failure (SPOF).

The answer is: yes, OpenVZ stable kernel is secure enough to be used for production workloads and in hostile environments. Why? The long answer involves a comparison of different virtualization techniques and their SPOFs, a description of OpenVZ architecture, the "denied by default" principle, the fact that its practically proven on a thousands of servers, etc. The short answer is: because we care.

Security is quite a complex field. It's not enough to write secure code once, or secure your system once. In the real world, security comes from constant care. In other words, it’s not enough for a sys admin who is using a good, secure operating system, but doesn't care daily about security.

The Linux kernel is quite secure. Still, new problems are found and resolved from time to time, by those people who care. Most of them are security experts (like Solar Designer), others just work on Linux.

A few days ago, Red Hat released a new update to RHEL4 kernel (RHSA-2007-0014). Let me quote: Red Hat would like to thank Dmitriy Monakhov and Konstantin Khorenko for reporting issues fixed in this erratum.

Both Dmitriy and Konstantin are working in our Virtuozzo/OpenVZ team. Dmitriy works in the Quality Assurance department (which I wrote about before), making sure our kernels are rock-solid (by trying to break it badly, that is). Konstantin works in our kernel support team, mostly fixing the causes of kernel oopses. Besides that, as you see, they both care for security (as well as everybody else in our team). They find bugs (including security bugs), they report and fix those, they send the results to major distribution vendors (and it's not the first time Red Hat has acknowledged our developers), as well as mainstream Linux (again, I wrote about it as well before).

And this is how Linux wins: with all the parties contributing to everybody's benefit.

UML author on OpenVZ

There is a nice interview with Jeff Dike, author and maintainer of User-Mode Linux, published recently on linux.com. There are a couple of statements devoted to OpenVZ:

Dike also noted that SWsoft and XenSource are trying to get OpenVZ and Xen technology, respectively, into the mainline kernel, but says that's unlikely. <...> He also says that OpenVZ is unlikely to be adopted in the mainline kernel tree, at least as it is. Dike says that OpenVZ has to have "code sprinkled all over the place" to work, and it violates conventions within the kernel.

I'd like to comment on this.

1. Just to clarify, our goal is not to merge OpenVZ -- we want to have OS-level virtualization (a.k.a. containers, a.k.a. namespaces) in the mainline kernel. Some parts of that will be from OpenVZ, some from Eric Biederman, some from IBM developers, something from somebody else we don't know yet -- and that is what happening now.

2. We certainly do not want to merge OpenVZ "as it is". The process is like the following: we pick up a piece of OpenVZ functionality, review it, port it to recent -mm release, and submit patches for review. We then get some comments, take them into account and release the next version of the same patch set (example: today Dmitry Mishin has just submitted the third iteration of L2 network namespace patches). Sometimes somebody else pick up what we submit, rework it and send for review. After a few iterations, code is ready to be merged.

3. It is not just ourselves SWsoft and the OpenVZ project who want to have OS-level virtualization in the mainline kernel. Different teams are working on that together -- so it is a collaborative effort. So far, we have achieved some success.

4. Indeed, OpenVZ changes affects the kernel code in multiple places, because OpenVZ adds a new and complex feature, which can be compared to, say, multitasking. Still, this code is easily broken down to several features/subsystems, so it is not like one huge non-reviewable patch.

5. While the OpenVZ patch is big, as compared with the size of changes between minor linux kernel versions, it is actually much smaller. For example, the patch from 2.6.18 to 2.6.19 is 7.7MB (in gzipped form), while the latest OpenVZ patch (028test010, against the same 2.6.18, also gzipped) is only 900KB.

Surely, it's a long way to go. Definitely, we are listening to everybody who likes to be involved. Hopefully, we'll get there.

Tags:

different types of virtualization

As Scott said in the previous post, "more articles to come". He was quite right — here are a couple of articles, both covering the same subject.

My article in the Enterprise Open Source Magazine (print version) talks about different approaches to virtualization, covering emulation, paravirtualization, and OS-level virtualization. Hopefully, it will give people a better understanding of the different types of Linux virtualization technology. The article describes OpenVZ specifically, and provides examples of usage scenarios.

Another nice article on the same topic has been recently published on the IBM developerWorks site.

Tags:

Why Virtuozzo is good for OpenVZ

I'm not a big fan of proprietary software, and this is an official blog of OpenVZ, not Virtuozzo — so I haven't had any plans to tell you anything about the latter. But there is one subject I really want to share with you: why Virtuozzo is good for OpenVZ.

To begin with, Virtuozzo is a commercial product based on OpenVZ software. It adds some more value: features, GUIs, tools (and there is also Virtuozzo for Windblows). The first version of Virtuozzo was released about 6 years ago, so it is not something new. Virtuozzo costs money, and is used by big corporations for mission-critical applications. Virtuozzo customers expect it to be very stable, fast, bug-free, well documented, etc. And to sell the product successfully, those expectations must be met.

But how can all this be achieved? A lot of approaches are used: from having a top-notch development team to dedicating lots of resources to testing the software. Indeed, the Virtuozzo QA team is quite large (as well as their server farm), and there are quite a few talented people (and high-end servers) working there. Those people are doing all the bad things with the kernel, trying hard to bring it down to its knees. The majority of the tests are automated, and more and more cases are added to the extensive test suite. The general idea is to find each and every bug — and fix it before the software ships to the customer.

So, good for them, but how does that affect OpenVZ? Quite simple: OpenVZ is the core of Virtuozzo, and thus it is tested and exercised in the same manner. Not too many open source projects can boast of having such great testing and as a result such high quality.

I have to admit it: this is exactly where proprietary software helps open source software. Without Virtuozzo, OpenVZ quality would definitely be lower. A dedicated quality assurance team is always needed because it's just not appealing for developers to find a new bugs in their code — they'd rather write some more.

PS Certainly the scope of "why Virtuozzo is good for OpenVZ" is much broader than just quality: for example, OpenVZ is also feature-rich because of the same reasons.

LinuxWorld Cologne, Germany

We have just returned back from Germany, where I was presenting OpenVZ at Linux World Cologne. For the first time, we had a separate dedicated booth, and we really enjoyed that.

For those three days, we have met hundreds of people, distributed about 100 of OpenVZ DVDs and booklets, and said about million of words telling and showing people what is OpenVZ, how it can be used, what are pros and cons and so on. Surprisingly, a lot of people found it's just what they need.

We also met a number of existing OpenVZ users — for example, one was using it in a small (25 permanent employees + 25 interns) commercial company, where they need a Samba server, a Collax server, and development server, all of three for some reason requiring three different Linux distributions to run on. So, instead of having three servers, they used OpenVZ to create three VEs. It is a production environment working flawlessly for a few months.

I have also met a student who did his thesis on comparing Xen and OpenVZ performance — the thesis is in German but we might translate a part of it later. If you guessed that OpenVZ outperforms Xen than you are damn right.

Finally, in a true spirit of open source, we helped a Debian OpenVZ user to fix a minor misconfiguration and he was finally able to run OpenVZ on his notebook. He is using OpenVZ as a replacement for UML.

OpenVZ on PPC and SPARC

As you might already know, we have recently ported OpenVZ to PPC64 platform, and that was pretty easy.

Here is the news: we are now porting to SPARC, thanks to Jonathan Kinney, a data systems specialist from Washington, USA. It all started with his question which he posted to forum back in May 2006: “if a Sun Fire T2000 could run OpenVZ?”. The answer at that time was like “no, but if we could have access to that hardware, it is quite possible”.

A few months later, in October, Jonathan returned again to that forum thread and said that he has the hardware and is willing to assist in porting OpenVZ to it. Kirill Korotaev picked it up from there, and just a few minutes ago I heard from him that he now has the kernel, which boots and works. Apparently, the size of patch is just about 1500 lines.

What amazes me in this story is the true cooperation between OpenVZ users and developers for the benefit of the worldwide community.

Tags:

Good news for all of us on the virtualization front!

The latest prepatch for the stable Linux kernel tree, 2.6.19-rc1, now includes some pieces of OS-level virtualization from OpenVZ, IBM, and Eric Biederman. Those patches have been sitting in -mm (Andrew Morton’s) tree for some time already, and now, during the “2.6.19 merge window,” Andrew has submitted them to Linus Torvalds. So it’s now a part of “vanilla” Linux, and will be finally released as a part of the 2.6.19 kernel when it is released.

So, what exactly went into the Linux kernel? Essentially, three sets of patches that implementing three features needed for any OS-level virtualization solution. Those are IPC and utsname virtualization, and preparations for pid namespaces - click for detailsCollapse )

I am really happy it is a community work and a community process (like I said before). We see different parties bringing in code and expertize, reviewing each other's code, making suggestions, exchanging ideas and improving things — to everybody's benefit!

These are just the first steps. Much more is needed to have full OS-level virtualization in the mainstream Linux kernel. Don’t worry — we are already working on that. A few days ago Kirill sent another iteration (v5) of beancounter patchset for further review and possible inclusion. Beancounters can be used to implement per-VE limits and guarantees for certain resources such as memory.

Red Hat thanks OpenVZ kernel hacker

A bit of shameless PR for our kernel team leader, Kirill Korotaev:

From RHSA-2006-0617:

Important: kernel security update
[...]
* a flaw in the restore_all code path of the 4/4GB split support of
non-hugemem kernels that allowed a local user to cause a denial of service
(panic) (CVE-2006-2932, Important)
[...]
Red Hat would like to thank Wei Wang of McAfee Avert Labs and Kirill
Korotaev for reporting issues fixed in this erratum.

OpenVZ contributions to the kernel

I just found out an interesting fact: from the 20 patches that are supposed to be included into the next stable 2.6.17.y (where y=10) kernel, 6 5 were done by OpenVZ developers.

What it could mean, besides the fact that OpenVZ team is a valueable contributor to the mainstream kernel? It also means we do care much for stability and security of OpenVZ, we do a lot of testing and QA, which is good for OpenVZ kernel, but for the mainstream kernel as well.

In a broader sense, this is a nice example of how collaborative open source development works. A nice example of “everybody wins” strategy. Indeed, in open source everybody wins.

Links to individual patches submitted by OpenVZ peopleCollapse )

Update: our kernel team found a bug in this blog post. Looks like the bug belongs to the infamous "off-by-one" category. :) There are actually 5 patches from OpenVZ developers, not 6 — it's just Greg sent one patch twice and thus I counted it twice. Fixed.

Latest Month

July 2016
S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
31      

Syndicate

RSS Atom

Comments

Powered by LiveJournal.com
Designed by Tiffany Chow