Top.Mail.Ru
? ?

Previous Entry | Next Entry

Xen, kernel modules and code contributions

Red Hat went out public to say loudly about Xen and their plans about that. There is a nice virtualization introduction demo (you need Flash to see it) on their openvirtualization.com site. I have just noticed that if you change the word "Xen" to "OpenVZ", and remove anything concerning "hypervisor", it would be quite an accurate description of what OpenVZ is and what it can do for you. So I welcome everybody to see that demo.

Still, Xen is a bit different. Say, you can not load kernel modules from inside an OpenVZ VPS, or use different kernels for diffrerent VPSs on the same box — but this is possible with Xen.

That leads to the question: what if you need some special kernel module in OpenVZ? The answer is: if it is a device driver and you want to use that device from within one VPS, it is possible (look for '--devnodes' and '--netdev_add' in vzctl man page). If you want to use some special stuff like, say, iptables module, from within a VPS — such module needs to be "virtualized" first (many iptables modules are already virtualized, so you can actually use them from a VPS).

By the way, speaking of that, recently Jason Stubbs, a Gentoo developer, send us a patch to virtualize ipt_REDIRECT kernel module. His work will appear soon in the kernel and vzctl we will release next week. Nice job, Jason!

Comments

(Anonymous)
Mar. 23rd, 2006 06:15 pm (UTC)
Re: Apples and Oranges of Xen and OpenVZ
A lot of people are going to want to run Xen. If you have a small home system then it is not practical I agree.

Enterprises want to run many separate kernels on the same hardware. When you can pack 4 CPUs into a 3U (or less) box with 64GB of RAM why wouldn't you want to run 25 or even 50 operating systems on that box.

Yes, OpenVZ can do many of the same things the multiple kernel approach definitely gives something more resembling a "real" server. If you doubt people want this how do you think VMWare is doing so well.
dowdle
Mar. 23rd, 2006 06:50 pm (UTC)
Re: Apples and Oranges of Xen and OpenVZ
Ok, I agree with that analysis. I'm sure Xen WILL find a niche among those (as you pointed out) who have 3U, 4CPU machines with 64GB of RAM.

If only I had some figures that reveal just how many lower end machines are sold by say... Dell... vs. higher end machines.

Heck, I've been talking to Virtuozzo's sales department some (because they don't do business any other way) to see how much their product costs. In their literature they boast "500+ customers".

Contrast Virtuozzo's "500+ customers" (and it has been around for over 5 years)... to say... how many OpenVZ downloads there are every single day. While I have no figures on the number of OpenVZ downloads... at some point (if it hasn't already) I would assume it would pass the 500+ downloads PER DAY mark.

That isn't to say that people don't want to buy Virtuozzo... or VMware... or use Xen... but there are plenty of "lower hanging fruit" that simply wouldn't consider Virtuozzo or VMware (because of the cost and licensing) and simply don't want or need Xen.

Again, I use that in support of the idea that Red Hat (and SuSE and everyone else) should make sure all virtualization schemes run well on their systems... and I would especially like to see OpenVZ working well in Xen.
k001
Mar. 23rd, 2006 07:14 pm (UTC)
Re: Apples and Oranges of Xen and OpenVZ
There are several issues with the "different OSs on one box" approach, compared with the OpenVZ approach.

First and most obvious one is density/scalability — this one was pointed above in a comment by dowdle. There is no need to go into details here — it's clear anyway that running hundreds of virtual boxes is much prettier then running tens of them. It is always good if you can squeeze more out of your hardware. Another small point that is relevant to this is performance — still this will not be a point in a few years then Intel/AMD will further develop their hardware virtualization support.

Second issue is manageability. Many different OSs, be it Xen domains or VMware VMs, despite the fact that they are on the same box, are still look like a separate instances from the management point of view. That means that mass management is just not possible; all those VMs and domains need to be managed separately, one by one, pretty much the same as if they were a separate physical servers. In contrast, in OpenVZ/Virtuzzo there is a single place from which you can manage all the VPSs on that box. Say, in Virtuozzo for Windows a service pack or a patch is applied to all the VPSs at once. You can migrate your VPS to another box — with latest&greatest VMware VMotion technology this is possible only in the case then SAN (network storage) is used. You can see VPS files from the host system and thus do mass management. Not possible with other technologies. Makes sense?

Third issue is resource management. You give your Xen domain 256MB of RAM and you can't really change it if your database has grown and your DBMS is hungry for memory to be used for its key cache. You have to restart it to add another 256MB -- pretty much the same way if you'd have a physical server and want to add more RAM to it. In OpenVZ, you can tune all the resources runtime, instantly — just because there is a single kernel which manages all of those resources.

Sure it's all software and thus can be fixed. Linux kernel can be (and I believe) modified to add/remove RAM during runtime, this making it possible to change the amount of RAM given to a Linux Xen domain without a need to restart it. Performance issues will be adressed (with the help of Intel/AMD guys). Xen stability will improve over time. Still, that comes with a price. Even now the size of Xen patch is about 1/2 large than that of OpenVZ — and it's still lacking a lot of features.

To conclude, Xen is an interesting technology and probably even be used together with OpenVZ (like you run OpenVZ as a Xen domain and run many VPSs in it). Still, in many scenarios OpenVZ has a clear advantage since it is just more straightforward and lightweight (in terms of overhead) than para-virtualization approach. So, both three virtualization technologies has there uses.

Latest Month

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

Page Summary

Comments

Powered by LiveJournal.com
Designed by Tiffany Chow