I am delighted, that we have a nice discussion about the topic!
Basically, this was motivated because we are not doing too much progress in IPFire 3 right now. Since October, we barely had time to work it and so we need to cut out things that are not widely used to get IPFire 3 done at some point.
In my (very personal) opinion, Xen is shit. It has ever been and probably will ever be. Bringing all that into a distribution is impossible - even the big distributions are struggling with that as Xen is poorly supported, buggy and nobody takes care about it.
Support for Xen guests (that means IPFire is running as a guest on a Xen system) comes for free, because finally a lot of the requirements have been merged into the Linux kernel. We won't have to do anything else on the user-space level to get this done. No major work at least. Maybe fighting the bugs...
Running it the other way round (IPFire is the virtualization host and some virtual machines are running on it) is much more complicated. It's not that compiling the tools is the main problem, it's rather fighting the bugs. Xen often breaks things like working with libvirt and stuff like that, so this is not going to be fun. Ben volunteered to do this work in IPFire, but together we decided that the use case for this is not worth doing all that work.
We are happy if there is someone who wants to dig into the problems and solve them. Frankly, this is a 40 hours a week job. Half of it is doing the work, the rest is crying because of the things you will find in the Xen code.
Despite that, we are planning to have KVM, so you can run virtual machines on a system that comes with the virtualization extensions in the CPU. KVM is much cleaner, faster and less work from a package maintainer's point of view.
The essential VMware and Hyper-V kernel modules have been merged into the Linux kernel a while ago, so running IPFire (2 and 3) on these hypervisors should be working perfectly.
-Michael