LWN: Comments on "Xen again"

Real world KVM

cdmiller — Wed, 10 Jun 2009 20:04:18 +0000

Yes, we looked closely at libvirt. At the time it was in transition as Qumranet was about to be bought by RedHat. When we first looked there was no support for live migration and it was out of sync with recent qemu's (changing CD's). We will probably be looking at libvirt again at some point.

No, it's completely unrelated.

tmassey — Wed, 10 Jun 2009 17:37:49 +0000

You say you have virtualized *disk* drivers for Windows for KVM? I'm aware of the paravirt network drivers, but I've looked repeatedly for block drivers. They've always been 'planned for the future', but I've not been able to find them.

Where would I get paravirt Windows drivers for KVM?

Let's step back a bit

paulj — Tue, 09 Jun 2009 07:50:31 +0000

Kqemu is long unmaintained. The Qemu developers are discussing ripping it out. Kqemu guest-kernel-space is very buggy and nearly always unuseable. So any deployment of Kqemu will run guest kernel under emulation, which obviously leads to very poor performance for all applications except those which are near-completely userspace CPU bound.

Let's step back a bit

xyzzy — Tue, 09 Jun 2009 02:11:48 +0000

I migrated my Xen DomUs to kqemu VMs a year ago. I didn't rigourously benchmark but the performance drop was noticeable -- I went from being able to fill 100mbps, to not being able to fill even half of it. And this was with wget and apache and static files, so mostly an I/O performance issue.

Let's step back a bit

djao — Sun, 07 Jun 2009 10:41:03 +0000

When I bought my laptop, January 2008, I shopped explicitly for one with virtualization capability. However, for a long time I just was not able to use it as such - Because of the lack of support in Xen for core features I want a laptop to support, such as ACPI

This is a fatal flaw in Xen, sure, but I don't understand why it would have stopped you from using KVM. You mention that you specifically bought a laptop with support for hardware virtualization, and KVM works fine with ACPI or any other core laptop feature, since KVM is just Linux.

I bought my laptop in April 2008 and I've been using it with KVM almost from day one. Everything works great, including ACPI.

Xen again

caitlinbestler — Thu, 04 Jun 2009 23:05:38 +0000

Actually Dom0 is not "the hypervisor portion of the Xen System", it is the hypervisor designated default owner of devices.

To be even more precise, Device Domains (or DomDs) are the owners of specific devices. Dom0 is the traditional and default DomD.

The separation of Device control from *the* hypervisor is one of the key strengths of the Xen architecture because it keeps the true Hypervisor (on which *all* other kernels rely) very stable. I suspect at least part of the opposition to "Xen Dom0" is not actually about "Dom0" but to the fact that the Xen Hypervisor is *not* Linux.

But focusing on what DomDs/Dom0 really requires the following pieces:

The actual/native device driver(s).
The "backend" drivers that support the Xen "frontend" drivers.
Glue to connect the backend drivers to the actual drivers.
The ability to configure that glue, preferably from user mode.

There is no particular reason why a Device backend has to be implemented in Linux. But Linux is particularly inviting for reasons #1,#3 and #4. Especially reason #1.

Understood, the "ABI" question is really a distraction. It is actually the Backend drivers that have stable ABIs, not Linux. The fact that Linux insists that kernel modules count as "Linux" is a Linux issue. People who develop those modules would really rather be free to follow their own coding standards, etc. Being GPL and following coding standards is reasonable, but having your module's interfaces being viewed as though they were Linux interfaces is a totally different issue.

So the real question is what kernel capabilities do backend modules truly need, and are these legitimate generic capabilities rather than Xen inflicting itself on the kernel?

Ultimately these relate to the ability to communicate with other Virtual Machines through shared memory and delegation of PCI functions and MSI-X interrupts. If you accept the concept that a non-Linux Hypervisor may partition a machine into physical machines, then is there any legitimate reason why mainline Linux should not be usable for Device controlling Domains?

Rejecting this application of Linux because Linux would rather also be the Hypervisor strikes me as taking your baseball home because the team wants somebody else to pitch. The true spirit of Open development would allow users to decide on Hypervisor versus Device Control separately rather than forcing them to lock the two decisions together.

Real world KVM

drag — Thu, 04 Jun 2009 21:29:12 +0000

I know it's not done for you right now.

But just since you brought up the subject of GUI tools and that sort of thing...

Rehdat is moving to KVM for the Redhat ES 5.4 release.

Redhat/Fedora vit-manager is working very very well with KVM on Fedora 11 beta.

http://libvirt.org/ is a library that is being developed that will provide a stable/unified API for people programming for Linux VM solutions. Not just KVM, but Xen, LXC (linux container system), OpenVZ, User mode linux, and Virtualbox.

Let's step back a bit

jimparis — Thu, 04 Jun 2009 21:28:27 +0000

But when you were purchasing a box 18 months ago, with a plan for a 5-year lifetime, wasn't it a huge mistake to overlook the hardware virtualization feature? I mean, KVM was merged into the kernel some 28 months ago.
I agree your situation sucks, but it seems more of a purchasing mistake than a reason to not move the world towards proper hardware virtualization.

Let's step back a bit

drag — Thu, 04 Jun 2009 20:29:44 +0000

the VT and SVM cpu extensions are only needed for X86 platform because the X68 ISA design is such a huge pile of shit.

KVM works fine on other architectures (like PowerPC), so that is all a bit of a red herring.

For x86 systems that donnot have VT/SVM you can use Kqemu and get similar functionality and speed.

No, it's completely unrelated.

drag — Thu, 04 Jun 2009 20:20:34 +0000

For sshfs if you want to have good performance you need to disable compression. If you think the crypto has to much overhead then change the encryption method to RC4.

Very likely you were running something like 3DES that has very high overhead. And like I said you need to have a relatively recent version of OpenSSH (say a version from the past 2 years or so) for reliable service.

You can set these on a per server basis in your ~/.ssh/config

I have had no problem personally beating NFS when it comes to my personal usage at home over wireless and gigabit link.. although of course this sort of thing is not suitable for large numbers of users.

No, it's completely unrelated.

bronson — Thu, 04 Jun 2009 19:32:23 +0000

Tried sshfs 5 or so years ago, rejected it because the crypto overhead prevented me from filling a 100 MBit link. I should probably try it again since that won't be a problem nowadays.

I only mentioned DRBD to illustrate how desperate I've become! It was actually pretty good except that I couldn't get the split brain recovery to work the way I wanted. So close and yet so far. Haven't gotten desperate enough to try AFS yet!

Why doesn't 9p or webdav or some simple protocol take off? It's amazing to me that NFS and CIFS are still state of the art. I guess I don't understand the trade-offs very well.

Let's step back a bit

buchanmilne — Thu, 04 Jun 2009 17:44:28 +0000

<blockquote>Hardware virt support is in just about every new x86-64 processor that comes out.</blockquote>

But, an 18-month-old 16-core (8*"Dual Core AMD Opteron(tm) Processor 885") server (Sun X4600-M1) doesn't have it. With another 5 years of lifetime on these boxes, it really would be nice to keep Xen (which is what they are currently running). There's no way I would migrate this (with heavily utilised VMs) to qemu-kvm ...

Real world KVM

cdmiller — Thu, 04 Jun 2009 15:47:45 +0000

Huh,

We have been using KVM for core servers for ~10 months now. We have ~25 Windows and Linux server VM's on our production cluster of 2 test and 4 production hardware servers (~$3000 each). We even run MSSQL on KVM. Shared storage is on NFS from a couple of DRBD'd storage servers.

When we tested the commercial Citrix Xen offering it could not create a Mandriva or Ubuntu server for us. We have found it much easier to roll VM's with KVM than with Xen. Using a wrapper script and some debconf with Ubuntu's VM builder we can spit out new, updated, Ubuntu server VM's in about 5 minutes custom configured for our environment.

Live migration was far superior for KVM than with VMWare when we tested last summer. KVM allows live migration over SSH (used to be the default mechanism). We see a couple of pings (2 to 5 packets) with increased latency during the infamous migration ping test, compare that to VMWare. We didn't test vs Xen due to the VM creation problem above.

The KVM GUI tools were lacking but were easily overcome with a minimal Perl driven CGI. We even get console in the web browser with a Java VNC applet.

