Work Underway To Return Xen Support To Fedora 13

Julie188 writes "Details on this are admittedly sketchy, but both Red Hat and Xen.org have gone on record promising that some kind of support for the Xen hypervisor is forthcoming for Fedora users. As we know, on Monday, Fedora 13 was released, chock full of features to appeal to business users. One of the ballyhooed improvements to 13 is virtualization — meaning KVM and only KVM — for Red Hat. Xen was dropped from Fedora a few releases ago and it hasn't come back in 13, except that 13 still supports Xen guests. Meanwhile, 'work is underway in Xen.org to add platform support to Fedora 13 post-release,' promises Xen.org's Ian Pratt."

Comments

KVM catches Xen

[Pecisk]

As more new servers are deployed for virtualization, Xen superiority over KVM slowly, but surely disappears. First of all, all new tech has virtualization acceleration support in CPUs. Now, for example, using KVM in combination with paravirtualized network and storage drivers (which are packaged and used in Ubuntu as default), Ubuntu Server 10.04 LTS has the same speed and performance as guest as using Xen. Also huge improvements into libvirt stack and virt-manager have played role here - yes, I know, Xen also can use libvirt, but still - as it is more and more easier to deploy virtual machines, be it development or server environment. I have worked with Xen exclusively in the past for some three years, and most problems have been kernel patching issues and in fact, HVM support (because you still have to emulate some devices with quemu, which leaks like crazy, I guess that's reason why KVM now uses paravirtualized devices for net/storage). I don't have time to compile code for production servers, so if KVM is in kernel, and it is supported by kernel team and distribution, I will go for it. I was reserved And I guess lot of newcommers in virtualization will too.

In nutshell, Xen devs shoot in the foot here. Have they agreed to be included in main kernel three and be more welcome with patches, it would be more interesting competition here.

Re:KVM catches Xen

[hax0r_this]

I was responsible for maintaining a Xen environment for about a year and a half and had much the same experience. We compile our own kernels and in this regard Xen was a nightmare. Do I stick with a 2.6.18 kernel which is the latest supported? If we do that we have to make sure to get backported security fixes. Or do we use forward-ported Xen patchsets which weren't all that reliable and were a pain in the ass to apply?

We finally switched to KVM and suddenly life got a lot easier.

(Going slightly off topic here)For a while we used libvirt and the associated tools, then we discovered Ganeti, a project at Google which has made cluster management a breeze. Libvirt has a "network" driver, but really isn't designed to manage redundant virtualization clusters. Ganeti, on the other hand, is designed specifically for managing clusters, and takes care of all the dirty work like setting up and managing LVM and DRBD. You can build out a new virtual machine, complete with an operating system in just one command, or even do it over the HTTP API. You can use Ganeti with KVM or Xen, but until/unless Xen is in mainline I won't be touching it.

Re:KVM catches Xen

[Anonymous Coward]

I rolled out a small number of KVM virtual machines at a remote site (6000 miles remote), and looked at Ganeti to manage them. It looked good, but in practice it was designed for much larger clusters than we had, and in the end it just flat out didn't work. It also didn't help that KVM has apparently only been supported since Ganeti 2.0 was released and that the documentation is very Xen-centric.

After a little more research I became a little disappointed by the current state of virtualisation tools. They're either incredibly simple GUI's to qemu for manageing one or two Qemu disc images on your desktop machine or huge complex beasts like Ganeti that are so specialised to the original authors that they're almost impossible to fit into anywhere else. In the end I just wrote a few simple scripts that could be used to clone & manage KVM instances which were no more than a couple of tens of line of Bash each, and we called it done. Sure it isn't a large scale virtualisation platform (we use VSphere 4 for our core infrastructure) but it works.

Re:KVM catches Xen

[shallot]

In nutshell, Xen devs shoot in the foot here. Have they agreed to be included in main kernel three and be more welcome with patches, it would be more interesting competition here.

Why, yes, they have agreed to include their patches in the main kernel tree, but not all of them have the consent of the upstream kernel developers. The response of the Xen developers has been a significant refactoring of their code. Try reading the readily available documentation on the progress of merging Xen kernel patches upstream.

Re:KVM catches Xen

[pasikarkkainen]

Some comments.. Xen hypervisor (xen.gz) is not meant to be integrated to Linux kernel. Xen is designed to be a separate piece of software. Xen is a secure, type-1 baremetal hypervisor, not a module for Linux. Xen dom0 ("service console") can be Linux, NetBSD or OpenSolaris. Most people use Linux as Xen dom0. When Linux is used as dom0 it needs to be able to run as Xen dom0 (obviously) - and this is where some people have had pain. For a long time the official Xen dom0 kernel patches were only available for Linux 2.6.18. This was difficult for many people and caused some distros to drop Xen dom0 kernel support because they couldn't affort porting the patches to newer kernels themselves. Today the situation is different. Xen developers are actively working on rewriting the Xen dom0 patches based on the (already existing) upstream pvops framework. pvops has been in the upstream Linux kernel since 2.6.24. Xen pvops dom0 patches are available today for the long-term maintained 2.6.32 kernel, and also for 2.6.31, 2.6.33 and 2.6.34. Novell has also forward-ported the old/traditional Xenlinux patches from 2.6.18 to first 2.6.27 and also to 2.6.31, 2.6.32 and 2.6.33. So there are many options today. For more information about the various Xen dom0 kernels see: http://wiki.xensource.com/xenwiki/XenDom0Kernels Also xen.org offers XCP (Xen Cloud Platform) which is a full platform, including installation CD and multi-host/pool management. If you use XCP you don't need to install custom kernels or anything - you get all included in the XCP bundle. More information about XCP: http://www.xen.org/products/cloudxen.html

Re:KVM catches Xen

[0100010001010011]

Not every OS shuns Xen as a Dom0 like Linux seems to. I run Open Solaris this is what it took to get running:

pfexec pkg install xvm-gui
pfexec svcadm enable milestone/xvm
pfexec reboot

That's it. I wanted to use Linux. I read every single manual I could. There seemed to be 10 different ways to do the same thing and the documentation was never quite there. I could just never get it working the way I wanted to.

With virsh and virt-manager setting up another OS is cake. I'm running Debian64 as DomU and Windows7 under HVM.

Re:Hi

[Aeternitas827]

Protip: Look for the quotation marks, it's a quote, not added by the person publishing to the frontpage.

Xen needs to improve

[Alain Williams]

I liked the idea of Xen and tried to use it for some time, however:

• The (free) management tools were bad. If you wanted to do anything other than something quite simple, it was hard or impossible
• The documentation was hopeless: not complete; not enough examples; out of date

An exciting technology that I hoped to use, but just not up to the mark.

Re:Xen needs to improve

[pasikarkkainen]

This has changed pretty much lately. A lot of new documentation has been written to the wiki, for example: http://wiki.xensource.com/xenwiki/XenCommonProblems has a lot of stuff and links to other new documentation pages. Have you heard of XCP (Xen Cloud Platform, http://www.xen.org/products/cloudxen.html)? It's a full "Xen distribution" featuring install CD, including everything needed for multi-host/pool management. No need to install custom kernels or anything. You can use OpenXenCenter (http://www.openxencenter.com/) to manage it, if you need a GUI tool.

Where it belongs...

[Chris Snook]

Fedora, not RHEL, is really where Xen belongs anyway. It's exactly the sort of mix of neat ideas, dirty hacks, and blatant wheel re-invention that could only have come from academia, and it was only ever made enterprise-grade by throwing heaps of money at it, and even then only for carefully tested configurations. Yes, it's pretty much single-handedly responsible for commoditizing virtualization, but the combination of the design and the lack of cooperation with the kernel community made it a nightmare to support. Xen is responsible for the existence of KVM because it showed such immense promise, and then delivered extreme frustration and pain.

Since Xen decided long ago it was going to be the center of its own universe, it's really in a great position to do cool experimental things that the kernel community would be more cautious about and the enterprise market wouldn't touch with a 10' pole without seeing a strong proof of concept first. That kind of innovation is a stated goal of the Fedora project.

The only technical advantage Xen enjoys right now is a lack of dependency on hardware virtualization features. Since it's impossible to buy a new machine that you can call a server with a straight face that lacks hardware virtualization, this is meaningless in the enterprise world, but Fedora (like other community distros) has a much broader scope, so there's still a real chance there for necessity to give birth to more invention, much like it did in the early days of Xen when x86 hardware virtualization was still a whisper in the halls at Intel and AMD.

Of course, Xensource/Citrix has already driven away most of the community that would have done this kind of pre-product development, so I'm not holding my breath, but it would be nice to see something more to come of all that work (and years of my own life) beyond simply supporting existing users.

KVM is also compatible

[thule]

Plus, KVM has xenner that provides Xen compatible devices to virtual machines. I also saw some patches going into KVM that provide Hyper-V hypercalls to KVM. Right now they are fairly basic, but it is a start.

There is no doubt that KVM is the future. It is built into the kernel -- no dom0 patches required. RedHat is heavily investing in it. Note the sponsored oVirt project that integrates libvirt and FreeIPA to manage a network of virtual machine servers using kerberos and ldap as the security framework.

Re:KVM is also compatible

[thule]

I'm guessing the only reason KVM was slower was because it didn't have special virtual drivers. It does have block and network drivers now, but NO video drivers. Since KVM is more focused on server performance than graphics I have never had an issue with the graphics speed.

Re:Cool story bro

[mrclisdue]

Protip: Apparently, anyone can embiggen the English language, cromulently, whenever one wishes....

cheers,

Can someone explain the point of hypervisors?

[Viol8]

Seems to me they mostly get used to run multiple OS's that each run a single main app. Last time I looked modern OS's are quite capable of running multiple apps at the same time so unless you really need to run different OS's on the same machine (er why?) then what exactly is the point?

Re:Can someone explain the point of hypervisors?

[betterunixthanunix]

Here is a scenario for you: you have some old server that is going to be decommissioned, but it is running some important software, and perhaps a different operating system from all of your other servers. On the one hand, you can go ahead and configure a new system...or with virtualization, you can simply take a snapshot of the hard disk image and run a VM on some other server (perhaps one that is underutilized).

In general, the point of virtualization in a server room is flexibility. VMs are easy to move around, you do not have to be tied to a single operating system (I hear the most common use of KVM is to run Exchange on system with a Linux hyperviser) on a single physical machine, which is particularly useful for sharing hardware resources when you have to deal with software that only runs on a specific OS. VMs also make it easy to checkpoint a system; KVM has "copy on write" disk images, for example, which track changes from a base image, which could be a COW image itself.

IBM did a lot of research on virtualization use, and I believe they had discovered uses for using VMs within VMs up to four layers deep (I am not really sure what they were doing).

Re:Can someone explain the point of hypervisors?

[thePowerOfGrayskull]

It's harder to see when you're not at the enterprise level. Picturing being tasked with providing 10,000 identically configured desktop PCs that are intended to run a limited subset of applications in a locked-down manner.

You have two choices. You can use actual desktop computers -- power-hungry, subject to failure at that number, and generally expensive to maintain at that scale. Or you can use VMs - a fairly small number of physical servers. Your desktop component can be a simple thin client device -- cheap, power efficient, much lower likelihood of failure, and - when they do fail - much simpler to manage as it takes a few minutes to replace the physical device. Your user never knows the difference, as he still connects to the same VM. If someone screws up a VM, you just rebuild it - an automated process that takes a few seconds. Compared to a PC which can require someone to physically be present at the machine; and at the very least will take 10-20 minutes to copy down the hard drive image over a network.

Now let's say you're expanding - another 2000 users. With desktop PCs you have to order PCs -- hopefully no major changes in hardware since you last ordered, because then your client apps need to be re-certified. Then you have physically image the hard drives to the standard image; then deploy and set up the hardware at each workstation.

On the other hand, if you were using VMs you would add 20-40 servers to the cluster and bring the VMs online. The configuration is completely automated, with a human being required only to press "go". You still have to purchase the thin client devices, but even considering the new servers you bought, the cost is *far* less than buying 2000 PCs. Too, it doesn't matter if the specs change on the thin client devices, because their sole purpose is to connect to the VM. The ongoing cost remains much lower, and setup consists of plugging it in and flashing the ROM. (Though at that size, there's a fair chance you can work out a deal with the manufacturer to do it for you.)

