Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Linux Gains Two New Virtualization Solutions

Posted by CowboyNeal on Sat Jul 21, 2007 08:51 AM
from the almost-as-good-as-the-real-thing dept.
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."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • just asking...
    • KVM (have been in the kernel since 2.6.20) already runs windows.
      • Re: (Score:3, Interesting)

        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.
    • by init100 (915886) on Saturday July 21 2007, @01:22PM (#19939501)

      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? (Score:4, Interesting)

    by realdodgeman (1113225) on Saturday July 21 2007, @08:57AM (#19937657) Homepage
    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? (Score:5, Insightful)

      by QuantumG (50515) <qg@biodome.org> on Saturday July 21 2007, @09:13AM (#19937761) Homepage Journal
      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: (Score:2, Informative)

        IDE is not a bus, don't confuse this with ATA (more recently SATA and PATA). IDE == Integrated Drive Electronics.
        • Re:Why? (Score:4, Informative)

          by QuantumG (50515) <qg@biodome.org> on Saturday July 21 2007, @09:39AM (#19937917) Homepage Journal
          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? (Score:4, Interesting)

          by drinkypoo (153816) <martin.espinoza@gmail.com> on Saturday July 21 2007, @10:30AM (#19938269) Homepage Journal

          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.

          • I didn't realize that iguest is going to be turned on by default. Oh wait.. it probably isn't. If you ever did a

            make xconfig

            you can see that the very first option is "code maturity level options", and that there are hundreds of features which are by default NOT TURNED ON and therefore do not show up in "anything resembling a production environment". And I'm not talking about kernel modules here, but things like CONFIG_MATH_EMULATION (under "processor type and features" near the bottom of the page) which

        • Re: (Score:3, Informative)

          It'll only increase the kernel foot print IF you compile them into the kernel, which they won't be enabled by default.
        • Re: (Score:3, Informative)

          Only if enabled in the distribution. It doesn't harm anyone to have it available in the kernel source tarball. And both KVM and Lguest are implemented as modules, so if you don't load them, they aren't there.

  • by Tribbin (565963) on Saturday July 21 2007, @09:00AM (#19937673) Homepage
    What are the pro's for heaving two implementations of, seemingly, the same solution?
    • The more people who use both solution, the quicker the kernel team can figure out which one works better, and go with that.
      • 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.

        • Good point...but I believe that, over time, the one that most users choose will end up being the most actively maintained.
    • Re: (Score:2, Informative)

      It's not the same solution because lguest and KVM have different goals. While KVM is trying to use as much hardware virtualization support as possible to gain full speed, lguest is not using these functions to run on more hardware. XEN tries to do everything and is thus a bit more bloated, but also with more functionality. Choice is good, just take the solution which fits your requirements best.
    • "The happy theme of today's kvm is the significant performance improvements, brought to you by a growing team of developers. I've clocked kbuild at within 25% of native. This release also introduces support for 32-bit Windows Vista. "

      I can't understand why the Linux kernel development team had 'Windows Vista support' as one of the items on their agenda at all. Virtualisation as I understand it, is basically an abstraction of the hardware that is performed in software. Should not all operating systems be designed to work with standard instruction sets, interrupts, registers and memory?

      Why should it be the job of a particular kernel or it's VM component to satisfy specific requirements of a specific version of another kernel (the Vista k

      • Re: (Score:3, Informative)

        The people who work on this stuff really wouldn't call themselves kernel developers, but ok, whatever. Associating any of the VM stuff with Linus is even more retarded.. what they do in their own modules is none of his fault or concern. Anyway, some people want to run Vista in a VM on Linux. These VM solutions don't try to virtualize every nook and cranny of the x86 hardware. Vista uses the system level x86 hardware in a slightly different way to XP. As such, it takes some changes to make Vista work.

        Should it not be the other way round - i.e. for closed-source Vista to be compatible and optimised for the open-source Linux kernel?

        Y

        • The people who work on this stuff really wouldn't call themselves kernel developers, but ok, whatever. Associating any of the VM stuff with Linus is even more retarded.. what they do in their own modules is none of his fault or concern.

          I find the announcement about these VMs is from Linus himself. Besides, it is Linus who decides which components get into the main kernel tree, so he is answerable for any decisions made.

          Anyway, some people want to run Vista in a VM on Linux. These VM solutions don't try to virtualize every nook and cranny of the x86 hardware. Vista uses the system level x86 hardware in a slightly different way to XP. As such, it takes some changes to make Vista work.

          If Vista has any idiosyncracies, it should be the job of the overpaid, bloated development team in Redmond to iron out the kinks and make it standards-compliant. Why should it be a concern of the Linux kernel development team? Besides, how did these developers gain access to quirky behaviour of Vista?

          • I find the announcement about these VMs is from Linus himself. Besides, it is Linus who decides which components get into the main kernel tree, so he is answerable for any decisions made.

            Linus puts whatever he wants into his tree, yes. His tree is the defacto "main" kernel tree, yes.

            If Vista has any idiosyncracies, it should be the job of the overpaid, bloated development team in Redmond to iron out the kinks and make it standards-compliant. Why should it be a concern of the Linux kernel development team? Besides, how did these developers gain access to quirky behaviour of Vista?

            What standards are you talking about exactly? The Intel x86 hardware documentation? I can assure you they are writing their code to those "standards" otherwise their code wouldn't work..

            If anything the virtualization guys are the ones who are not implementing the "standards".. as not everything that will run on an x86 processor will run the same way under virtualization. That's simply because it's a lot of

    • by Chris Snook (872473) on Saturday July 21 2007, @12:09PM (#19938927)
      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.
  • ...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?
    • Re: (Score:3, Insightful)

      The hardware support for virtualization is in the kernel.

      Just like the hardware support for webcams is in the kernel.

      • See, now, that would make sense. So it's not the entire virtualization programs, just hardware hooks and drivers, basically? Meaning that there still needs to be a separate program to take care of actuality running things and what not?
        • Re: (Score:3, Informative)

          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. W
      • My question has nothing to do with monolithic vs microkernel. My question has to do with why are these programs being including with the kernel.

        Only one hardware branch of the kernel gets compiled, and yes, I know I can choose not to compile many things into the kernel, and do so whenever I compile it.

        See the post below you for an answer that was helpful. Compare that to your answer, and figure out how to answer a question instead of trying to belittle someone.
  • by JustNiz (692889) on Saturday July 21 2007, @10:08AM (#19938123)
    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
    • Re: (Score:3, Informative)

      No. But if/when there is ever an open source nvidia kernel driver with 3d support that isn't completely broken and is integrated into the kernel, you might see some people take an interest in virtualizing it.

      Probably the first thing they'll do is make it so X running in a virtual machine can share the same DRM (Direct Rendering Module) as X running on the host. Of course, that's not much good to a Windows guest.

    • Re: (Score:3, Interesting)

      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]

  • by GiMP (10923) on Saturday July 21 2007, @11:02AM (#19938475) Homepage
    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.
    • by _Knots (165356) on Saturday July 21 2007, @12:42PM (#19939209)
      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.
    • by Per Wigren (5315) on Saturday July 21 2007, @12:44PM (#19939239) Homepage
      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: (Score:2, Informative)

      by Anonymous Coward
      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.
    • I don't have any idea what you mean by "VMWare Player doesn't work with my wireless card". VMWare doesn't know ANYTHING about your underlying networking hardware. All it uses is the IP stack.
      • Re: (Score:2, Informative)

        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).
      • Re: (Score:3, Informative)

        I have an Atheros chipset wireless card which requires binary drivers to work. It does not work with VMware.

        This [launchpad.net] 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 fro
    • Competition is a wonderful thing!! I suspect three solutions probably will quickly end the vmware / XEN disagreements that went on for so long... :-)
    • by Iphtashu Fitz (263795) on Saturday July 21 2007, @09:24AM (#19937825)
      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.
    • Please review Robert Frost: "The Road Not Taken [amandashome.com]".

    • it might be worth remebering that the _kernel_ part of these VM solutions have been merged into the kernel, and not the userland tools (they are seperate packages). A VM needs certain kernel hooks for the hardware virtualization, hence the need for a kernel 'driver(s)', and the VM scheduling happens there too.

      So the comparisment with emacs is very inaccurate, emacs is a userland tool, and doesn't have kernel modules :-)

    • Re: (Score:3, Informative)

      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.
    • If you still need access to Adobe products like Photoshop for print production, like my GF does, there's nothing available on Linux that will do the job.

      Linux + Xen + W2K lets her leave the windows desktop and still use these tools.

      Pretty straightforward.

      Yes.

    • Re: (Score:3, Informative)

      I only have Ubuntu installed and I don't see why a VM is such a massive feature these days?

      I have vmware installed and use it on a regular basis. Here's what for:

      • Windows emulation. Wine is great and good, but it doesn't run everything. Sometimes I want to run some Windows software not supported by Wine. Mostly this takes the form of various (non-3d) games. I have Windows 98 and Windows 2000 VMs. Also cellphone hacking can pretty much only be done under Windows (at least for Motorola) - it's possible to flash only like one format of software image under Linux, whereas I can handle about five o
    • 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.