Linux Gains Two New Virtualization Solutions

An anonymous reader writes "The upcoming 2.6.23 kernel has gained two new virtualization solutions. According to KernelTrap, both Xen and lguest have been merged into the mainline kernel. These two virtualization solutions join the already merged KVM, offering Linux multiple ways to run multiple virtual machines each running their own OS."

So, will it run Windows?

just asking...

Re:So, will it run Windows?

You mean Lguest? FTA:

Lguest doesn't do full virtualization: it only runs a Linux kernel with lguest support.

So the answer is no, Lguest does not run Windows. Xen runs Windows, but only if you have a VT-capable processor. Like Lguest, Xen can run Linux without a VT-capable processor.

Why?

Wouldn't it be enough with one? Or maybe they could have merged all the features into one VM.

I think this will confuse users. Choice is good, yes, but 3 VMs in the kernel? Sounds like overkill.

Re:Why?

Yeah, like all those file systems the kernel supports. What's with that? You only need one. Man. Choice is good and all, but it sounds like overkill.

Don't get me started on buses.. PCI, USB, SCSI, IDE, how many do you need?!

Re:Why?

bus error: driver not found.

Re:Why?

Which is why I mentioned file systems...

That said, you mentioned KVM.. KVM (for Kernel-based Virtual Machine) is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). (from here [qumranet.com]). It *is* a hardware driver.

Re:Why?

In what way are hardware drivers similar to VM technologies?

in this situation the analogy is clear. As time went on, people discovered new designs for virtualization and decided to implement them. Each design has strengths and weaknesses that make them appropriate for different situations. The same is true of hardware buses; older buses tend to be cheaper to implement. There are exceptions, it's probably cheaper (or will soon be cheaper due to economies of scale) to implement PCI-Express at PCI bandwidth than it is to implement PCI itself. It's certainly cheaper to implement firewire than SCSI (in spite of this, there are practically no native firewire storage devices. But anyway.) (And firewire, which goes up to 800MHz which peaks at 100MB/sec, is superior in most ways to anything up to and including LVD SCSI, including speed, simplicity of cabling, etc etc) Can you tell I have an ax to grind?

But anyway, the point is that we have UML, which runs linux as a process; we have this new lguest, which runs linux as a module; we have xen which is full virtualization without a need for VT, we have kvm which is like xen but does need VT, we have vmware which is also pretty much like xen (and doesn't need VT, although I was under the impression newer versions of vmware would take advantage of it if present, for a speed boost.)

There's some other examples too, but these are enough to talk about right now. Suffice to say that each approach has advantages and disadvantages. But they're useful for different things!

For maximum separation, for example, you could have a Linux that ran servers inside of different UML processes. While exploits in UML would still be possible, this would stop a privilege escalation bug in one server from affecting another. I envision a tool that tracks dependencies and generates the UML filesystem images automatically. Syslogging is done through the virtual network, to the syslog on the core system. Want to test a package? A command to run it in a UML might be as simple as running fakeroot. (fakelinux?) You could do all of this with this new lguest system, instead of UML.

Meanwhile, you're still going to need a full virtualization solution to run non-linux operating systems under Linux (at least until a cobsd (see "colinux") comes out - I forgot about that one for a moment) so there's still a purpose for that.

lguest doesn't need VT

More importantly, lguest apparently does not require a CPU with virtualization technology. This is exciting news for those of us running on older hardware.

As a cross-platform developer, I'm interested in installing Windows on a virtual machine instead of dual-booting, and the current virtualization technologies don't cut it for me; VMware player is proprietary and doesn't work with my wireless card, QEMU is just too darn slow, and everything else requires a VT CPU. I'm looking forward to trying out lguest.

Could somebody clear this up for us?

What are the pro's for heaving two implementations of, seemingly, the same solution?

Re:Could somebody clear this up for us?

Actually, it doesn't work like that. What actually happens is that the code which is maintained poorly gets dropped. So if there are dedicated people working on KVM but no-one actually working on lguest, eventually something will change that results in lguest not working anymore. Eventually people will drop the broken code from their tree until someone fixes it. If no-one fixes it, then it'll never be picked up again. There's no "oh, lguest is actually faster than KVM, we should all work on that".. it's individuals making their own decisions on what to work on (be it that they find it interesting, or they find that bit of code more pretty, or they are paid by someone to work on it) and those individuals are responsible for what happens to that code.

As long as N solutions are maintained there will be N solutions in the kernel. A solution won't be dropped because it performs worse.. or any other "technical" reason.

Re:Could somebody clear this up for us?

These aren't even close to the same solution. KVM provides hardware-assisted virtualization, with Linux as the hypervisor. Lguest provides linux-in-linux paravirtualization (no hardware support), and is extremely lightweight (5000 lines of code, total), but lacks many advanced features. Xen provides both paravirtualization and full virtualization, runs under a custom hypervisor intended to run multiple different OSes (Linux, Solaris, Windows, etc.) simultaneously, and has a plethora of sophisticated features, such as live migration (and all the maintenance headache of the correspondingly huge codebase).

They each fill very different niches, so there are very good reasons for having all 3 in the kernel.

I RTFA twice and thought to myself...

Wow, there are now three VM solutions built right into the kernel? What are they going to do next? Merge emacs?

Re:I RTFA twice and thought to myself...

I once considered writing a kernel emacs accelerator module, but later decided it would be easier to just run Linux inside of emacs!

As a testament to my lack of knowledge...

...why should virtualization technology be incorporated into the kernel, and not kept outside, as a "3rd" party app? Shouldn't the kernel be essentially a library and some low level support (multi-tasking, handle certain interrupts, that sort of stuff)? I've never really even considered bash, or even ls as part of the kernel. Am I just really mistaken, or is the word kernel used more broadly than that?

does anyone actually use a VM....

... on the desktop? I only have Ubuntu installed and I don't see why a VM is such a massive feature these days? Have I missed something amazing that I can do on these or is it simply for a cool "hey I can run a desktop on a desktop!"

I understand that application compatibility is a big deal but Linux has a zillion apps already.

I just don't get all the marketing surrounding it.

GPU support question

So do any of these solutions support 3D graphics (nvidia) hardware?
The only reason I currently have a windows partition at all is for gaming.

Being able to run Windows 3D games in a VM would allow me to move to a Linux-only box and also give me a nice way of:
* managing the way windows keeps grabbing diskspace
* remove the need to go through reinstalling/reactivating windows every 6 months or so
* limiting the damage Windows virusses can do
* limiting all the phone-home comms with Microsoft that windows keeps doing

Clarification of these technologies

Each of Xen, KVM, lguest, and UML can be considered virtualization products but they are all vastly different. Below I describe each of these products in relation to their inclusion to the Linux kernel.

Xen - the Linux kernel supports code allowing it to be run as a guest underneath the Xen kernel, all through software. Linux's support for Xen does not make Linux a virtualization platform, only a GUEST for the Xen kernel which sits at Ring-0. (though a "dom0" Linux system can interact intimately with the Xen kernel, it actually sits at Ring-1). I should note that the Xen kernel also supports hardware virtualized domains, though this is unrelated to the patches to Linux.

KVM - the Linux kernel supports virtualization of guests through hardware extensions, this requires supported hardware. Linux becomes the Ring-0 kernel.

lguest - (my understanding is) an unmodified Linux kernel can act as a hyper-supervisor through loading Linux kernels as modules. Linux sits as both Ring-0 (supervisor) and Ring-1 (guests). This is experimental with limited features and only supports Linux guests.

UML - the Linux kernel becomes a userspace program. This allows Linux to run as an executable application/program. With UML, Linux can be compiled for a Linux or Microsoft Windows target. The executing OS sits at Ring-0 and the UML program sits at Ring-1. This has the advantage of requiring no modifications to the host OS and is very portable (you could email an entire Linux system to a friend without requiring anything installed to their system), but the disadvantage of poor performance.

From a high-level, the products UML, Xen, and lguest are actually very similar in function. They act as architectures to which Linux can be compiled in order to make it a guest OS of another Ring-0 kernel. These architectures provide the targets of a kernel module (lguest), a userspace program (UML), or a xen-domU guest (Xen). On the other hand, KML is the only patch that is intended to add support to Linux to act as a Ring-0 kernel on behalf of guest systems -- and even then, KML can be viewed more as a hardware driver for the processor extensions.

Re:Clarification of these technologies

Slight corrections:

The UML program sits at ring-3 on X86 machines: it's just a normal user program using the ptrace() mechanism and extensions [except when the host has been patched with SKAS, but even here it's just a "normal user program". Rumor has it that SKAS might eventually make it into mainline, but it's time in 'real soon now' is starting to rival Duke Nukem Forever's.]. Rings 1 and 2 are odd, rarely used (IIRC there's the current virtualization craze and OS/2 as notable consumers) features of the x86, derived from MULTICS. For processors with only two (user & supervisor) modes, identify ring 0 with supervisor mode and the other rings with user mode.

It is a little odd to say that Linux "becomes" the Ring-0 kernel under KVM. It was already running in ring 0.

Re:Clarification of these technologies

Yes, they are all very different but at the same time quite similar from a user's perspective. All of them (unless I've missed something) more or less emulate a whole machine. This means you have to mess with disk images or dedicated drives/partitions/LVs, allocate a fixed amount of RAM to the guest, among other things.

Personally I like the approach of OpenVZ [openvz.org] and VServer [linux-vserver.org] better. The main OS and the guests all share the same kernel, share the RAM and their root filesystems can be just subdirectories of the host's filesystem. When inside the virtual server you don't realize that though. You only see your own processes and everything works as if it was a dedicated server. You can run iptables, reboot and just about everything you could normally do in XEN/KVM/VMWare. Including live migration of virtual servers to other physical hosts. chroot on steroids.

I really hope OpenVZ and/or VServer will be merged at some point. VServer seem to keep up with current kernel releases so that wouldn't be too hard to merge I guess. OpenVZ usually have a lag of something like half a year.

but

But will it run on... nevermind!

yes!!

I think all the xen users out there will agree with me when i say "yes!!!!!!!!!!!". I'm actually quite impressed, given what is involved in maintaining xen in the kernel, that this happened as soon as it did.

Hardware requirements and microcode.

Three choices, but none of them gives the optimal solution, which is unmodified guest OSs on processors lacking specific hardware support.

This is apparently hard or impossible on many i386 processors due to the difficulty of intercepting certain instructions. But since Linux updates the processor microcode at boot time, would it be possible to modify the processor microcode to change the way the offending instructions operate ?
(just invalidating them would proably be enough)

3D acceleration please

I've slowed worked Linux into everything else I do on a computer, now just let me never have to switch out of it and I'll be set.

Anybody running OS/2 Warp 4 under linux?

I keep an old PII clunker kicking around to run Galactic Civilizations V2.5, an OS/2-only game. I'd really like to get rid of it, but keep OS/2 for the game. With QEMU and Virtualbox, I've occasionally managed to "install OS/2" but the VM crashes when trying to do much more than merely bring up the OS/2 desktop. I'd be interested in any working solutions. TIA.

How freakin' big is the Linux kernel now?

Anyone attempting to compile a full Linux kernel with every conceivable feature that doesn't clash with another turned on, non-moduluar, will be able to measure the build time in months...

Unless they're running a virtualized cluster of machines! :-)

Re:Multiple ways to run Multiple OSs

Competition is a wonderful thing!! I suspect three solutions probably will quickly end the vmware / XEN disagreements that went on for so long... :-)

Re:Multiple ways to run Multiple OSs

A number of reasons. One is to be able to run different linux distros on the same machine for testing purposes. Another is to set up two completely different environments that run tasks at different times.

I used to work for a search engine company (not Google) that has thousands of linux servers. After doing a bit of research they discovered that the vast majority of these machines are idle for a good amount of time. Rather than buy new servers they simply installed Xen and intellegently divided up the physical hardware to perform their different tasks. Now instead of separate physical servers to do web spidering, data analysis, log processing, etc. they've combined these tasks onto the same physical hardware but kept them as individual virtual servers.

Re:What about kqemu?

If kqemu want to integrate their kernel components into the kernel they can. It's not the Linux developers going out looking for things to add to the Linux kernel... or them developing their own solutions.. or anything like that. All of these technologies have been added to the kernel tree by the people who maintain them.

Solved it three different ways!

Please review Robert Frost: "The Road Not Taken [amandashome.com]".

Re:legality

Despite being modded down to -1, I think this needs treating as a legitimate question:

Isnt it illegal to run windows with this? Googled it n microsoft seems to think so.. MelNews

Illegal? That depends on your definition of legal... different nations have different laws.
Breach of software license? Possibly... if I recall correctly, the EULA for Vista forbids running in a virtualised environment. I believe it is perfectly legitimate to run XP this way as long as the license key has been purchased legally and is not currently in use in another installation (obviously with the exception of multi-user licenses). For other versions of Windows, it depends on the EULA but I think Vista is the only one to forbid it.

Re:Multiple ways to run Multiple OSs

Why what? Why multiple virtualization solutions? Because each solution has its own advantages and disadvantages. Use the solution that fits your needs best.

Re:What about kqemu?

KQemu hasn't been GPL for very long, so it hasn't so there hasn't been very many people looking at it for very long. Also the developer of KQemu probably hasn't even ASKED it to be merged (or maybe he has, I don't read the LKML). It's also possible he submitted it to be merged and theres a few things they want him to work out first (Xen has been trying to be merged for a LONG time now).

Re:What about kqemu?

Actually, adding the complexity of all this virtualization into the kernel is a little scary to me.

I just upgraded my wife on Debian Sarge testing with a Win4Lin 2.4-27 kernel. Web designer who demanded PhotoShop, Illustrator, Flash, and IE but the Win98 Win4Lin base and apps were getting dated. Did a dist upgrade to Etch Stable and installed XP Pro on QEMU with kqemu. Was good. The kqemu performance was very adequate, net, samba share and got her apps working.

But then I upgraded to Etch testing. First, qemu itself had changed -- blog rumor says he changed the base virtualized hardware and my XP didn't start. Downgraded and pinned that. Couldn't use the 2.6-21 kernel with nvidia. I understand it has been a function issue within the paravirtualization. Could work around that an easy way -- in which case qemu wouldn't work again. Or I understand a person can hack some source. Also, I let a bochsbios upgrade slip in. Another package that killed qemu that I had to downgrade and pin.

So I ended up with sort of a Debian Etch testing but with several packages pinned back to stable that works fine but it has been a bit of a minefield. And it is my understanding that the virtualization built into the kernel is at the heart of the problem.

Re:What about kqemu?

KQEMU (and indeed QEMU) releases are relatively infrequent, the latest pair of releases was in February.

QEMU has so far been a solid foundation for a handful of other FOSS virtualisation solutions, KVM use a modified Qemu (Does anyone know if KVM support is going upstream into the next QEMU release?) and Virtualbox incorporated QEMU to establish full system emulation on top of their own hypervisor. If anything I'd like to see the Virtualbox OSE kernel module merged, which imo is far superior to raw QEMU+KQEMU at the moment.

QEMU is far from dead though, there seems to be quite a bit of activity regarding patches on the qemu-devel mailing list.