Feeds

Red Hat cranks virtualization power play

Move aside, Microsoft, Citrix, VMware...

Next gen security for virtualised datacentres

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 virtualization since acquiring Qumranet, the creator of the KVM virtualization hypervisor, for $107m in cash last September. After last week announcing an interoperability agreement with Microsoft, which will see Red Hat support Windows instances atop its Xen and KVM hypervisors and Microsoft support RHEL atop its Hyper-V hypervisor, and ahead of VMware's VMworld Europe trade event in Cannes, which starts tomorrow, Red Hat decided it had better explain what it was going to do with KVM.

And so Red Hat today mapped out its server and desktop virtualization plans, which are going to take the next 18 months to get fleshed out with some details and delivered as commercialized products.

"Red Hat is in a power position to set the agenda for virtualization," said Brian Stevens, chief technology officer at the Linux outfit, which is also - by virtue of its JBoss acquisition - one of the key providers of middleware.

Stevens didn't say much on the call except that the broad product offerings would be called Red Hat Enterprise Virtualization and that the company was partnering with chip maker Intel and server maker IBM to bring this KVM-based technology to market. IBM's help seems to be related exclusively to the delivering of virtualization for Linux as it relates to its x64, Power, and mainframe servers.

Red Hat invested more than a year to get the open source Xen hypervisor embedded inside RHEL 5, a project that was announced in November 2005 for delivery in late 2006, but which was pushed out by about six months to March 2007 because Xen was such a moving target back then.

Last year, Red Hat opted to go with KVM because unlike Xen, KVM is part of the mainstream Linux kernel, which means developers are not constantly trying to reconcile the Linux kernel and the Xen hypervisor. (That's why Qumranet is worth $107m in cash, and why Citrix Systems and the open source Xen community it sponsors should try to get Xen mainstream as well.)

And that is why Red Hat is going to be basing its future virtualization strategy on KVM. Consider Xen part of the learning experience and something that Red Hat is happy to support in RHEL 5 as long as customers want to use it.

But starting with RHEL 5.4, KVM will be the default hypervisor inside RHEL not Xen, according to Navin Thadani, senior director of the virtualization business at Red Hat. (This shift is already under way with the Fedora development release of Linux. Fedora 10, which came out in November last year, has both Xen and KVM hypervisors, but Fedora 11, due at the end of May, will default to KVM. The default position on installation is not just a matter of preference, but a signal that KVM will be ready for primetime.

Next gen security for virtualised datacentres

Next page: Inaugural KVM

Whitepapers

Endpoint data privacy in the cloud is easier than you think
Innovations in encryption and storage resolve issues of data privacy and key requirements for companies to look for in a solution.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Advanced data protection for your virtualized environments
Find a natural fit for optimizing protection for the often resource-constrained data protection process found in virtual environments.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.