In our study, we eliminated HyperV and Xen early on and it became a contest between VMWare and KVM. KVM won out despite some shortcomings in GUI tools and commercial support. The fact that a VMWare update had a critical bug last summer during our testing influenced our results a bit.

Let's step back a bit

TomMD — Thu, 04 Jun 2009 15:42:48 +0000

> Virtualization does not only work at the server farm, it can also be very useful at desktops.

YES! And its not just for x86 anymore, but there are architectures that don't have VT or SVM hackery and are perfectly viable users of Xen. I'd love to run Xen on the (ARM based) beagle board or a BB based laptop.

No, it's completely unrelated.

sbergman27 — Thu, 04 Jun 2009 14:08:28 +0000

My understanding is that the main thrust of the the 9p virtio stuff is to implement shared volumes without all the ugly network guts being exposed to the administrator. And hopefully, at lower latency than the rather significant local latencies one sees even using a virtio network driver.

I have an ugly situation where I have a (proprietary) cobol C/ISAM <-> SQL gateway to some cobol accounting files. Due to the brain-deadness of the proprietary vendor (political concerns, their licenscing with their Cobol runtime supplier, yadda, yadda, yadda...), I have to run it virtualized in an old distro and it sees the C/ISAM files via NFS4. It's written to do a lot of fsync'ing and doesn't seem to make any use of any sort of NFS caching, and so latency absolutely kills its performance. I can't use any of the virtio stuff because the guest kernel is too old to support it, and even that has latencies in the hundreds of microseconds. So I'm using the software emulated E1000 driver, which is almost as efficient as virtio.

However, if I could use the 9p shared volume stuff, I suspect, but am not sure, that latency would be much improved. As it stands, it is still over twice as fast as running on a separate machine via NFS4 over 1000baseT.

So far as I know, the 9p-virtio thing is still an active project, but not yet in mainline KVM. Or, at least, it does not seem to be in Ubuntu 9.04 server.

Xen is not user-space

dunlapg — Thu, 04 Jun 2009 13:32:17 +0000

-- Begin Quote --
If they are two packages, and Linux breaks the interface between kernel and hypervisor, then the fix would be to redesign the Linux change to cope with keeping the same ABI to the hypervisor. This is a burden that the maintainers do not want to carry.
-- End Quote --

That's an understandable concern. But Keir Fraser has unequivocally stated that he does not expect that. It's Xen's job to be backwards compatible with older kernels if it wants to be. It's not Linux's job to be backwards compatible with older hypervisors. If the ABI changes in Linux, Xen will upgrade to match; and if someone upgrades Linux over a dom0<->xen ABI change, then they will have to upgrade Xen over that same ABI change as well.

Let's step back a bit

ESRI — Thu, 04 Jun 2009 13:28:08 +0000

I know we have a LOT of Dell PE 2850's and newer still with a lot of life and horsepower in them... perfect for running Xen, but not at all good for running KVM.

Xen is not user-space

nevets — Thu, 04 Jun 2009 13:19:45 +0000

> The feeling that dom0 changes add a ton of ugly "hooks", but don't make the Linux code base any better. Since the Xen hypervisor functionality is outside of Linux, having cool functionality in Xen doesn't really count as improving Linux. But if a hypervisor component were in the kernel, rather than a separate projec,t then the kernel as a whole would seem to benefit. (This is a bit of a subtle one to understand; it depends on drawing a boundary and saying, "If it's inside this tree, it contributes to making Linux cool, and may be worth the cost of the hooks. But if it's outside the tree, it doesn't contribute to making Linux cool, so the hooks are a cost without a benefit.")

This is a very important point. I would look at as, if it is in the kernel, it means Linux and Xen are packaged together. If it is out of the kernel, then Xen and Linux are too separate packages.

This is a key point. If they are as one package, and a change in Linux breaks the interface between kernel and hypervisor, the fix would be to update the hypervisor to handle the new change.

If they are two packages, and Linux breaks the interface between kernel and hypervisor, then the fix would be to redesign the Linux change to cope with keeping the same ABI to the hypervisor. This is a burden that the maintainers do not want to carry.

