back to article Red Hat cranks virtualization power play

Red Hat is a player in operating systems and middleware, and it wants to be a player in server virtualization - at least more of a player than it has been since it parked the Xen hypervisor inside its Enterprise Linux 5 distro back in March 2007. The company has been dropping hints about its plans for server and desktop …


This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    Xen doesn't want to get their code mainstream

    Xen is getting the building blocks of their hypervisor in the linux kernel, but they've already announced that they do not plan to get their whole hypervisor in the linux kernel source tree. Maybe because KVM makes most of their code irrelevant...

  2. InsaneGeek

    Xen will never fully be part of Linux kernel

    Main reason is that Xen isn't linux at all, it's a based off a different microkernel rather than Linux. So when you are running Xen, something other than a Linux OS is actually running interfacing at the hardware layer, and then you run Linux on top of that layer... which is why the kernel guys probably won't ever fully integrate it into the mainline kernel, and it always will be an "add-on" by distros, etc.

  3. Richard


    KVM is so much easier to use. No need to reboot the whole server if I want to start a virtual machine. Linux is the hypervisor already. With the virtio drivers installed in my guests it's basically the same speed as Xen, and it does SMP and migration and all the rest perfectly well.

  4. Rupert Hair

    Xen *is* in the Linux kernel

    "...unlike Xen, KVM is part of the mainstream Linux kernel..."

    Please see:

    "Xen support has been in mainline Linux since 2.6.23, and is the basis of all on-going Linux/Xen development..."

  5. amanfromMars Silver badge

    Red Hat White Knights? Virgin Territory?

    "Xen is getting the building blocks of their hypervisor in the linux kernel, but they've already announced that they do not plan to get their whole hypervisor in the linux kernel source tree. Maybe because KVM makes most of their code irrelevant..." .... By diegocg Posted Monday 23rd February 2009 22:00 GMT

    That was almost right, diegocg. You might find that "Maybe because most of their code makes KVM irrelevant" is a lot nearer the truth in the Dynamic Inclusive Fields of Virtualisation.

    "What is not obvious to me is why you need Xen or KVM bundled inside RHEL if you have a free-standing KVM hypervisor and tools to deploy it on desktops or servers and manage either Windows or Linux instances. This sounds more like a legacy packing and pricing issue than a technical one."

    Bulls eye gold with that observation, Timothy. Are RHEL looking for a free Intellectual Property Ride/MetaDataMine of Virtual Machinery Technology/Topology? Although you can't blame them for that whenever it can render you an Open Field of Play to Capture all Markets and especially Control of Capital Markets, which would make the peanuts paid acquiring Qumranet, the creator of the KVM virtualization hypervisor, for $107m in cash last September, seem like money well spent, but only if it can Lead Perception with Viable Information Placement in both Mainstream and Underground Viral and Guerrilla Media Channels where they will Naturally Grow by Adoption and Adaptation to Generate Horizontal Client Wealth and Income rather than Imposition and Sale/Purchase for Vertical Payment and Profit. Should it be the Latter rather than the Former, will it be a Short Lived and Short Loved, and probably also just another one of those Naked Short Affairs, which are Crashing the System so Admirably.

    Whenever it is so easy to purchase trade secrets which capture Powerful Control Markets for cash printed in just seconds, who wouldn't accept an obscene offer, for the System always wins with its bet that the money is returned thus Generating Value/Industry/Product with its Spend and yet costing it Nothing because it is always returned to start all over again. The Real Secret is in finding Big Spenders who know how the System works rather than those who just Bank it and sit on the fat wallets hoping it doesn't disappear because they do so little and/or Nothing of Note for the System ..... which invariably has the natives getting restless too, plotting all manner of Activity to Crash the System and remove the Currency Blockage for a Constructive Free Flow.

  6. Anonymous Coward

    Re: Xen doesn't want to get their code mainstream

    Almost right, but not quite.

    The xen hypervisor, unlike the VMware and KVM hypervisors, does not sit inside the host OS, it's an OS in its own right. It's more like the venerable IBM VM in that respect. The Xen kernel (hypervisor) is tiny, much much smaller than the Linux kernel.

    What is going into the kernel (2.6.29 or possibly 2.6.30) is the native support that allows a mainstream kernel to run as the privileged domain. That means no more special xen-ified kernel, just use the unmodified, mainstream kernel. It works quite well now with the current release candidate for 2.6.29, but there are still problems to be ironed out.

    KVM has a lot of catching up to do before it can rival Xen and both will be around for a long time yet.

  7. Name

    Hardware support?

    my understanding is KVM needs hardware support compared to xen paravirtualised hosts which will run on anything?

  8. Anonymous Coward

    re: Hardware support?

    Exactly. KVM depends upon VT (or the AMD equivalent) and there are going to be a lot of existing RHEL5 customers who will be hacked off because Xen stops working on an update and their virtual machines no longer run.

    It will be interesting to see what does actually appear in 5.4. RHEL6 (and Fedora 11) will have KVM support but, in both cases, the same kernel will run unmodified for both the privileged (dom0) and unprivileged (domU) Xen domains so it won't really matter. The current crop of Red Hat xen support tools are designed to plug in xen or kvm support and leave the high level interace well alone so we may well see the kvm-only stance weaken.

  9. Anonymous Coward

    re: Hardware support?

    Redhat is committed to running and improving both and there is even a layer that allows kvm to support Xen VMs.

    Long term you can see a decline in improving the current Xen setup on linux distros due to the burden of support - KVM is a lot easier from the distro viewpoint.

  10. Me Meeson

    Check out

    RedHat already have a virt suite in dev. Check out I would guess that this is the development bed for all virt related progress in RedHat EL.

    It's only at 0.96 at the moment and much of the architecture is still being finalised but it works bloody well and looks to be a Xen killer. VMWare may still beat them with ESX 4 (or whatever it ends up being called) in ease of use (and some funky new direct i/o stuff), but they still can't beat the price of ovirt ;-)

  11. InsaneGeek

    Re: Xen doesn't want to get their code mainstream

    AC: "The xen hypervisor, unlike the VMware and KVM hypervisors, does not sit inside the host OS, it's an OS in its own right."

    That would depend upon the version of VMware you are running ESX it is a hardware layer micro-kernel hypervisor like Xen (VMware workstation and server run inside another host OS). Additionally with Linux kernel 2.6.21 including paravirtops & VMI in the mainline kernel all VMware versions support full paravirtualization of Linux guests as well.

  12. Anonymous Coward
    Anonymous Coward

    RHEL 6

    I reckon they should just role out RHEL 6 early instead of 5.4 and load up OpenSSH 5 with all the lovely chroot possibilities and PHP 5.2 to keep KVM company. And DRBD. Never mind that I don't know what I'm talking about. This is the internet.

    Oh, and for Christmas I'd like a decent Red Hat firewall appliance config tool with inbuilt versioning and support for vlans and DMZs and an easy to use IPSec implementation with selectable profiles for connectivity to third party vendors and the moon on a stick please.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2020