Red Hat Pledges 'Integrated Virtualization'

OSS_ilation writes "Red Hat was all about virtualization in a recent announcement for an 'integrated virtualization' initiative with XenSource and chipmakers AMD and Intel. The move was seen as a way for Red Hat to bring its commitment to virtualization technology into 'sharper focus [...] with the release of a product roadmap that includes virtualization technology built into its enterprise version of Linux.' Red Hat's CTO, Brian Stevens, said the move would remove the complex 'rocket science' aspect of virtualization, and drive the technology into more enterprises as a result."

Sweet

[maelstrom]

No matter what the haters say, Red Hat is one of the main distributions I go to when building a new server (CentOS if no support needed). Things like integrated SELinux, easy to use yum (or rpm apt-get), and now virtualization make it very impressive.

Red Hat + Xen

[plasticsquirrel]

From what I gathered from the article, it looks like Red Hat is porting their distro to the Xen virtual machines and then packaging that with the natively-compiled OS as a virtual machine manager. It's nice to see a distro pick up Xen officially and package it an easy-to-use way, since Xen has very impressive performance. The article or the summary probably should have included a link to the Xen web site, so if you want to know more: the Xen site [cam.ac.uk].

Re:What is this?

[barefootgenius]

Refer http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ [cam.ac.uk] or http://en.wikipedia.org/wiki/Xen_(virtual_machine_ monitor) [wikipedia.org].

Re:This sucks

[NitsujTPU]

It can take a couple of forms. In one form, it would be hooks for a VMM requiring a host OS.

In another form (which I know that Xen supports) it provides ways for the VMM to have control over the host OS, though Xen supposedly supports a number of these methods though ways not requiring modification to the source code.

There are others too (IE, replicating an image of a running OS, snapshotting the OS).

The article doesn't really tell you what they mean at all. I've seen all of these discussed in the context of Linux and Xen before. In fact, I thought that most of those were implemented.

Xen Vs. Linux VServer

[linuxguy]

A couple of months ago I was faced with the problem of needing to host multiple domains on one system. I initially considered Xen for my virtual servers need. However when I learned that this solution would not share the memory (each Vserver would have to have its dedicated memory) I decided to try out Linux Vserver [linux-vserver.org]. I have been a happy user of Linux Vserver since then.

With Linux Vserver you only run one kernel on your system where with Xen each virtual server runs its own kernel. This presents some limitations for Linux Vserver. For example the guest virtual servers cannot have the network loopback interface lo. But almost all of these I could live without.

Now if I want to start adding more virtual servers I can, without having to worry about running out of memory.

Re:Xen Vs. Linux VServer

[NitsujTPU]

There is a paper where the authors used Xen in a manner in which they copied the image of the running OS. A copy on write police was implemented, so RAM usage would be minimal. They got Xen to scale to thousands of virtual servers on some form of relatively reasonable hardware.

It is worth noting, though, that this is part of the point of what Xen is. Xen is a VMM, and part of the point is that you virtualize the machinery so you can run multiple OS's and such. This really is the direction that everything is going. The technologies that you can build on top of this are very... convenient.

Re:Xen traded full OS compatibility...

[Al Dimond]

To put it simply (I don't know the more in-depth stuff off the top of my head) Xen won't run an unmodified x86 OS as a guest (DomU). Instead of actually emulating the physical devices it provides ways for the guest OSes to request services from it through specialized "drivers", for one thing. Once the kernel/driver work is done, however, the fact that you're running under Xen does not affect your userspace apps.

So you can only run operating systems that have been modified to run under Xen. So far Linux, FreeBSD, NetBSD and Plan9 have undergone modification, at least according to http://wiki.xensource.com/xenwiki/OSCompatibility [xensource.com]

Re:Red Hat leaving the desktop arena?

[drsmithy]

RedHat has never sold a desktop/laptop product.

Yes, they do. [redhat.com]

it already is.

[nietsch]

Only the technology is named User Mode Linux (UML) instead of Xen. Xen still requires you to jump trough quite a number of hoops before you have a virtual machine running. With UML it is so simple you can start, stop & create new ones on demand like is done at linuxzoo.net [linuxzoo.net]

With xen you need a modified host kernel and do some tricky stuff with LVM to use Copy on write disks. With lvm it is the default, you can just point to a base image and have the users modifications in a separate file. The downside is the speed penalty: UML is 40-50% slower than Xen.

Re:it already is.

[Anonymous Coward]

Xen is way more flexible and has way greater performance than UML. Although you do have to patch the kernel in order to use Xen, your comment could be interpreted as if you were *forced* to use LVM and COW with Xen. This is, however, misleading - neither of these possible options are /default/.

Your 40-50% figure is also highly misleading. When operations are I/O-bound, UML can lose to Xen by a factor of 100, but when it's CPU-bound, the overhead of either method is neglegible.

Re:Xen traded full OS compatibility...

[buddha42]

This is no longer true with the use of Intel's VT or AMD's Pacifica CPU features. Xen originally had to have this OS-level hack because of limitations of the x86 architecture making it impossible to completely virtualize. Intel and AMD have solved this. You can buy Pentium 4's with VT *right now* and run un-modified windows guest's on Xen. The AMD M2 and the next set of Intel chips (the core/core-duo's desktop and server cousins) will all support this.

Modified kernel vs. modified chips

[hpcanswers]

Xen works with any OS as long as either the kernel has been modified to fit virtualization, or the processor has extensions that support it directly. So either way, Xen allow just any old system, though it isn't tied to a particular platform.

Just a word of caution though: Xen is "new technology," which basically means it isn't the most stable product right now, especially given its level of technical sophistication. Similarly, the new processors from AMD and Intel are, well, new; they will require some time in the market before they are used adequately.

All in all though, the technology is pretty exciting. Some researchers I work with are looking into using Xen on SMPs with multiple Ethernet ports. Since vanilla Ethernet requires the kernel for TCP, multiprocessors tend to have trouble adequately using the multiple communication links. With virtualization though, there can be one instance of the OS per processor, which means one TCP stack per processor, which means one Ethernet port per processor.

Re:Beta testers == lab rats

[mikelieman]

I've been using the FC5RC3 on a test system which uses Xen for a wacky combo of MySQL, and PHP that some groupware requires which conflicted with the standard Core packages.

From what I've seen in going from "Rolling Your Own" to the FC5 distro, is that Fedora got it RIGHT on this one. "It Just Works" for me.

When the host machine gets rebooted, it doesn't even reboot the Guests. They just get suspended, and resumed when the machine comes back up.

Two Thumbs Up.

Re:Xen Vs. Linux VServer

[styrotech]

To me, one kernel is an advantage, not a limitation. A kernel upgrade on a VServer box is a one-step operation, whereas on a Xen (or like) you have to repeat it for every guest.

Not quite. Unless your guests use different kernels (in which case you wouldn't be using VServer anyway), you only have one guest kernel to worry about. I have a Xen machine running 4 Debian Sarge machines - in the boot directory of the host there is the host kernel and a guest kernel. All guest instances boot off that one guest kernel. There are no kernels installed in the guests themselves.

Sure upgrading two kernels is more work than upgrading one kernel, but it not as bad as you think.