Having the two as one package would mean if you upgrade one, you also upgrade the other. A subtle point indeed, but an important one.

Let's step back a bit

gwolf — Thu, 04 Jun 2009 12:56:37 +0000

> How many of these 500,000 servers running Xen can't run KVM? And aren't those on a schedule to be retired, for other reasons (e.g. power consumption, increasing failure rate, etc.) soon?

When I bought my laptop, January 2008, I shopped explicitly for one with virtualization capability. However, for a long time I just was not able to use it as such - Because of the lack of support in Xen for core features I want a laptop to support, such as ACPI (which is mainly useful for laptops, granted, but that could be very well used everywhere, leading to sensible power savings). Virtualization does not only work at the server farm, it can also be very useful at desktops.

No, it's completely unrelated.

gwolf — Thu, 04 Jun 2009 12:48:03 +0000

> Heh. KVM has paravirt drivers that are built into the kernel right now.

Yes, and that's good - I use KVM with paravirt network and disk devices for Windows hosts. Still, many things (i.e. memory access, real CPU mapping, even the kind of architecture the guests report as having) have to be emulated. Paravirt devices are a great boost, though - And by being much simpler, say, than hardware-specific drivers, I am also reducing the most common cause for Windows' instability.

Now, both with Xen and with KVM (and I'd expect with any other virtualization technology) you can forward a real device - Just remove support for it on the host (or Dom0) kernel and ask the virtualizer to forward the needed interrupts/mapped memory space/bus address, and you have it natively inside. Of course, you lose the ability to perform live migrations - But you cannot always win! :)

No, it's completely unrelated.

drag — Thu, 04 Jun 2009 12:20:49 +0000

Yes.

You need to have Intel or AMD's virtualization support to take advantage of KVM.

Even with the virtualization support KVM will be slower then PV. Xen's PV is very superior in terms of performance in almost all situations.

KVM's advantages over Xen are:

* Cleaner design. I am guessing that KVM hypervisor code is between 20k-30k with all the arch it supports were Xen's hypervisor code is easily 10x that much.

* Much easier to administrate and deal with. Does not require patches, does not require rebooting or anything of that nature. It's "just there". Does not require special console software or management tools beyond just qemu if that is all you want. You can use top to monitor VMs and crtl-z to pause them if you started them from a terminal, for example.

* Does not require to have your OS "lifted" into a Dom0... The way Linux interacts with the hardware does not change. This means (with latest kernels) I can suspend my laptop while running VMs and it just works.

* Heavily leverage's Linux's existing features. Instead of having to write various peices of hardware support into the hypervisor KVM gets all that and more by default. When Linux does improvements to, say, memory management then people using KVM directly benefit from that work.
(this is not a huge advantage over Xen, its more of a big improvement when compared to Vmware ESX.. no restrictions to hardware, network block protocols, or sata or anything like that... if Linux supports it you can use it in KVM)

* It is already installed and setup on your machine. All you have to do is intall the qmeu portion and the virt-manager or libvirt stuff if you want to have a nice and easy way to manage them. All Linux distributions have KVM support.. it's modules are by default by everything I've looked at.

disadvantages:

* PV on Xen is still easily performance king.

* require some hardware support.

Let's step back a bit

nye — Thu, 04 Jun 2009 12:18:46 +0000

While I mostly agree, there are still a number of new mainstream CPUs which don't support hardware virtualisation, mostly aimed at the budget or mobile market. I know if I could use KVM on this laptop it would make my life a little easier. I've never used Xen so I don't know if it would be worth the effort for my purposes, but I'd be a lot more likely to try if it were in the kernel already.

Xen is not user-space

dunlapg — Thu, 04 Jun 2009 12:11:02 +0000

There seems to be a slight confusion in the article, where twice it refers to Xen as "user-space". In kernel terms, "user-space" has a technical definition: running in processor ring 3. In fact, Xen runs in ring 0, and when Linux runs as a domU or dom0 on Xen, it runs in ring 1.

Someone in the lkml discussion said that Xen wasn't an operating system, which was quickly refuted: the core job of an OS is to manage the sharing of resources, specifically memory and cpu time. Sharing memory and cpu time between multiple VMs specifically what Xen does, delegating the sharing of almost all other resources (disk, network, &c) to dom0 or driver domains. This makes Xen very akin to a micro-kernel. (Xen proponents have acknowledged this similarity, and said that Xen is "a microkernel done right".)

So when the article says "it seems unlikely that something as large as Xen would be the first user-space component to break through that barrier", something is confused. Xen isn't a user-space component. If Xen were to be merged in (or an in-kernel hypervisor project started), it would run in ring 0 and include memory and processor scheduling algorithms, just as Linux currently does, but targeted towards sharing between VMs, as opposed to processes.

The reason this is being discussed in the first place is that some people (myself included) don't believe that the same code can work well both as a kernel and as a hypervisor. This includes all aspects of the hypervisor, but specifically scheduler can work well both as a scheduler of processes and a scheduler of VMs. KVM currently runs VMs as processes, with Linux as the de-facto hypervisor. So a VM running under KVM gets a processor scheduler rather than a VM scheduler. Maybe the Linux scheduler could be made to do both, but the Xen community thinks it's better to have a dedicated VM scheduler, as well as other dedicated VM-oriented algorithms.

Having this code in the kernel would address two issues:
* The fear that Linux will be stuck with supporting a very invasive ABI. If the hypervisor is in the kernel tree, it would be a lot easier to tie them together.
* The feeling that dom0 changes add a ton of ugly "hooks", but don't make the Linux code base any better. Since the Xen hypervisor functionality is outside of Linux, having cool functionality in Xen doesn't really count as improving Linux. But if a hypervisor component were in the kernel, rather than a separate projec,t then the kernel as a whole would seem to benefit. (This is a bit of a subtle one to understand; it depends on drawing a boundary and saying, "If it's inside this tree, it contributes to making Linux cool, and may be worth the cost of the hooks. But if it's outside the tree, it doesn't contribute to making Linux cool, so the hooks are a cost without a benefit.")

Whether it's practical to do a merge with Xen specifically, is another quesiton. :-)

No, it's completely unrelated.

drag — Thu, 04 Jun 2009 12:03:58 +0000

No clue about plan9.

But DRBD is a way of keeping volumes in sync, not so much a file system.

The easiest FS to administer that I know of is sshfs. I use it heavily and it is stable and actually very fast. It can beat NFS even sometimes.. And all you need is Openssh server running and a fuse support in the client. The ssh server is the real gauge on how well sshfs works. Anything other then a relatively recent version of OpenSSH and I doubt the results will be that good.

But if DRBD was even being considured then your needs are going to be specialized. Other alternative to look at could possibly be Redhat's GNBD from GFS or ISCSI.

Let's step back a bit

rwmj — Thu, 04 Jun 2009 08:43:40 +0000

s/Bruce/nevets/ ...

Let's step back a bit

rwmj — Thu, 04 Jun 2009 08:42:43 +0000

Bruce, this is an interesting and valid point, but it's also a bit like the discussion of 3D rendering that happened in the mid 90s. Sure, 3D graphics cards were rare and expensive at first, and that meant there was a place for software rendering.

Nowadays though no serious 3D program (ie. no game!) comes with a software renderer, because the 3D hardware is everywhere, on motherboards, in open handhelds like the GP2x-Wiz, and even in experimental boards like the ARM-based Beagleboard.

Hardware virt support is in just about every new x86-64 processor that comes out. A few 32 bit netbooks don't have it right now, but it'll come to those too.

Also don't overlook the fact that KVM does have software emulation. OK, it's slow, it's in userspace, and it relies on qemu. Nevertheless, just running qemu-kvm will transparently fall back to software emulation if the hardware doesn't support virtualization.

Rich.

Let's step back a bit

sf_alpha — Thu, 04 Jun 2009 07:45:32 +0000

It isn't true that KVM does not have Dom0. But it reside in different layer, put the fact that both KVM and Xen -- Dom0 is privileged and handle device drivers + hardware, weather is in top or bottom of virtualization later.

For Xen, Xen Hypervisor is a controller too grant access Real hardware/cpus, but Dom0 is virtually both HW driver and admin system.

For KVM, It is application + kernel part too grant access Real hardware/cpus (using processor assisted), but system running KVM is both HW driver and admin system.

In both cases, if parent or dom0 cracked, whole system is compromised.

I agree that if Xen code is too much impact on x86 core arch code it should not merge until this fixes, but again KVM is not Xen replacement at all. Even with xenner which is really KVM but Xen guest.

I can say that Xen lacks support from its users. If Xen shipped in kernel it would heavily tested. But now it's not, even Xen currently keep track latest kernel inside git, most people seems to use stable and old Xen kernel and not many are working on new Xen Dom0 kernel.

And again, KVM is not thing that would replace Xen and not replace each other. I cannot see any benefits for replace Xen with KVM for now (I running a couple servers using Xen, some of those not support VT-d or AMD-V).

Topics of this problem is that Xen cause too much changes of the core x86 code and seems not to clean enough.

No, it's completely unrelated.

bronson — Thu, 04 Jun 2009 07:06:40 +0000

> 9pnet_virtio

Wow, people are still writing 9p code? Given the sad state of http://sourceforge.net/projects/v9fs and http://sourceforge.net/projects/npfs I thought that these projects were stone dead.

I'd really like a network filesystem that is easier to administer than NFS and CIFS... Tried DRBD but didn't like it much. Is v9fs worth a look?

No, it's completely unrelated.

sf_alpha — Thu, 04 Jun 2009 07:03:25 +0000

If KVM + virtio still need processor support it would be very slow compared to Xen when running on unsupported processor.

Let's step back a bit

ras — Thu, 04 Jun 2009 06:49:37 +0000

It may well be exactly what I want. Thanks.

Let's step back a bit

jamesh — Thu, 04 Jun 2009 06:34:25 +0000

An earlier post linked to http://kraxel.fedorapeople.org/xenner/. Can you use that to run the guest images from your provider?

Let's step back a bit

drag — Thu, 04 Jun 2009 06:28:54 +0000

> 1) critical hypervisor code is small, so more easily ported and audited