As far as personal/desktop use - good for testing apps on different OSs, and playing with new OSs. Also good from a security perspective (run your web browsers in a VM, and questionable software. Roll it back daily or whenever you think there's been a compromise.) Also good if you're running Linux but have a couple of needed apps that don't work on WINE.

Re:Someday KVM may catch Xen

[Thundersnatch]

Is ESX so much faster than VirtualBox?

Yes, it is. At least it was in all of our internal testing, and every published benchmark I've ever seen.

In my experience VirtualBox beats VMWare in quite a few areas (though, sadly, not in networking). And the most recent version, 3.2, with fully asynchronous I/O widened the gap further. It's almost to the point that having virtualbox run a VM in a file on ext2 beats VMWare running the same VM with it's "partition filesystem" in normal setups.

Are you comparing VirtualBox with VMware Server or VMware Desktop? VMware ESX/vShpere are completely different products. VirtualBox may in fact out-run the lower-end, OS-hosted VMware Server and VMware Desktop. But in general, it won't come close to anything from the VMware ESX/vShpere product line (which is a hypervisor that runs on bare metal).

Re:Someday KVM may catch Xen

[Thundersnatch]

Actually ESX is a hypervisor that runs on an old redhat distro last time I checked. Given the featureset of the newer VMWare's it would amaze me if half of them (specifically the "new" hardware support) isn't just the result of a linux kernel upgrade.

No, the VMware ESX hypervisor runs on bare metal. The management console for ESX is based on an old RedHat, but that just talks with the Hypervisor via an API. In fact, the ESXi version doesn't even have the management console, and you use the VMware client to manage the hypervisor.

But I'd appreciate a few links with recent benchmarks if you have them.

I'll see what I can dig up, but comparing VirtualBox to ESX isn't frequently done because they're so different. I recall that I saw benchamrks comparing VirtualBox to VMware desktop, and then benchmarks comparing ESX to VMware Desktop, and did the transitive analysis.

Our internal tests threw out VirtualBox (and VMware Server) as options after very simlpe IOmeter benchmarks. They were both dog-slow compared with ESX.