In recent days I was trying to install XEN hypervisor on Slackware 14 for testing purposes. I spent huge amount of time to install it (Kernel adjustments, dependency resolution :-) GRUB settings and so on) There is a lot of work to be done to get it working. Finally, once XEN was installed and I rebooted my system, I encounter some problems with my system (modules were not loaded to pure system - without hypervisor).
So I thought - let's give a try and go with Debian. Guys, 30min and I had working XEN.
But finally I found Debian as too automatic. There is no control over many stuff... Anyway lets back to Slackware.

I'm wondering if it possible to push XEN (or other hypervisior) into Slackware 14.1. Now, when we have GRUB on board it is a great opportunity.
We have 2013 and everything is "virtual" or running in clouds. It would be great to have working hypervisior in Slackware out of the box.

What do you think about this?

Have you tried e-mailing the xen maintainer for SlackBuilds.org? He has SlackBuild scripts and everything. Perhaps you can work with him.

Considering that Xen is now 100% open-source and free (to RMS standards), and that it is a top quality hypervisor, it may well be a good inclusion into standard Slackware. To me Slackware is easily the best server distro going (based on simplicity, reliability and most-importantly - predictable package management), and Xen is really best in server environments. For desktops (where I also use Slackware), VirtualBox fits well, but it's not as free or open. +1

VirtualBox is free and Open. You can download the sources in their download page
For something big as XEN, i think it should stay in SBo project

@willysr - are you 100% sure about that ? Does that include the Extension Packs ? I did a (very) quick perusal of the source tree and can't see them fully (other than some examples). I's sure there was always a difference between the so-called open-source version and the binary, especially with features such as USB access. I would be happy to be wrong, but quite frankly I do not trust Oracle.

And I'm not sure that "size" should be a decider on whether the software should be in SBo or Slackware. I'm sure there are bigger systems currently in Slackware (Gimp,gcc,tex etc).

No, i'm not talking about size, but i mean the complexity and maintainability since i remember during the development of Slackware 14.0, the XEN package in SlackBuild are getting a lot of patches in order to have it built and it took some time to be considered stable at that moment.

The source code is available here: https://www.virtualbox.org/browser/vbox/trunk, but that is only the virtualbox, not the extension pack. The extension pack remains closed as described here: https://www.virtualbox.org/wiki/Editions

Ah - build complexity is the issue. Fair enough. 1 point to you.

My point on VirtualBox remains then - VB is NOT open and free as per the Richard Stallman view (and mine). 1 point to me !

Score : Even.

if Slackware has to consider a built-in hypervisor why Xen (and its project members) and not KVM (qemu)?

I would vote for KVM ... and all of QEMU (to emulate things), too.

Well, one could have both KVM and Xen. But I suspect that Xen has better performance than KVM. And Xen benefits from years spent under Citrix, where it acquired numerous powerful features. Like full snapshotting, live transfer to other hardware etc. Xen was only recently fully open-sourced by Citrix.

I've been using kvm for a few years but not xen. I'm always willing (though not so eager) to try xen to see the benefit from cpu paravirtualization.

that you can have also with lxc (I use it in production with Slackware since some years).

Yes, lxc is really a good thing! But very often I'm running different kernels (different versions of Linux, and even Windows) so I still need one of kvm and xen :-)

BTW: guys, which hypervisors are you using?
Till now I see VB, KVM, XEN. Any others?

Not exactly a hypervisor in the literal sense, but I also plan to use LXC (chroot on steroids) and plain chroot in addition to KVM and QEMU (emulating other CPUs).