Ya.. it starts up like that. But it rarely stays like that.

In the case of Xen I think your looking at about 300-400K lines of code in a full-featured version.

In the case of KVM the initial patch was about 12K loc and was accepted almost immediately into the kernel code. (quite a achievement)

Let's step back a bit

drag — Thu, 04 Jun 2009 02:34:55 +0000

> I believe that a paravirtualized guest runs much faster than a qemu guest. But I have not taken any benchmarks.

YES PV is massively faster then just plain Qemu. Massively faster in all respects. The overhead of Xen PV vs naked hardware is going to be just a few percent.

Of course this requires modification to the guest.

Xen again

jengelh — Thu, 04 Jun 2009 02:10:17 +0000

>But ... KVM is not thing for replace XEN. At least, KVM require processor support to work.

But the effort to get Xen run these days is, compared to less-paraful HVs like Vbox/Vmware/etc., high, from here's standpoint POV. Even UML requires less work ;)

No, it's completely unrelated.

drag — Thu, 04 Jun 2009 01:59:26 +0000

> My favorite way out for most of the cases I would be forced to handle with Xen for this kind of needs is to use vserver - Which is _not_ formally a virtualization technology, but a compartmentalization/isolation technology (akin to what was introduced as the BSD Jails around 2000), where many almost-independent hosts share a single kernel, but live within different security contexts.

Well things like BSD Jails, Vserver, OpenVZ, etc etc. All of these are very much virtualization technology in a very real sense. They just are not hardware virtualization.

> Why do you want to paravirtualize? Because the performance impact is way lower. You don't have to emulate hardware at all - In a regular virtualization setup, the guest OS will still shuffle bits around to give them to, say, the ATA I/O interface, possibly aligning them to cylinder/head/sector - On a hard disk that just does not exist, that is a file on another filesystem or whatever. When it is paravirtualized, the guest OS just signals the host OS to do its magic.

Heh. KVM has paravirt drivers that are built into the kernel right now.

virtio-blk = block driver
virtio-rng = random number generator
virtio-net = ethernet network driver
virtio-balloon = used for reclaiming memory from VMs
virtio-pci = pci driver
9pnet_virtio = plan9 networking

And that works fine with updated versions of Qemu also. So you should be able to take advantage of them if your using Kqemu + Qemu for your virtualization. I think. But virtio is a standardized way of doing things. Should probably work with Qemu-dm for Xen stuff.

I there are windows drivers for virtio network. I am not sure about virtio block or balloon though...

I don't know how well KVM + Virtio compares to Xen PV..

Then on top of that you can use AMD's IOMMU or Intel's VT-d to map real hardware directly to virtualized hosts, which would be the fastest possible since your handing off direct access to the hardware.

