[9fans] qemu, kvm, xen

[9fans] qemu, kvm, xen

[ron minnich]

I decided to try out the new kvm hypervisor. It is built into the
linux 2.6.20 kernel, and is far simpler to run and setup than xen. In
fact, it is quite nice: if you know how to run qemu, you know how to
run kvm: they have modified qemu so that you use the same command
line, tools, etc. If kvm is not present, qemu runs as always; if kvm
is present, the modified qemu starts up kvm with the target system as
a guest.

First problem I hit with kvm was an emulation problem, so you do need
to modify your plan9.ini to set
*norealmode=1
The far jump in again16bit causes kvm to crash and burn (look for the
"EA", etc. at the end of again16bit).

Well, never mind that, the numbers will show it does not (yet) really
matter. The test system here is a Thinkpad T60 with Core Duo (NOT Core
2). 1 GB memory. It's fast.

The plan 9 systems I booted were, for qemu and kvm, a terminal; and
for xen, a cpu server. I.e. the xen Plan 9 system is doing a bit more
work, as it starts up more servers, but does not start up rio.

boot:
qemu, 60 seconds
kvm, 100 seconds (yes, indeed, kvm did indeed boot more slowly than
plain old qemu)
xen, 6 seconds (it's nice)

build a pccpuf kernel:
qemu, 100 seconds
kvm, 80 seconds
xen, 12 seconds

So, the choice for speed is still xen. THX will remain xen-based for now.

thanks

ron

Re: [9fans] qemu, kvm, xen

[Anthony Sorace]

On 4/6/07, ron minnich <rminnich@gmail.com> wrote:
> THX will remain xen-based for now.

That's good, because otherwise you'd have to change the acronym, and
THK doesn't have nearly as interesting references (no offense to any
members of the Turkish Aeronautical Association intended).

Re: [9fans] qemu, kvm, xen

[Eric Van Hensbergen]

On 4/6/07, ron minnich <rminnich@gmail.com> wrote:
>
> boot:
> qemu, 60 seconds
> kvm, 100 seconds (yes, indeed, kvm did indeed boot more slowly than
> plain old qemu)
> xen, 6 seconds (it's nice)
>
> build a pccpuf kernel:
> qemu, 100 seconds
> kvm, 80 seconds
> xen, 12 seconds
>
> So, the choice for speed is still xen. THX will remain xen-based for now.
>

I/O is really going to suck with KVM right now -- after all, they are
using qemu for all their I/O emulation, so it makes sense that they
would be as slow.  The fact that boot is almost double qemu is kinda
crazy (is that qemu + kqemu, or vanilla qemu?) -- I mean I know they
are setting up some extra shit, but double the time is nuts.

kvm will catch up as soon as better paravirtualization interfaces are
integrated (particularly for I/O) -- this is why I wanted to push 9p
as the KVM paravirtualized I/O interface -- its clear they need to
close that gap.

         -eric

Re: [9fans] qemu, kvm, xen

[ron minnich]

On 4/6/07, Eric Van Hensbergen <ericvh@gmail.com> wrote:

> kvm will catch up as soon as better paravirtualization interfaces are
> integrated (particularly for I/O) -- this is why I wanted to push 9p
> as the KVM paravirtualized I/O interface -- its clear they need to
> close that gap.

I think this is correct. We will keep the THX name however when we
move to kvm, since it's much nicer.

This is a window in time, folks. Anyone who has time to work on
paravirt I/O for kvm that uses 9p could probably get somewhere with
the kvm guys, and avoid the problems of the xen I/O device interface.

I think, overall, given its much simpler setup, kvm is going to win in
the long term. It's in the kernel, it's a piece of cake to set up and
use, you don't need python, xml-rpc, and tons of config files. There
are almost fewer lines of code in kvm than there are files in xen. OK,
so I'm exaggerating, but not by much.

One thing I'm finding is that linux is a very tolerable device driver
layer for Plan 9. This T60, with Plan 9 as a guest OS, is a far better
Plan 9 platform than a T23 with Plan 9 native.

thanks

ron

Re: [9fans] qemu, kvm, xen

[Paweł Lasek]

On 4/6/07, ron minnich <rminnich@gmail.com> wrote:
[cut]

You can also use the current sources from kvm's website (I am
currently using kvm-16 w/ add-scsi patch). It's easy to setup unless
you have gcc >3.x _and_ 64-bit userland....

Also, compiling patched qemu with gcc newer than 3.x means you can run
only w/ kvm enabled.

> First problem I hit with kvm was an emulation problem, so you do need
> to modify your plan9.ini to set
> *norealmode=1
> The far jump in again16bit causes kvm to crash and burn (look for the
> "EA", etc. at the end of again16bit).

I never noticed that - I had troubles with march cd's 9pcf kernel, but
using an old one from ca 2005 solved the problem of hangup after
"running /bin/rc".

On the other hand, I use AMD's SVM instead of intel's VTx, and they do
differ in some places, as qemu needs to put most of real mode through
emulation.

[cut]

Unfortunately I haven;t had time to do any benchmarking. The only one
I could say I have performed is that after switching to SCSI I have
been able to sit through the whole installation process without
falling asleep...

> thanks
>
> ron
>

-- 
Paul Lasek