Kernel developers don’t get Xen
The recent bruhaha surrounding Xen on LKML (http://lkml.org/lkml/2009/6/2/475) is really disheartening. Essentially, the Linux kernel devs are at a disconnect with users. Some are proposing narrow-minded ideas such as DROPPING software paravirt or merging Xen as a whole into the kernel.
I use Xen for a few primary reasons: it bar none has the best speed — full software paravirtualization pays dividends here; it is mature; it works on perfectly good machines that don’t happen to have the latest chips; it does hardware passthrough on these same systems; it has great live migration that actually works.
Ingo Molnar wants you to send all your perfectly good enterprise iron to the landfill even though these systems will last 10+ useful years without boneheaded software decisions such as this.
These same FUDsters want to strip the crossplatform nature of Xen dom0 out too. Xen dom0 runs on NetBSD and Solaris. It is a true hypervisor and will plug into exisiting architectures, and not force you to use Linux for everything.
I have to admire all the hoops Jeremy Fitzhardinge has jumped through to date, as I know my patience is wearing thin.
Xen powers huge sites such as Amazon and services like linode.com/slicehost.com. By not having dom0 in the kernel where distros such as Ubuntu and Fedora can easily integrate it, kernel devs are doing a disservice to users.
I use KVM, VMWare, and Virtual Box at work in addition, but Xen is firmly entrenched in my toolbox. The roadmap they have looks great, and I just don’t see a reason for decline in Xen popularity. High availability in Xen 4.0 is what I’ve always been waiting for.
Jeremy has gone to great lengths to work with upstream but keeps getting shot down and asked to do something else when he meets one requirement. The solution is to merge Jeremy’s conservative dom0 patch set and work on a technical solution to the patches that the FUDsters consider bad. It’s what the users want!
Related posts:
- Kernel 2.6.30 is a Go I initially thought this would be a rather uninteresting release,...
- I hate Ubuntu I hate Ubuntu. I immediately lose respect for anyone who...
- FS-Cache merged in Kernel 2.6.30 FS-Cache has been merged into the upcoming kernel 2.6.30. This...
- DRBD merged with kernel 2.6.33 DRBD has been a long standing external patch in many...
- Xen 3.4.1 on RHEL/CentOS 5.4 I’m happy to report that the updated Gitco Xen 3.4.1...
Tags: 2.6.31, dom0, paravirt_ops, xen
June 6th, 2009 at 1:30 am
Can you please read that => http://lkml.org/lkml/2009/6/2/352
What is your answer ?
June 6th, 2009 at 1:44 am
@Egan
There seems to be a lot of sentiment toward Xen in the Linux kernel and most (including Linus) point to blanket statements like that (“Xen is hard to merge”) rather than specific code critique/improvements. That’s why it all shouldn’t go in in one merge. Jeremy has separated a lot of the work and has some basic dom0 patches. By accepting these now, it will at least lighten the load Jeremy and distros have to carry to get Xen dom0 kernels built. Then, the focus can shift to cleaning up Xen and merging in more/better/cleaner dom0 code.
My statement is this:
Xen is in wide use. It is hurting more people by having it not in the kernel than having some “hard to merge” code in the kernel. Let us have rudimentary Xen dom0 support in the kernel now, then gradually fix and improve both it (dom0 code) AND xen itself over time.
June 6th, 2009 at 10:06 am
Have you ever tried solutions like openvz or linux-vserver?
IMHO are good solutions, even better xen for linux virtualization if you need best performances from your machines.
June 6th, 2009 at 1:19 pm
@Scorp
I have used both. They have their place in my toolbox as well, specifically for virtual hosting where many copies of the same OS are being used.
Xen and KVM are used a bit differently. They let you run complete Linux operating systems with the vendor kernel, very useful for different versions and also when doing software QA. Of course, they will also run non-Linux kernels which is where they really shine.
What I really would like to see is more documentation on LXC, Linux native containers. This is openvz/linux-vserver support built into the vanilla kernel. It has been in the kernel for a while but nobody is talking about it! I suppose once libvirt supports it well, it should be more accessible to the masses.
http://lxc.sourceforge.net/
June 17th, 2009 at 4:24 am
@kev009: I can understand your frustration. I for one would really like to have dom0 in kernel upstream. But as long as there are patches for it, I wouldn’t think as boldly as you are. You are exactly sounding like what Linus refers to in this very mail. Did you run the command he gave ? I did. I know what it means.
Kernel development is hard enough to deal with unbacked with proof statements: it will be difficult to merge without touching, destabilizing virtually all other subsystems. You are blindly accusing developers who have tried and managed to keep hundreds of thousands of lines of code clean, and merging Xen dom0 code would just sound and be totally incoherent in this respect. Better not merging dirty code than having to clean it up afterwards. The strategy Jeremy saud he would like to be taken for that matter is unrealistic in regards of many other out-of-tree kernel projects. I clearly understands how it can be quite hard to deal with but don’t blame the fact that xen dom0 support for Linux was coded with speed of development in mind. EVERY out-of-tree projects have to pass the review step and if concerns are raised, they HAVE to be addressed, no matter what is the popularity of the project.
Xen has much to gain too, by going thru this process, the larger the code is, the longer the review-and-fix process is.
June 17th, 2009 at 8:48 pm
@regala
You took my post completely out of context and blatantly ignored the concluding paragraph.
I called for the merging of the conservative patches that said developers have approved of on the ML various times. And it appears that they are taking this course of action finally (2.6.31 merge so far has some xen supporting code for dom0).
Nowhere did I say or imply “merge dom0 functionality all at once, right now!!”. This would indeed be stupid. Getting full dom0 support will take several kernel cycles. It has to start somewhere, however small.
June 23rd, 2009 at 4:45 am
They merge whatever they can merge. It is easy to look at things from your POV only but try to be an x86 arch maintainer for a while and see what you ‘ll think then :)
The code that was not merged was all sorts of “if (xen)” stuff that makes the code even more complex and hard to debug. The popularity of the project does play a role and whenever Linus and x86 maintainers can merge something they typically do.
But the linux kernel powers *way* more stuff than Amazon and other cloud stuff and destabilizing it to please xen users would
probably be a wrong decision.
If merging the hypervisor to Linux proper is not possible, then
some other way needs to be found that allows the x86 tree to keep changing as fast as it does now without having complaints from users “oh, you broke xen again”.