Let's step back a bit

ras — Thu, 04 Jun 2009 01:51:26 +0000

ncm: Is it that a KVM Xen can't run your paravirtualized image?

Firstly, beware I am trying to do this as we speak. I've tried things. Some of them didn't work. But maybe it is just because I don't have a clue.

There are two issues here. One is I don't seem to get a choice as to what DomU I am running. The VM hosting provide couple and I choose one. If I want to work on it locally, I image it and have a fiddle. The essential point being, I can't choose one that suits KVM. On the other hand, if there is some magic way I can make any image run fine under KVM, and back again 100% reliably then I am mostly satisfied. Right now I haven't found that way. As I said, this is possibly because I need a clue.

Secondly, I would like to use the same tools for managing the DomU the hosting provider does - it just makes it so much easier to understand what is going on. In other words, I want to run the xen tools in a Linux Dom0. This is very much a secondary consideration for me though. It is possibly more important from the Xen world domination point of view as you want to make it as easy as possible for the hosting providers, and right now they have to be very picky about what they use as their Dom0.

Currently I can use Linux 2.6.26 as my Dom0. Sadly a big chunk of my peripherals aren't supported by 2.6.26. In fact some aren't stable under 2.6.29 (wireless causes the machine to freeze if I use it heavily), so right now I am eagerly awaiting each new kernel release. But porting the Xen patches to each and every kernel release is simply too much work.

Let's step back a bit

ncm — Thu, 04 Jun 2009 01:23:24 +0000

This is a very interesting and persuasive view. I wonder, though: if Xen can be hosted on KVM, then the ultimate choice doesn't affect you, does it? You can run your Xen image on an old Xen or a new Xen, and not notice the difference. Where am I confused? Is it that a KVM Xen can't run your paravirtualized image?

Let's step back a bit

ras — Thu, 04 Jun 2009 01:05:42 +0000

I am just exploring the implications of this issue myself.

When I going out and try to buy CPU cycles, the most attractive way to do it right now is a Xen VM. There are other options - shared hosting, VMware and probably others. All have warts compared to a Xen VM. It is really nice to be able to configure and debug my VM on my laptop, then send it to the hosting provider. So that is point 1: unlike KVM or any other solution described here, Xen is out there, in the real world. Because KVM isn't, it is in a practical sense unless for one of the major applications of VM's - cloud computing.

Point 2 is that many of those Xen images out there are para-virtualised for speed, so I can't use KVM to develop them.

Point 3 is I want to run the latest Linux kernel as my Dom0 - principally because nothing else seems to work on modern hardware. Applying the Xen patches myself is an absolute PITA.

The end result is not having Xen is making Linux hard to use in an emerging platform - cloud computing. I don't doubt there are real issues - the fact that Xen uses the Dom0 to talk to the hardware sounds to me like it has the makings of a real ugly patch. However Xen isn't a webcam that can be ignored. Xen is an entire platform - like Windows or Linux. And it is an open source solution locked in battle with closed alternatives. I want it to win - after all I could just use VMware. If Xen doesn't win, possibly no open source solution will. KVM is not even a player in this space.

Xen again: which ABI

mjg59 — Wed, 03 Jun 2009 23:39:06 +0000

That's not the case. We've broken the Linux <-> BIOS interface several times in ACPI, though admittedly every time it's been to make ourselves look more like Windows.

Let's step back a bit

nevets — Wed, 03 Jun 2009 23:01:32 +0000

I believe that a paravirtualized guest runs much faster than a qemu guest. But I have not taken any benchmarks.

I also think the issue is that Xen is still quite a head of KVM in features, but this too is slowing down.