|
|
Log in / Subscribe / Register

Virtualization in Linux: A Review of Four Software Choices (Techthrob.com)

[Posted February 11, 2008 by jake]

Techthrob.com takes a look at virtualization choices for Linux. "This article looked at four different products for virtualization in Linux, specifically Ubuntu Linux. The findings were interesting - the only product that requires the purchase of a licence for personal use, Parallels, actually performed the worst of the group. Qemu did well for a completely free-as-in-speech application, although VMware and VirtualBox blew the competition away in terms of performance."
to post comments

What's the future of Xen in mainline?

Posted Feb 11, 2008 21:46 UTC (Mon) by dhess (guest, #7827) [Link] (7 responses)

I used kvm on an Opteron server running Ubuntu Gutsy with 2 virtual machines for about 3 months with no problems, but when I added a 3rd VM, the kernel began to panic with an unhandled page fault on an almost daily basis. The panics appeared to coincide with heavy CPU load on the 3rd VM. I tried the latest vanilla kernel (2.6.24 at the time, I think) but got the same results as with the Ubuntu 2.6.22 kernel. I switched to the Ubuntu Xen kernel, rebuilt all my VMs as Xen domU's, and the machine has been up ever since, happily running 4 domU's now.

Regardless of any kernel bugs, the free software tools people have built around Xen (e.g., xen-tools) and the fantastic xm command made it worth the switch. kvm's choice of QEMU as a platform hampers its use on servers. QEMU appears to target the desktop virtualization crowd, which is fine, of course, but it's not well-suited for remote/headless work. I could never get the serial consoles on my kvm guests to work reliably, and I had to use GNU screen to manage the guests, since QEMU doesn't include the ability to attach/detach a session as xm does. The libvirt project may resolve this in time, but currently it doesn't work particularly well with QEMU, in my experience; for example, I couldn't get the serial console to work at all with virsh and friends.

My main concern with Xen is its future. Debian and Fedora appear to have frozen upstream integration while Xen is ported to paravirt-ops, which sounds like the right move given Citrix's acquisition of XenSource, but does anyone here know how that work is going, and when we'll be able to build Xen kernels from the mainline Linux kernel?

What's the future of Xen in mainline?

Posted Feb 12, 2008 0:00 UTC (Tue) by larryr (guest, #4030) [Link] (2 responses)

had to use GNU screen to manage the guests, since QEMU doesn't include the ability to attach/detach a session

It sort of does, via the -vnc option, which uses a VNC server as the console.

Larry@Riedel.org

What's the future of Xen in mainline?

Posted Feb 12, 2008 21:58 UTC (Tue) by dhess (guest, #7827) [Link] (1 responses)

Sorry, you're right. I should have said that it doesn't include the ability to attach/detach a text-only session. Running VNC over SSH to a remote host to get console access is not much fun.

What's the future of Xen in mainline?

Posted Feb 14, 2008 3:59 UTC (Thu) by danpb (subscriber, #4831) [Link] 

Indeed we've not hooked up the text based serial console in QEMU to 'virsh console' yet. It
has long been on the TODO list, but never quite made it to the top... VNC is the most common
access method for graphical console, or just SSH into the guest for text mode.

What's the future of Xen in mainline?

Posted Feb 12, 2008 5:22 UTC (Tue) by monty (guest, #48098) [Link] 

My sister runs an internet cafe , for her i had put up zersohell and ipcop using qemu on a
single machine . That machine is without monitor , she only need to switch on the machine and
can follow the status of vm's remotely using vnc (only if required) and can manage zeroshell
and ipcop through web interface. Good thing about qemu is that it can use linux native network
tools like bridge-utils , this way one can create sophisticated virtual network environment
using qemu.

dunno, OpenVZ is fine for me

Posted Feb 12, 2008 21:58 UTC (Tue) by gvy (guest, #11981) [Link] 

I run a modest number of OpenVZ kernels with some couple dozen VPS on all of them (half of
these runs on one dualcore, 4Gb system).  Just works, and handles added load quite well.

It's ALT Linux 4.0 Server (which integrates OpenVZ support out-of-box).

What's the future of Xen in mainline?

Posted Feb 14, 2008 4:02 UTC (Thu) by danpb (subscriber, #4831) [Link] (1 responses) 

You can get updates on the progress of the Xen paravirt ops work on the Fedora wiki, since
we're targetting Fedora 9:

http://fedoraproject.org/wiki/Features/XenPvops

And frequent postings to the xen-devel mailing list

http://lists.xensource.com/archives/html/xen-devel/2008-0...

Short summary,  i386, Dom0 and DomU both work on pvops + 2.6.24 and we can spawn guests.
x86_64 DomU is very close to being usable. 

Stephen publishes his GIT repo with the work

http://git.et.redhat.com/?p=linux-2.6-dom0-pvops.git;a=su...

What's the future of Xen in mainline?

Posted Feb 15, 2008 4:34 UTC (Fri) by dhess (guest, #7827) [Link]

That's great, thanks for the updates and the links!

Virtualization in Linux: A Review of Four Software Choices (Techthrob.com)

Posted Feb 12, 2008 9:14 UTC (Tue) by rvfh (guest, #31018) [Link] (7 responses) 

If he wants the KVM module's acceleration, doesn't he need to run the KVM-optimised version of
Qemu, also named KVM??? That would explain why Qemu was slow: no acceleration.

Virtualization in Linux: A Review of Four Software Choices (Techthrob.com)

Posted Feb 12, 2008 13:06 UTC (Tue) by Felix_the_Mac (guest, #32242) [Link] (6 responses) 


I have checked with the reviewer and the machine he was testing on does not have VT. Therefore
this is not a review of KVM speed.

No VT? No fair to *any* of the platforms reviewed.

Posted Feb 13, 2008 1:54 UTC (Wed) by xoddam (subscriber, #2322) [Link] (5 responses) 

... and for the same reason not a reflection of the performance of *any* of the virtualisation
environments on a VT-capable processor.  Performance of *all* of them is likely to be better
with fully-virtualised hardware than with paravirtualisation that traps everywhere.

Mind you, there are still a lot of non-VT processors out there, so these 'gut feeling'
performance benchmarks are of some use to those of us still running them.

No VT? No fair to *any* of the platforms reviewed.

Posted Feb 14, 2008 3:38 UTC (Thu) by walken (subscriber, #7089) [Link] (3 responses) 

Full disclosure: I'm a VMware employee.

VMware would not use VT even if the box supported it, because current VT hardware is slower
than the emulation techniques we can do in software.

VT holds some promise of getting faster in future CPU generations, and it does make things
simpler if you don't already have the software emulation techniques implemented, but it is not
a silver bullet as of today...

No VT? No fair to *any* of the platforms reviewed.

Posted Feb 14, 2008 4:06 UTC (Thu) by xoddam (subscriber, #2322) [Link] (1 responses) 

> current VT hardware is slower than the emulation techniques we can do in software.

I'm intrigued (though not *quite* incredulous).

... I suppose that's not the sort of comment your employer would encourage you to elaborate
upon in a public forum, though?

I would have thought the best you could do in a generic way would be to trap, though I suppose
numerous specific performance optimisations are applicable if you're intimate with your
various guest OSes.

No VT? No fair to *any* of the platforms reviewed.

Posted Feb 14, 2008 8:37 UTC (Thu) by walken (subscriber, #7089) [Link] 

Well I can't tell *all* about the secret sauce but the main ingredients are already known...
See http://portal.acm.org/citation.cfm?id=1168857.1168860 for example for a relevant published
paper.

VMware can use binary translation - a technique that is actually quite similar to what qemu or
many java JIT environments are doing. It's complex but surprisingly inexpensive if you do it
right. Since we don't directly execute the guest kernel code but rather a translation of it,
we have an amount of flexibility not available in hardware - if we find out that our
translation for something traps too much, we can look at it and figure out an alternative
translation that will trap less.

The first generation VT hardware, on the other hand, is actually quite limited, it provides
all the traps you need to write a trap-based virtualization monitor, but in the end you still
have to handle all these traps. Most notably the page table virtualization is left out as an
exercise to the monitor implementor - this ends up being a lot of traps and with not much one
can do about them other than waiting for future generations of VT hardware.

Don't get me wrong though, hardware virtualization *will* get faster eventually... it just
takes a while though, due to cpu design cycles being longer than software design cycles :)

No VT? No fair to *any* of the platforms reviewed.

Posted Feb 14, 2008 15:35 UTC (Thu) by sg7jimr (guest, #22837) [Link] 

This statement about VMWare not using VT is not completely accurate.  In order to have 64 bit
virtual machines an Intel processor must have VT extensions for VMWare to allow it to run.
That implies that VMWare does in fact make use of VT to some extent.  It was not only necessary
for the processor to support VT but those extensions had to be enabled in the BIOS, so it
seems a real dependency and not some marketing thing.

No VT? No fair to *any* of the platforms reviewed.

Posted Feb 14, 2008 14:58 UTC (Thu) by danpb (subscriber, #4831) [Link] 

The first generation of VT enabled hardware is not really focused on performance - it is more
about enablement - ie it allows you to run unmodified guests, with the minimal software
tricks. There are many ways to virtualize without hardware support and many of them will
outperform current VT hardware. eg paravirtualized Xen will easily outperform VT enabled
fullyvirtualized Xen. 2nd generation VT enabled hardware is starting to add some interesting
features (NPT on AMD, EPT on Intel) that can make a huge difference to performance bringing
fullyvirtualized guests closer to being on a par with paravirtualized ones. You still need to
have paravirtualized drivers inside your fullyvirtualized guests though - without it I/O will
be terrible. 

The article in question is really quite badly done. Plain QEMU is not really interesting
unless you need to do cross-architecture virtualization, eg PPC on x86 - no one will claim you
should use it for native x86 on x86 because emulation is simply never going to be fast enough.


KVM's future is very bright indeed, but if there's no VT then it reduces to just QEMU
emulation, so the review was rather worthless wrt to KVM. If you're talking state of art, then
KVM should be compared against Xen paravirt and Xen fullyvirt since that's the most commonly
used open source virt out there today, and for all its flaws Xen (eg not being in upstream
LKML) does work pretty well in terms of performance. 

Finally, paravirtualized drivers should be used in all tests, since I/O performance will
inevitably suck without it and anyone seriously deploying virtualization in production will
use paravirtualized drivers.

Virtualization in Linux: A Review of Four Software Choices (Techthrob.com)

Posted Feb 12, 2008 11:34 UTC (Tue) by Felix_the_Mac (guest, #32242) [Link] 


I was thinking the same thing... but since I've only played with KVM for 1 day this weekend I
don't know for sure. :-)

Virtualization in Linux: A Review of Four Software Choices (Techthrob.com)

Posted Feb 12, 2008 23:12 UTC (Tue) by interalia (subscriber, #26615) [Link] (3 responses) 

I think this review is flawed because it only concerned running Windows.  For Linux users,
that may be the most common guest OS, but the problem is that it potentially measures
optimisation for a Windows guest rather than generic virtualisation performance. And since the
hardware did not support VT, that also might affect things.

I use Parallels at work for running QNX on a Core 2 with VT. In my limited experience, QNX
runs much faster in Parallels than in VMware despite being somewhat crappy on Linux due to the
Mac being their biggest focus.

Virtualization in Linux: A Review of Four Software Choices (Techthrob.com)

Posted Feb 13, 2008 1:02 UTC (Wed) by leoc (guest, #39773) [Link] (2 responses) 

Have you tried VirtualBox?  Sun just bought the parent company (Innotek), but the code is
GPL'd and even the SVN trunk works well (just stick to kernel 2.6.23 on your host, the kernel
driver doesn't support 24 yet).

Virtualization in Linux: A Review of Four Software Choices (Techthrob.com)

Posted Feb 13, 2008 23:08 UTC (Wed) by interalia (subscriber, #26615) [Link] (1 responses) 

No, I haven't tried VirtualBox yet actually... good reminder.  I haven't looked into it
closely, but I thought that the free GPLed version was crippled in a significant way compared
to their commercial offering?

Virtualization in Linux: A Review of Four Software Choices (Techthrob.com)

Posted Feb 14, 2008 21:13 UTC (Thu) by leoc (guest, #39773) [Link] 

I think the free version is complete.  I've run OS/2, Windows and Linux under it.  The
drawback is that it is somewhat difficult to compile.  I would recommend getting the code from
subversion. The tarball drops do not contain some of the dependencies so their hokey build
system has trouble when you try to point it to versions installed separately.


Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds