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?

[The_Fire_Horse]

just asking...

Why?

[realdodgeman]

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?

[Anonymous Coward]

I'm wondering what's NOT going to be put in the kernel eventually. I mean what's next, MPlayer? At what point do we say enough is enough?

Re:Why?

[drinkypoo]

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.

Re:GPU support question

[EvilRyry]

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.

I recently read an article on the progress of just this. It sounds pretty cool and the initial results are impressive. This combined with the DX->OpenGL Wine code, that I'm sure will be open sourced from the makers of parallels (just had a slashdot story on this), makes for an exciting future for providing hardware acceleration to guest applications.

More information: http://www.cs.toronto.edu/~andreslc/vmgl/ [toronto.edu]

Re:Clarification of these technologies

[Per Wigren]

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.

Re:So, will it run Windows?

[zlatko]

Absolutely, running Windows XP on Linux [linuxinsight.com] is both easy to setup and performs quite well. I'm quite amazed with kvm technology for both reasons. This is not to say that Xen is bad, but it seems so much harder to setup, that I haven't even tried. kvm is dead simple.