Slashdot Mirror
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."
just asking...
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.
What are the pro's for heaving two implementations of, seemingly, the same solution?
If you mod this up, your slashdot background will turn into a beautiful sunset!
FYI, Xen hasn't required VT since the beginning either. The only problem was you needed a specially patched kernel because linus didn't like how xen implemented their hooks into the stock kernels. It looks like that has been resolved however.
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.
I once considered writing a kernel emacs accelerator module, but later decided it would be easier to just run Linux inside of emacs!
VMWare by default bridges your network interface into the VM. Wireless drivers have such poor support for network bridging that this almost never works. It especially doesn't work with WPA or any such.
If you NAT your VM network traffic, then things work (well sorta, with all the nastiness that NAT comes with).
It's a big help for software developers needing to support multiple platforms/versions. At my company we provide support for the past 5 or 6 versions of our software, so I have a VM for each version that I fire up when I need to check something or patch a bug. Lots easier than dealing with multiple physical machines.
"The best argument against democracy is a five minute chat with the average voter."
--Winston Churchill
The hardware support for virtualization is in the kernel.
Just like the hardware support for webcams is in the kernel.
How we know is more important than what we know.
I have an Atheros chipset wireless card which requires binary drivers to work. It does not work with VMware.
This is the Ubuntu bug report (note the length and number of duplicates) which actually breaks apt on installation, but it's not Ubuntu specific; you can't configure it manually with this wireless card either. The only solution is to disable networking virtualization, which means I can't even have VMware use my wired connection unless I disable the wireless card entirely or physically remove it from my system.
Was I seriously modded down for that? Mods, what the hell?
Yes. Thing is, bare x86 metal can do virtualization.. you just gotta be creative. There's a lot of ways to do it, utilizing different parts of the hardware. So there's some solutions that work great for some things and some solutions that work great for others. It's like having two drivers for the same bit of hardware and choosing which one to use based on how you're using the device.
:)
Then there's para-virtualization.. modifying the kernel of the guest OS so you don't even need anything in the kernel. Well, sometimes kernel support can help para-virtualization
How we know is more important than what we know.
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
How we know is more important than what we know.
I have vmware installed and use it on a regular basis. Here's what for:
I've talked about it elsewhere, but I also envision a system using UML (or now, lguest) to separate servers (or groups thereof) away from the main system to reduce security risks. It would let you use selinux with a fairly restrictive policy on your controlling system, and if one of the subsystems is compromised it could easily be discarded and rebuilt.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.