Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Gains Two New Virtualization Solutions

Posted by CowboyNeal on 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."

16 of 170 comments (clear)

  1. Why? by realdodgeman · · Score: 4, Interesting

    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.

    1. Re:Why? by QuantumG · · Score: 5, Insightful

      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?!

      --
      How we know is more important than what we know.
    2. Re:Why? by QuantumG · · Score: 3, Informative

      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). It *is* a hardware driver.

      --
      How we know is more important than what we know.
    3. Re:Why? by QuantumG · · Score: 5, Funny

      bus error: driver not found.

      --
      How we know is more important than what we know.
    4. Re:Why? by drinkypoo · · Score: 3, Interesting

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  2. Could somebody clear this up for us? by Tribbin · · Score: 4, Insightful

    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!
    1. Re:Could somebody clear this up for us? by QuantumG · · Score: 3, Insightful

      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.

      --
      How we know is more important than what we know.
    2. Re:Could somebody clear this up for us? by Chris+Snook · · Score: 5, Informative

      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.

      --
      There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
  3. Re:Multiple ways to run Multiple OSs by Iphtashu+Fitz · · Score: 3, Informative

    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.

  4. Re:I RTFA twice and thought to myself... by brunes69 · · Score: 4, Funny

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

  5. GPU support question by JustNiz · · Score: 4, Funny

    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

  6. Clarification of these technologies by GiMP · · Score: 4, Informative

    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.

    1. Re:Clarification of these technologies by _Knots · · Score: 4, Informative

      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.

      --
      Anarchy$ dd if=/dev/random of=~/.signature bs=120 count=1
    2. Re:Clarification of these technologies by Per+Wigren · · Score: 3, Interesting

      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 and VServer 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.

      --
      My other account has a 3-digit UID.
  7. Re:So, will it run Windows? by init100 · · Score: 4, Informative

    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.

  8. Re:So, will it run Windows? by zlatko · · Score: 3, Interesting

    Absolutely, running Windows XP on Linux 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.