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

( 7 comments — Leave a comment )
dowdle
Mar. 17th, 2006 10:22 pm (UTC)
Apples and Oranges of Xen and OpenVZ
I've tried Xen... and it is great if one needs/wants what it has to offer. The Fedora Core developers have put a lot of effort into Xen support for the upcoming FC5 (see FC5 Xen Quickstart Guide). Some of the things you will notice from that document are the recommended system resources:
  • A minimal command-line Fedora system requires around 600MB of storage, a standard desktop Fedora system requires around 3GB.

  • you will want to have 256 megs of RAM per guest that you wish to install

Ok, disks are cheap but really... 256MB of RAM per guest? Ok, let's see. On a machine with 1GB of RAM that would top out at four Xen machines. On 1GB of RAM, I can have (easily) dozens of OpenVZ VPSes.

Again, it depends on what you want to do... sure Xen is more flexible if you can meet the inflexible resource requirements... but for my usage, OpenVZ allows me to squeeze more out of a machine than Xen does, hands down.

Now, I'm just a hobbyist so I can't offer real world data from hundreds of production machines... but I do offer my comments from my limited experiences with both systems.

Will I be playing around with Xen and FC5? Certainly. Heck, I'd really like to get OpenVZ running inside of Xen. That way I can give someone root access to their own OpenVZ system and let them go nuts creating their own VPSes... without it affecting my own Xen machine and its VPSes. :)

Oh, and another thing... take a look at the tools that are provided to install a Xen guest (again as documented in the FC5 Xen Quickstart guide). They have a script that will aid in creating and installing an FC5 guest... and that's about it. The management tools in Xen are quite limited at this time.

While Red Hat, mostly from a marketing standpoint I think, is trying to get ahead of the curve when it comes to virtualization, I think it would do them well to also invest some time and effort into OpenVZ. Oh, and of course, it wouldn't hurt them to make sure VMware runs well too.

(Anonymous)
Mar. 21st, 2006 01:34 pm (UTC)
Re: Apples and Oranges of Xen and OpenVZ
Hi dowdle,
I think you can't really compare openVz with Xen. Xen as hypervisor has a lot of features openVz will never have - for example openSolaris can run side by side with FreeBSD and CentOs on the SAME server using xen. Indeed the memory has to be assigned exclusive to an domU (the virtual server as it is called by Xen).
I think it's kind of a right tool for the right job" thing: If you are after seuqqzing the last bit out of an physical server in the sense of having a lot of customers having some kind of root-access, openVZ is perfect for you. If you wamt to have multiple OSs side by side on the same server (saying Quad Opteron with 32 GB RAM), the Xen just fits fine.

My 2cents,

Frank
k001
Mar. 21st, 2006 02:57 pm (UTC)
Re: Apples and Oranges of Xen and OpenVZ
Yes indeed, if you need to run different kernels, different operating systems on a single box, Xen (or VMware, for that matter) is a way to go.

Still, does anybody use Solaris and Linux on the same box in a production environment? For testing - yes. For fun - yes. For real serious work - I doubt it.

According to farm people who grow apples, it is possible to put a branch from the apple tree and implant it to a peach tree (and vise versa). While this is an interesting thing to do, the apples you buy were grown on apple trees.
dowdle
Mar. 21st, 2006 04:49 pm (UTC)
Re: Apples and Oranges of Xen and OpenVZ
Well, I've discussed your very point on several occasions with various people... so that is why I put in the subject "Apples and Oranges". Of course I know Xen and OpenVZ are different... and that is why Red Hat (and others) should support them all... since they all have a specific void they fill.

What annoys me though is when I tell someone I'm using OpenVZ (because it does what I want and it works very well) and they proceed to try and educate me on how wonderful Xen is and why I should use it. The reason I don't use Xen is because OpenVZ is a much better fit for my needs.

I have to ask who really wants to run different operating systems and kernels on the same machine? A developer or experimenter surely... it is a cool accomplishment... but I just don't see it taking hold in too many production environments. I could be wrong though. The main reason, like I previously mentioned, is the RAM requirements, number of processes, etc. As you are surely aware, each Xen box if a full blown system and as a result, requires appropriate resources. The stated goal is to squeeze more out of the machines you already have. Ok, on most people's machines they might be able to install 2-4 Xen boxes. Contrast that to OpenVZ. I'm only trying to compare the two when they are used in comparable scenarios.

Yes, when you want to run different kernels and OSes... by all means... pick Xen or VMware.
(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.
( 7 comments — Leave a comment )

Latest Month

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

Comments

Powered by LiveJournal.com
Designed by Tiffany Chow