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 …
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.
http://blog.codemonkey.ws/2008/05/truth-about-kvm-and-xen.html
"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.
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.
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.
RedHat already have a virt suite in dev. Check out ovirt.org. 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 ;-)
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
