virtualization.info

Today IBM launches version 2 of a new cloud computing platform for software development and testing.
The offering seems similar to the virtual lab automation facility similar to the one that the US startup Skytap offers since April 2008.

CNET reports that this infrastructure-as-a-service (IaaS) cloud is powered by the new Red Hat Enterprise Virtualization Hypervisor (REVH), which is based on KVM.
If confirmed this would be the biggest and most important case study for the new Red Hat virtualization platform at today.

IBM published a short video to show how it works:

This cloud offering is an extension of the platform dubbed Smart Business Desktop that IBM launched in October 2009. That part of the offering, called Smart Business Desktop Clouds, serves virtual desktops, and is powered by VMware, Citrix, Desktone and Wyse technologies.

Ironically, the website section dedicated to Desktop Clouds returns an error, making impossible to access the offering for new customers. The cloud has to be resilient, not the web pages that advertise it.

Update: Red Hat confirms with an official announcement that the new IBM offering is powered by its KVM-based platform. 

Labels: Cloud Computing, IBM, KVM, Red Hat

BrianMadden.com recently published an extensive review of the VDI platform based on KVM that Virtual Bridges offers since December 2009: VERDE 3.0.

Some key points of the review:

• Almost 100% command line oriented (version 4.0, expected for April, will introduce a server management GUI).
• Supported protocols are RDP and Virtual Bridges implementation of RFB (used by VNC).
  VERDE’s RFB is pretty fast, Virtual Bridges claims it is superior to RDP 5.
  The open source version of Red Hat SPICE protocol is unusable, will be adopted in future if possible.
• Active Directory integration is supported through 3rd parties products like Likewise, but there’s no Single Sign On (SSO).
• VERDE Cluster setup is complex, as you have to configure 5 tiers (Satellite Servers, a Master Server, Workstations, authentication servers and storage).
  RDP only partially supported (this will change in version 4.0).
• A proprietary protocol, SMART, is used to synchronize the virtual desktop image between the server and the workstations in offline VDI scenario.
  SMART supports branch office scenarios, with virtual desktop replication across WAN.
• It uses a PDF-based universal printing solution for client-side printing.
• User data is separated from the the OS using a secondary drive letter

Comments are worth a read too as they contain details about pricing. Highly recommended.

Labels: KVM, Reviews, VDI, Virtual Bridges

Archipel is a new open source virtual infrastructure management system based on the libvirt libraries and the Extensible Messaging and Presence Protocol (XMPP, formerly Jabber).

Still in early stage, the tool supports KVM, Xen, OpenVZ and VirtualBox and it’s currently able to operate single virtual machines and VM groups, displaying performance statistics about them.

The interesting twist is that, thanks to the XMPP engine, this console provides instant notification about VMs status to any chat client that supports the (almost) standard protocol.
This means that virtual infrastructure administrators can query virtual machine status through their IM program of choice (like Google Talk or Gmail Chat for example).

To do so, each virtual infrastructure entity, including hosts and virtual machines, appear as an IM contacts,  with its list of “friends”. 
Every management task can be executed through chat messages, and geographically distant virtual infrastructures can communicate through remote XMPP servers.

Labels: KVM, OpenVZ, Oracle, Platform Management, Sun, Tools, Xen

ConVirt (formerly XenMan) is an open source management console that supports multiple hypervisors, including Xen and KVM.
Originally started in 2006, the product was relaunched in March 2009, demonstrating a significant potential.

One year later, the company behind ConVirt, Convirture, releases version 2.0, which once again features notable capabilities:

• new architecture
  made of an AJAX web front-end which supports multiple administrators and a back-end data repository for the entire virtual infrastructure
• performance trends reporting
  capability to produce interactive charts about historical information in the data repository
• template compliance tracking
  capability to track how much a virtual machine changed from its original template and to flag discrepancies
• datacenter-wide monitoring
  both storage and network resources can be monitored from a single console rather than checking each host configuration

The company is still offering the product as open source, but it’s also trying to monetize it with the introduction of an Enterprise Edition (currenty in beta).

This product will add to the open source edition the following capabilities:

• dynamic resources allocation (through the use of resource pools)
• high availability (through hosts and virtual machines fail-over)
• virtual machines backup (both scheduled and on-demand)
• network and storage automated configuration (VLAN and SAN setup across multiple hosts)
• role-based access control
• alerting and email notification
• CLI and APIs

Labels: Convirture, KVM, Platform Management, Releases, Xen

The Novell increased focus on KVM didn’t pass unnoticed.
Several news outlets suggested that this may the first step before Novell abandons Xen, following the Red Hat path, which will ultimately turn into the end of Xen as a community-driven open source hypervisor.

The whole idea is not useful to Citrix, which wants as many partners as possible on its side to validate Xen, and certainly it’s not useful to Novell, which needs to avoid that customers start looking elsewhere (read VMware, Citrix, Oracle).

So while Citrix helped to explain why KVM makes sense in some cases but it’s not a full Xen replacement, Novell somehow clarified its intention to support both virtualization platforms.

Nonetheless, the buzz around AlacrityVM must have pleased the company which felt the urgency to (informally) announce the upcoming full support to KVM in SUSE Linux Enterprise Server 11, to be released later this year.

If the market is really interested in KVM, Novell may leverage the opportunity more than others: the acquisition of PlateSpin gave the company some of the best P2V/V2V migration tools on the market, which will be an easy sell anywhere enterprises want to switch from Xen to KVM.

Labels: KVM, Novell

A couple of weeks ago Citrix announced a new partnership with Novell on virtualization.

The deal includes two parts.
The first one is focused on providing joint technical support to those customers that run SUSE Linux Enterprise Server as a XenServer guest OS.
The second one grants the use of Platespin Recon for Citrix and its Solutions Advisors partners.

While Novell could be considered a Citrix competitor because of its implementation of Xen, the reality is that, at the moment, Citrix has no interest in competing with anybody at the hypervisor layer.
The Citrix strategy is focused on placing XenDesktop on top of every possible hypervisor. And this includes ESX, Hyper-V and of course as many Xen flavors as possible.
So the Novell version of Xen is just an additional opportunity to sell VDI for Citrix.

At the same time the Novell commitment on Xen validates the hypervisor that Citrix is using as main foundation, keeping developers and customers engaged, and Citrix has all the interest to not disrupt it.
The increasing focus that Novell has on KVM must be clarified before customers start to think that yet another vendor (after Red Hat) is abandoning Xen.
This is probably why the Citrix CTO Simon Crosby offered a surprising insight about the value and shortcomings of KVM, the reason behind the Novell and Red Hat decision to invest on it, and the increasing interest for Oracle VM:

…

It's important to realize that for a Linux vendor, KVM significantly simplifies the engineering, testing and packaging of the distro. KVM is a driver in the kernel, whereas Xen, even with paravirt_ops support in the Linux kernel, requires the vendor to pick a particular release of Xen and its tool stack, and then integrate that with a specific kernel.org kernel, and exhaustively test them together - rather than just getting a pre-integrated kernel and hypervisor from kernel.org. So it is entirely reasonable to expect that over time the distros will focus on KVM as a hypervisor. I think KVM is extremely powerful in this context. But ultimately the choice depends on how the end-user wants to acquire/consume virtualization.

If the use case involves the customer buying, installing and running Linux to achieve virtualization, KVM will eventually do a fine job. If on the other hand, the user expects to deploy a virtualization platform that is entirely guest OS agnostic, using a complete virtual infrastructure platform then a type-1 hypervisor that is OS agnostic (xen.org Xen Cloud Platform, Citrix XenServer, OracleVM, VMware vSphere) is what they will go for. I have previously made the case that OS-bundled hypervisors have both inherent advantages and disadvantages in penetrating the market: The opportunity is to supplant the existing OS footprint with a new version of the OS that includes virtualization. The disadvantage is that no OS vendor has yet done a good job of virtualizing its competitors' products, and indeed strategically is never likely to do so. Let's be blunt: thus far they have done a mediocre job at best…

Labels: Alliances, Citrix, KVM, Novell, Xen

When Red Hat announced its decision to switch virtualization technology, moving from Xen to KVM, in June 2008, it generated a lot of buzz.

It was a dangerous move, considering that the platform was pretty new, that its creator and maintainer was a young startup, Qumranet, and that no ISV was actually supporting its applications inside it.
On the other side KVM was integrated in the Linux kernel after just six months of development, and Red Hat eventually acquired Qumranet to get the knowledge, the people and the influence to return the most on its risky investment.
Nobody followed Red Hat: Citrix, Virtual Iron, Oracle, Sun and of course its primary competitor Novell continued to work on Xen.

Fast forward to late 2009: Red Hat is finally ready to unveil its commercial implementation of KVM, introducing Enterprise Linux (RHEL) 5.4, Enterprise Virtualization Hypervisor (REVH) and Virtualization Manager for Servers (REVMS).
Red Hat continues to be the only virtualization player to offer a commercial implementation of KVM, but but things may change soon.

Novell is in fact researching a new hypervisor built on KVM called AlacrityVM:

AlacrityVM is a performance focused hypervisor based on the Linux KVM project. Virtualized environments often impose significant performance penalties against a given workload when compared to native "bare-metal" equivalents. This project is motivated by the belief that it doesn't necessarily have to be this way, nor do we need exotic hardware to achieve it. AlacrityVM demonstrates that most of the existing performance bottlenecks in today's system are simply the result of suboptimal software stacks. By systematically identifying and fixing the weak links in the guest/hypervisor equation, near native performance from a virtualized environment is realistically achievable.
We also aim to add new features, such as the ability to express real-time constraints, network qos, virtual filesystems, etc.

AlacrityVM is in a very early stage (the first public build appeared in March 2009) but it seems that Novell already submitted it to the Linux maintainers for inclusion in upcoming kernel 2.6.33.
Linus Torvalds rejected it saying that there was not enough interest around the project.

Part of the kernel or not, it demonstrates that Novell is considering and investing on Xen alternatives. And this is particularly interesting considering that the company announced its plan to release a lightweight version of their virtualization platform (read: with a stripped down version of SUSE Enterprise Linux) in March 2008 and never delivered so far.

Labels: KVM, Novell

Red Hat recently launched the public beta of its Enterprise Linux (RHEL) 5.5 which introduces the memory ballooning overcommitment technique for KVM.

The beta build finally includes the virtio balloon driver that was missing in RHEL 5.4. This means that KVM virtual machines will be able to change allocated memory at run-time.

KVM got memory ballooning in September 2008 but only now it appears in an enterprise Linux distribution.
Some may argue that this technique alone is not enough to achieve efficient memory overcommitment (VMware for example also uses contend-based page sharing and demand paging) but Red Hat also has content-based page sharing since RHEL 5.4 thanks to the KVM integration with Kernel SamePage (KSP).

Labels: KVM, Red Hat

Fedora, the Linux operating system supported by Red Hat, will reach version 13 in May 2010, and will introduce a number of new features to enrich the KVM capabilities:

• Hostinfo
  Allow a virtual machine to see information and statistics from the host operating system, under narrow and strictly controlled conditions and only at the discretion of the host administrator.
• KVM Stable PCI Addresses
  Allow devices in KVM guest virtual machines to retain the same PCI address allocations as other devices are added or removed from the guest configuration.
  (this is particularily important for Windows guests in order to prevent warnings or reactivation when device addresses change)
• Shared Network Interface
  Enable guest virtual machines to share a physical network interface (NIC) with other guests and the host operating system. This allows guests to independently appear on the same network as the host machine.
• VHostNet
  Enable kernel acceleration for kvm networking.
• VirtAppliances
  Extend support for virtual appliances in management tools.
• VirtAuthorization
  Configuration of fine grained authorization for remote virtual machine management services.
• VirtVNCResourceTunnel
  Provide client access to guest resources such as the serial console, and sound card output, by tunnelling over the VNC connection.
• VirtioSerial
  This feature modifies the current single-port virtio-console device to guests running on top of qemu and kvm. It exposes multiple ports to the guest in the form of simple char devices for simple IO between the guest and host userspaces. It also allows for multiple such devices to be exposed, lifting the current single device restriction.
• Xen to KVM Migration
  Provide nearly effortless automatic translation of Xen virtual machines to KVM virtual machines.
• Xen pvops Dom0
  Dom0 support for pvops-based kernel to support hosting of Xen guests which has been lacking since Fedora 8.
  (currently Fedora releases 11 and 12 contain Xen hypervisor and tools, but Xen dom0 capable kernel is missing)

Of course many of them may be included in the next version of Red Hat Enterprise Linux (RHEL), which gives a good idea of how the KVM platform will evolve.

Thanks to linux-kvm.com for the news.

Labels: KVM, Red Hat, Xen

Just a couple of weeks ago Red Hat made bold move by releasing its remote desktop protocol SPICE, acquired from Qumranet in September 2008, as open source.

The company now offers the SPICE drivers for KVM virtual machines.

The package (for Windows XP only at the moment) creates a virtual GPU called Red HAt QXL and a Virtual Desktop Interface Port.

Administrators are also required to install a SPICE agent inside each Windows guest.
At that point the SPICE client, which is part of the open source release, will be able to connect to the virtual machine.

Thanks to Linux-KVM for the news.

Labels: KVM, Qumranet, Red Hat, Releases

Red Hat embraced hardware virtualization a long time ago by adopting Xen as part of its Enterprise Linux operating system.
Despite that the company never penetrated the market enough to become a serious competitor for VMware, Microsoft and Citrix.
In the attempt to increase its chances to become a key player in the virtualization space, Red Hat is making some courageous choices.

First, it replaced Xen with KVM, becoming the first major vendor to sell and support this relatively new platform inside enterprise (IBM supports KVM too, but just for VDI and just for a very specific software stack).

Now, right before launching its VDI offering, Red Hat has open sourced the SPICE remote desktop protocol, acquired from Qumranet in September 2008. And this is a major step, one of the few that could make a difference.

All the other major virtualization players released or are about to release high performance remote desktop protocols that are optimized for VDI: Citrix has the ICA/HDX, VMware and Teradici just released the software-only version of PCoIP, and Microsoft is expected to integrate the technologies acquired from Calista in its RDP.
On top of these three, there’s a crowd that is pushing for its own proprietary protocol (like VDIworks and Pano Logic) or for its own RDP optimizations (like Quest and Ericom).

In this mess of non-compatible, brand new protocols, an open source alternative is certainly interesting.

The availability of SPICE as open source has many potential ramifications.
First of all, it may immediately attract IBM, which is using the Citrix HDX protocol today for its brand new desktop-as-a-service (DaaS) offering. 
Secondarily, it may be integrated in Xen, which would increase the chances to have major contributors like Oracle.
More than that, it may slip in most thin clients, because vendors are free to extend it and integrate in their devices without having to deal with anybody.
Last but not least, it may receive the support of many cloud providers that, over time, will have to deal with heterogeneous virtualization platforms in their IaaS clouds.

The most important thing, anyway, is that the open sourced SPICE protocol could become part of the Linux kernel. Qumranet already succeeded in a similar challenge with KVM, after just six months of development.
If the Linux kernel will integrate SPICE, every distribution will feature it out-of-the-box in a few months. And this means that every Linux guest OS will be VDI-ready without doing anything.

Of course the success of SPICE will depend much on its performance. Brian Madden published a valuable insight on this very point covering the architecture and features of the protocol.

The open source version of SPICE is available here.

Labels: KVM, Qumranet, Red Hat, VDI

Last week Microsoft and Red Hat announced the certification of their operating systems, Windows and Red Hat Enterprise Linux (RHEL), on each other virtualization platforms, Hyper-V and KVM.

It is a major announcement in many ways.

First of all, customers that have Windows/Linux mixed environments finally have a decent choice. 
Side by side with Novell SUSE Enterprise Linux, now Hyper-V (both R1 and R2) supports RHEL 5.2, 5.3 and the new 5.4.

More importantly, Microsoft and Red Hat validated the use of Windows Server 2003, 2008 and 2008 R2 as guest operating system on the KVM implementation that comes with RHEL 5.4.

On top of that Microsoft has even accepted to provide support to Red Hat users that run most of its enterprise applications inside KVM virtual machines.

Now, and only now, Red Hat has something concrete to tell to the customers.
With the large majority of virtual machines running Windows worldwide, without this mandatory step the new Red Hat offering couldn’t be considered anything more than an interesting future platform.

Thanks to the Server Virtualization Validation Program (SVVP) instead, KVM, or at least the Red Hat implementation of KVM, is at the same level of VMware ESX, Citrix XenServer, Novell Xen and Oracle VM Server in terms of support for Microsoft technologies.

Now Red Hat has to hurry up and show the serious stuff.

Labels: Alliances, KVM, Microsoft, Red Hat

In early September while most of the virtualization community was busy in San Francisco for the VMworld 2009, Red Hat was finally releasing the first piece of its new virtualization offering in Chicago at its Summit 2009.

The market expected the company to launch the new Enterprise Virtualization Hypervisor (RHEVH, a minimal version of RHEL plus KVM that could compete against VMware ESXi or Microsoft Hyper-V Server), and the new Enterprise Virtualization Managers (EVMs) for servers and desktops. But Red Hat only released RHEL 4.5.

In March the company announced that these new products would be released sequentially, starting mid 2009 and for next 18 months, but for now the general public knows nothing but a few technical details unofficially published by some a beta tester.

The ones that attended the Red Hat Summit in Chicago (or visited the Red Hat booth at VMworld) knows more. Luckily, Red Hat published some breakout sessions’ videos of the event, so we all can watch the ones related to virtualization:

Linux-KVM.com published an extensive synopsis of the first one above.
Here’s some points that are worth a highlight:

• Red Hat will support ISV software certified on RHEL whether it’s running on bare metal or running on the RHEL kvm or standalone kvm since it’s the same codebase.
• RHEV standalone kvm has a very small footprint of < 100mb in size which makes it easy to do things like pxe boot it.
• Hosts can scale host to 96 cores and 1TB RAM.
• Guests can scale up to 16vcpus and 256GB RAM.
• Supported Linux guests includes RHEL 3,4,5. Supported Windows drivers available for Windows XP, 2003 and 2008.
• NUMA, power management, memory page sharing (ksm) are some other important features. KSM important for density, very important and will be in product from day 1.
  Light workload VMs on a 48 core machine: 256 GB RAM could run more than 600 VMs.
• Testing results from internal and customers showed SAP workloads: 85-95% performance, Oracle OLTP: 80-92% bare metal. LAMP stack showed better than bare metal performance. Java achieved up to 94% bare metal.
• The management tools will be released in later half of 2009.
  Supports high availability by allowing VMs to automatically restart on other host when host having problems. Supports system scheduler at cluster level, live migration and power saver mode. There’s a maintenance manager that will automatically live migrate vms off servers during scheduled maintenance. Also includes monitoring and reporting tools.
  Support image management including templates and thin provisioning
  
  Note from virtualization.info: Red Hat published a video of Red Hat Enterprise Virtualization Manager on YouTube that we are featuring in the website sidebar and on virtualization.tv.

Labels: KVM, Red Hat, Releases

The formal launch of the new Red Hat virtualization offering based on KVM is just a few days away.

Excluding the products names, so far most Red Hat didn’t disclose any detail about the platform that will replace its previous implementation of Xen.

For the impatient ones, Mark Wilson published some concrete information about this product that are worth a check (our emphasis):

…It’s a standalone hypervisor, based on a RHEL kernel with KVM, and is expected to be less than 100MB in size.

Bootable from PXE, flash, local disk or SAN it will support up to 96 processing cores and 1TB of RAM, with VMs up to 16 vCPUs and 256GB of RAM.

Red Hat is claiming that its high-performance virtual input/output drivers and PCI-pass through direct I/O will allow RHEV to offer 98% of the performance of a physical (bare metal) solution.

In addition, RHEV includes the dynamic memory page sharing technology that only Microsoft is unable to offer on it’s hypervisor right now; SELinux for isolation; live migration; snapshots; and thin provisioning.

…

supporting guests from RHEL3 to 5, and from Windows 2000 to Vista and Server 2008 (presumably soon to include Windows 7 and Server 2008 R2).

RHEV is an x64 only solution and makes extensive use of hardware assisted virtualisation, with directed I/O (Intel VT-d/AMD IOMMU) used for secure PCI passthrough together with PCI single root I/O virtualisation.

…

The real story is with management and Red Hat is also introducing an RHEV Manager product.

I was impressed with (that I don’t remember seeing in System Center Virtual Machine Manager, although I may be mistaken) is a search-driven user interface. Whilst many virtual machine management products have the ability to tag virtual machines for grouping, etc., RHEV Manager can return results based on queries such as, show me all the virtualisation hosts running above 85% utilisation.

…

The third part of Red Hat’s virtualisation portfolio is RHEV Manager for desktops - a virtual desktop infrastructure offering using the simple protocol for independent computing environments (SPICE) adaptive remote rendering technology to connect to Red Hat’s own connection broker service from within a web browser client using ActiveX or .XPI extensions.

Red hat claim that their VDI experience is indistinguishable from a physical desktop including 32-bit colour, high quality streaming video, multi-monitor support (up to 4 monitors), bi-directional audio and video (for VoIP and video conferencing), USB device redirection and WAN optimisation compression…

Thanks to DABCC for the news.

Labels: KVM, Qumranet, Red Hat

In May, during its main conference Synergy, Citrix announced the existence of an open source virtual switch that may compete with the Nexus 1000V that Cisco made available for VMware vSphere.

In early June, the Citrix CTO Simon Crosby shared a very few details about it, but so far most of the virtualization community doesn’t know much about it. But the official website about the project quietly appeared online now: the product is called Open vSwitch and is released under the Apache 2 open source license.

The first release (which is almost complete and available online as well) is designed to support distributed networking (like the Cisco Nexus 1000V) and includes the following features:

• Visibility into inter-VM communication via NetFlow, SPAN, and RSPAN
• Standard 802.1Q VLAN model with trunking
• Per VM policing
• NIC bonding with source-MAC load balancing
• Kernel-based forwarding
• Support for OpenFlow
• Compatibility layer for the Linux bridging code
  (The Open vSwitch can be even used inside a plain Linux distribution in place of operating system bridge)

On top of that the following features are part of the roadmap:

• User-space forwarding engine
• sFlow
• Compatibility layer for VDE
• Ethernet over GRE (for ERSPAN and virtual private network creation)
• Full L3 support + NAT
• Priority-based QoS
• More management interfaces (IOS-like CLI, SNMP, NetFlow)
• 802.1x/RADIUS
• Support for hardware acceleration (VMDQ, switching chips on SR-IOV NICs)

The version available online is near the 1.0 (0.90.4), but it’s only available as source code.
The online documentation already explains how to use it with a XenServer 5.5 host.

Labels: Citrix, KVM, Xen

For a long time a number of contributors sponsored by Red Hat worked on a virtualization interface that could standardize the way hypervisors are managed, getting rid of the differences between vendors’ implementations.

The API is called libvirt and it’s around since early 2006.

Red Hat has a strong commitment on it, at the point that its imminent KVM-based virtualization offering is based on its, as announced in June 2008.
This is why the API is released under the GNU Lesser General Public License (LGPL) which allows the inclusion in any commercial product.

Through libvirt, a management platform running on Linux, Solaris, Mac OS or even Windows can already control both Xen, KVM, Sun VirtualBox, Parallels OpenVZ, QEMU, LXC and User Mode Linux (UML). But the best has yet to come.

The just released version 0.7.0 includes a number of remarkable new features, including support for the IBM POWER hypervisor and what seems a first attempt to support VMware ESX.

Of course this doesn’t mean that VMware will allow a product using libvirt to manage its flagship hypervisor without buying vCenter Server.
But for sure it means that in a near future Red Hat may be able to offer what Microsoft already offer with System Center Virtual Machine Manager (SCVMM): the capability to control multiple hypervisors through a single management console. And this may be extremely appealing for some of those customers that already purchased vCenter.

Labels: KVM, Red Hat, VMware, Xen

Red Hat is definitively preparing for the imminent launch of its new enterprise virtualization offering based on KVM and the Qumranet technologies acquired in September 2008.

A very important piece of the puzzle is how Windows guest operating systems will perform on the Red Hat implementation of KVM.
Most virtual machines on the planet runs Windows, so if Red Hat doesn’t shine here it will have nothing concrete to compete against VMware, Citrix and Microsoft hypervisors.

In mid-July the company gave a hint on how it plans to manage this aspect of its strategy: it released version 1.0 of its KVM para-virtualization drivers for Windows guest OSes under the open source GPLv2 license.

The set includes the network driver (kvmnet) and the device block driver (viostor) and both already are certified against the Microsoft Windows Hardware Quality Labs (WHQL).

Thanks to Linux-KVM.com for the news.

Labels: KVM, Red Hat, Releases

By now most virtualization.info readers should know that Red Hat plans to (finally) unveil its KVM-based virtualization offering on Sep. 1, at the Red Hat Summit 2009 in Chicago (and maybe at VMware VMworld 2009 as well).

The new product portfolio will include not one but two management solutions:

• Enterprise Virtualization Manager for Servers featuring Live Migration, High Availability, System Scheduler, Power Manager, Image manager, Snapshots, thin provisioning, monitoring and reporting.
• Enterprise Virtualization Manager for Desktops (the connection broker and management console SolidICE acquired from Qumranet in September 2008)

While the public knows how SolidICE looks like, nobody really saw the first management solution above, except the few lucky beta testers that Red Hat secretly selected before June.

The only public management solution for virtual infrastructures that Red Hat is working on is called virt-Manager.
The product is promising (supports Xen, KVM and QEMU virtual machines) but it’s in the work since September 2006, it still is at version 0.80 (released at the end of July) and doesn’t seem enterprise-ready at all:

Redhat’s virtual machine manager has come a long way and is starting to show some real usability. I’ve gone from using command line exclusively to now only using command line for testing purposes. There’s still a lot to do but it’s still only version 0.8 and it’s developing at a nice pace. Apart from the bug with creating vms using existing storage, I’ve had no real usability problems with it. I am, however, looking forward to a nicer main viewer.

Hopefully virt-manager is not the product that Red Hat plans to use to compete against VMware vCenter, Citrix XenCenter and Essential, Microsoft System Center Virtual Machine Manager and Oracle/Virtual Iron management platforms.

Labels: KVM, Qumranet, Red Hat

In December 2008 Virtual Bridges closed a major deal with IBM to bundle a Linux-friendly version of its Win4VDI connection broker (called VERDE) with Canonical Ubuntu Linux and the IBM Open Collaboration Client Solution (OCCS), which includes Lotus Symphony, Notes and other IBM products.

The deal was especially relevant because this bundle was designed to deliver a VDI solution based on the KVM virtualization platform that Ubuntu embeds. And IBM was the first major ISV to support its enterprise products inside KVM virtual machines.

Eight months later Virtual Bridges, IBM and Canonical are back with VERDE 2.0.

The first new thing in this release is the product strategy: Virtual Bridges completely replaces Win4VDI with VERDE, avoiding to market and sell two different versions of the same connection broker.

The second and most important news is related to a new key component of the package: a client-side virtualization platform.

The press announcement mentions the term client hypervisor, but in this case we are talking about a lightweight Linux distribution with KVM (which is not a hypervisor architecture).
Like over client hypervisors, this one requires Intel VT enabled so it won’t work on some laptops (courtesy of Sony and Intel).

The virtual desktop can be checked out and copied on the local KVM platform, allowing the mobile user to work in a so-called offline VDI mode.
At that point VERDE 2.0 uses a new Self-Managing Auto Replicating Technology (SMART) protocol to synchronize the local virtual desktop image with the primary one that resides inside the corporate virtual infrastructure.

Labels: IBM, KVM, Releases, VDI, Virtual Bridges

Oracle continues to stay mum about its integration plan for Oracle VM, Sun xVM Server and Virtual Iron hypervisors, but don’t hold anything when it’s time to talk about the new competitors.

Just two months ago the company dismissed the VMware virtual appliance initiative and its Marketplace, saying that it doesn’t contain anything but toy appliances.
One month later Oracle decided to clarify how the word co-opetition is not in its vocabulary, modifying the support policy to exclude every virtualization vendor that offer a hypervisor for x86/x64 architectures.

Today it’s time to hit Red Hat (and by some degrees Novell).
On its corporate blog last week Oracle highlighted its commitment to Xen and the open source:

…Oracle's Linux commitment began in 1998 with the first commercial database on Linux. Not only does Oracle run the whole business on Linux, but also run the base development on Linux for all our products. Today Oracle has over 9,000 developers working on Linux and provides Global Linux Support in over 100 countries…

The key point of this apparently candid post is about the quality of support that only Oracle can offer.
To support the statement Oracle points to another article about the reasons behind the launch of Oracle Unbreakable Linux:

Oracle Unbreakable Linux launched two years ago as a support program for existing Red Hat Enterprise Linux (RHEL) implementations or for new Oracle Enterprise Linux implementations. Oracle Unbreakable Linux program is about enterprise-class support that customers can't get (or is not available) from Red Hat.

…

Oracle brings the highest support quality, more value, and proven business practices to Linux support, including the following items Red Hat can't:

• 7500+ professionals providing 24x7, global support in over 145 countries
• Lifetime support policy (7+ years of general product support with the ability to extend to unlimited number of years)
• Premier backporting (Request backport of specific features eliminating pressure to upgrade with every update release)

…Due to dissatisfaction with Red Hat's quality of support as well as a desire to get more value, many users have switched from Red Hat Support to Oracle Unbreakable Linux Support…

The message is specifically directed to Red Hat because Red Hat is the company that promoted Xen for years and then decided a complete U turn by replacing the open source hypervisor with KVM.

Red Hat will (re)start competing with the other virtualization players in September when its new offering will become finally available.
And before any customer even think about jumping on the KVM bandwagon, Oracle wants to make sure that everybody knows how much better they are at support.

Labels: KVM, Oracle, Red Hat, Xen

We still don’t know anything about the new Red Hat virtualization portfolio based on KVM and Qumranet VDI technologies, despite a (claimed) oversubscribed beta program that nobody was able to access.

A key piece of this offering of course is Red Hat Enterprise Linux which was expected to drop Xen in favor of KVM as the default virtualization engine.
The release notes of the just announced beta of RHEL 5.4 confirm this.

The KVM version included in RHEL 5.4 will support RHEL 3.x, 4.x and 5.x guest OSes along with Windows XP, Server 2003 and Server 2008.
All of them are supported in 32 and 64bits, and each OS will be able to run without installing any para-virtualized (PV) driver, despite these components will be available as part of the distribution. 
No mention of Windows Server 2008 R2 and Windows 7 which will hit the RTM next week.

The Red Hat customers using Xen are not entirely left in the cold but their life will be much harder now:

Xen based virtualization is fully supported. However, Xen-based virtualization requires a different version of the kernel to function. The KVM hypervisor can only be used with the regular (non-Xen) kernel.

While Xen and KVM may be installed on the same system, the default networking configuration for these are different. Users are strongly recommended to use one hypervisor at a time.

This beta shouldn’t run more than a couple of months as Red Hat plans to release the new products on September 1, according to LeMagIT.

Labels: KVM, Red Hat

Ten days ago Red Hat announced that its new, much awaited, virtualization offering based on KVM was in beta and that the beta program was oversubscribed.

The reality is that, as far as we know, Red Hat never announced the beta program or the details of its implementation of the Qumranet technology (acquired in September 2008), and never gave the opportunity to sign for it to the general public.
Still today there not a single bit of information about what Red Hat did in one year and a half after dropping Xen in favor of KVM.

Red Hat will take another two months to finally tell the world as LeMagIT revealed earlier today: the general availability of the new virtualization platform is in fact planned for September 1, 2009, which means during the VMware VMworld 2009.
Too bad that this year VMware is not particularly happy to have competitors showing their solutions on the exhibit floor.

Labels: KVM, Red Hat

One of the oldest (and hottest) topic in the history of modern virtualization is if the Xen open source hypervisor can be integrated into the Linux kernel or not.

XenSource tried to achieve the goal for years (while VMware did its best to avoid it), but in December 2006 Linus Torvalds announced the decision to include another virtualization platform in place of Xen: KVM.

KVM was developed and maintained by the startup Qumranet, acquired by Red Hat in September 2008, and at that time was just 6 months old, much less mature than Xen.
Despite that and because of its architecture (at least this is the official reason), KVM has been included in the kernel since version 2.6.20 and Xen is not.

After this and after the acquisition of XenSource by Citrix, the idea of Xen inside Linux seemed definitively archived. But the community is still debating about the topic.

Torvalds’ comment on the idea is lapidary:

…If Xen was a single driver thing, we wouldn't have this discussion. But as is, Xen craps all over OTHER PEOPLES CODE. When those people then aren't interested in Xen, why is anybody surprised that people aren't excited?

Thanks to c0t0d0s0 for the news.

Labels: KVM, Xen

In the past months virtualization.info highlighted several times how Cisco is silently using KVM as an alternative virtualization platform to VMware.
We always wondered why, considering the investment that Cisco made on VMware.

Now, finally we have an answer to give: Cisco invested in Qumranet too.

Qumranet is the startup that developed and maintained KVM up to the moment it was acquired by Red Hat.
And that’s why Red Hat had a minor but very relevant position during the launch of the Cisco Unified Computing System (UCS) despite its virtualization offering is pretty weak now.

The fact that Cisco invested in Qumranet is not widely known and we had to admit that even virtualization.info overlooked this key information so far.
How the investment links Cisco to Red Hat is not clear but it’s easy to guess that the upcoming Red Hat new virtualization portfolio based on KVM will have an early chance to be bundled with UCS.

Now VirtualLogix, the mobile virtualization startup where Cisco invested along with Intel, is the next most interesting company to watch.

Labels: Cisco, KVM, Red Hat

The article appeared on WorksWithU may be the first documented case of a company deciding to adopt KVM instead of VMware or Citrix hypervisors.

To be fair the scenario described by the author is at the lowest limit of the SMB range: a mere two virtual machines for a single virtualization host.
Yet, it’s interesting to read the reasons behind the choice to go for KVM on Ubuntu rather than VMware ESX or Citrix XenServer:

1. Cost.  Although our virtualization requirements are minimal–we need to run only two guest servers on a single host machine–VMware would have cost an astonishing amount of money.  With features like VMware motion factored in, we were looking at a huge hit to the budget–and it didn’t help that VMware charges per CPU, not machine, regardless of whether all CPUs will actually be dedicated to virtualization.  KVM is totally free, in both senses of the word, and offers functionality equivalent to VMware motion.
2. Ease of deployment.  Installing KVM on Ubuntu 8.04 is as simple as an apt-get.  ESX server is also easy enough to install, but having to deal with licensing adds another layer of complication that we’d prefer not to face.  KVM, of course, requires no license.
3. Speed.  Although I don’t have hard numbers, KVM-based virtual machines definitely ‘felt’ more responsive than those running on VMware.  Our experience seemed to confirm Red Hat’s claim last fall that KVM can support five VMs for every three running on VMware on the same piece of hardware.  It was also troubling that ESX server wasted upwards of 500 megabytes of memory–without any VMs running–on system overhead, while an Ubuntu server is a considerably more efficient host.
4. Management.  Apparently it never occured to VMware that systems administrators might be running Linux on their workstations.  As a result, Windows is the only platform on which VMware’s graphical management infrastructure is supported.  A Linux CLI client is available, but I’d like more options than that.  KVM, in contrast, can be managed via the command line, via graphical interfaces (running either on the local machine or forwarded over ssh to a remote workstation) or through the Enomaly web interface.

Be sure to read the whole article to fully understand the process that led to this choice.

Labels: KVM

Earlier this week SDTimes published a brief coverage of the Linux Foundation’s Collaboration Summit, which was held in San Francisco last week.

A very brief note in the article highlights a remarkable information:

For the virtualization crowd, Zemlin [Jim Zemlin, Executive Director at the Linux Foundation] said that, moving forward, the Linux Foundation is encouraging vendors and developers to standardize on KVM, not Xen.

If true this may be the confirmation that the Citrix acquisition of XenServer has compromised the relation with the open source community, despite Citrix is giving back.

It’s interesting to note that the Red Hat acquisition of Qumranet, which developed and maintains KVM, didn’t have the same impact.

Labels: KVM, Xen

In 2006 the ConVirt team started an ambitious project: develop an open source, multi-host management console for Xen.
Initially called XenMan, the tool was then renamed ConVirt and its roadmap was enriched with several highly desirable features.

Three years later the ConVirt team morphs in a company called Convirture, and ConVirt, still an open source product, finally reached version 1.0 with a notable number of features:

• Support for Xen and KVM
• Support for multi-host virtual infrastructures
• Support for virtual machines snapshot, live migration, backup and decommission
• Support for VMs templates and virtual appliances
• Support for storage usage

The product is available free of charge here.

Labels: Convirture, KVM, Xen

With the acquisition of Qumranet in September 2008 Red Hat raised a lot of interest.
The customers that trusted the company when it was promoting its Xen implementation all over the place want to know what will happen to them.
The potential customers that are interested in an open source hypervisor but  dislike the idea of Citrix indirectly controlling how Xen, want to know how serious Red Hat is about KVM.

Last week, finally, the company announced its commitment:

• Next versions of Enterprise Linux (RHEL) will feature KVM.
  The exiting versions featuring Xen will be supported for the full lifetime of RHEL 5.
• Red Hat will release a brand new Enterprise Virtualization Hypervisor (a minimal version of RHEL only supporting KVM and a selected number of drivers).
• Red Hat will release a brand new Enterprise Virtualization Manager for Servers featuring Live Migration, High Availability, System Scheduler, Power Manager, Image manager, Snapshots, thin provisioning, monitoring and reporting.
  This product will be able to manage both RHEL and RHEVH.
• Red hat will rebrand the Qumranet connection broker and management console SolidICE as Enterprise Virtualization Manager for Desktops.

All the products above will be delivered sequentially over the next three to 18 months, with delivery dates beginning in the middle of 2009.

Of course the biggest concern about KVM is that ISVs are not supporting it. And because something like 95% of the existing virtual machines run Windows guest operating systems, a partnership with Microsoft is fundamental.

This is why just two weeks ago Red Hat joined the Microsoft Server Virtualization Validation Program (SVVP).
Without it, the company could sell its new virtualization platform only to those customers that run Linux guest OSes, and that is a small niche compared to the huge virtualization market.

Yet, much depends on how the new platform will be priced (something that the company didn’t announce yet).
The free XenServer can damage Red hat much more than VMware.

Labels: KVM, Qumranet, Red Hat

One of the biggest challenge when adopting a new virtualization platform is securing the ISVs support.
Without it moving from the market leader to a more innovative or cheaper solution is a risky business.

It’s the case of KVM, the open source virtualization platform that is part of the Linux Kernel since version 2.6.20 and that is attracting a large number of developers (away from Xen, we were told).

KVM may be very cool, and the fact that Red Hat acquired its maintainer, the startup Qumranet, certainly ignites high hopes for the platform.
But the reality is that, at today, KVM is still too young to feature the ISVs support that VMware, Citrix or Microsoft can offer.

Excluding IBM, which just started to its Lotus Notes, Symphony and a bunch of other applications on the Virtual Bridges implementation of KVM, no other major IT vendor is officially endorsing KVM.

As often happens, Microsoft is the key to change this situation: it’s now more than clear that virtualization is being used across the globe to virtualize and consolidate in large majority Windows boxes.
If Microsoft officially supports Windows in a KVM virtual machine then the other ISVs will follow, and the customers can start adopting the solution with confidence.

With much surprise it’s possible that the unlikely event already happened.

As most readers remember Cisco is using a mysterious virtualization platform inside its Wide Area Application Services (WAAS) 4.1 appliance. 
Despite the company stays mum about the VMM used inside WAAS, in the past months virtualization.info received a remarkable number of confirmations from different sources that the appliance is almost certainly powered by KVM.

Now Cisco is selling WAAS 4.1 and its new virtualization capabilities certifying its use as a platform where the core Microsoft services (part of Windows) can be consolidated.
To do so Cisco joined the Microsoft Server Virtualization Validation Program (SVVP) in August 2008. But the SVVP program doesn’t include Windows support.

This means that, through the SVVP program, Microsoft is supporting its core services inside the Cisco WAAS 4.1 virtual machines (which are, we are almost sure, KVM virtual machines), but not the operating system itself.
So, who is supporting Windows exactly? 

The only two possibilities are that Cisco is in charge for the OS support, and it seems unlikely, or it’s Microsoft that is making an exception and is supporting its operating system inside KVM, at least the Cisco implementation of it.

The reason why all these details are unclear, and Cisco customers should investigate before buying WAAS 4.1, is the business relationship of the two software giants: Cisco is definitively in bed with VMware and it’s preparing to make a major announcement, while Microsoft is totally in love with Citrix, which probably isn’t too happy to know that KVM is being supported so quickly.

If it will emerge that Microsoft officially supports Windows on KVM, this may further boost the Red Hat chances to attract customers with its upcoming new virtualization platform.

Labels: Alliances, Cisco, KVM, Microsoft

Yesterday the open source virtualization KVM reached another milestone: the build 83 now includes support for the AMD Input Output Memory Management Unit (IOMMU) technology.

An IOMMU makes I/O virtualization more efficient by allowing VMMs to directly assign real devices to guest operating systems. It's not possible for a VMM to emulate the translation and protection functions of an IOMMU, because the VMM can't get between kernel-mode drivers running on the guest OS and the underlying hardware. So, in the absence of an IOMMU, VMMs instead present an emulated device to the guest OS. The VMM then translates the guest's requests, ultimately, into requests to the real driver running down on the host OS or on the hypervisor.

Less than one month ago the version of KVM that is included in the Linux Kernel 2.6.28 introduced the support for Intel IOMMU called VT-d.

Now both implementations are supported and the AMD patch will soon reach the mainstream kernel (probably 2.6.29).

Labels: KVM, Red Hat

The just released Kernel 2.6.28 includes more than 104 patches for the virtualization engine KVM, included in Linux since 2.6.20.

One of those patches is specially important as it allows the mapping of physical PCI device to a specific virtual machine through the Intel Virtualization for Directed I/O (VT-d) technology.

Intel introduced VT-d in early Q1 2006 but so far only Novell and Oracle supported it in their Xen implementations (as the virtualization.info Buyer’s Guide highlights).

The PCI direct access grants higher performance but lower flexibility in a virtual infrastructure: for instance a VM can only map as many devices as are physically present in the platform.
Nonetheless it’s a critical step to bring high-performance virtualization on consumer equipment (something often called client hypervisor) like laptops.

Red Hat, which is the main contributor of KVM after the acquisition of Qumranet, has all the interest to achieve the goal as the company executives clarified last month.

Meanwhile KVM continues to get new features: in its last build, KVM-82, the platform allows users to nested virtual machines when running on AMD CPUs.

Labels: KVM, Red Hat

Virtual Bridges is a company founded at the end of 2006, that always offered commercial flavors of QEMU for Linux, BSD and Solaris platforms.
After KVM made its appearance Virtual Bridges started to implement support for it on its products for Linux. Where KVM is not available KQEUM is automatically used.

In August it significantly extended its scope by releasing its first VDI connection broker for KVM: Win4VDI.

Compared to other products in this space, Win4VDI doesn’t connect the user to the actual guest OS, but rather to the underlying host. From there the user session is started.
In this way Virtual Bridges can leverage the authentication methods and profiles that the host is using.

The choice has been courageous.
Even if KVM is part of the Linux kernel and even if its maintainer, Qumranet, has been acquired by Red Hat, the spread of a new virtualization platform must surpass a huge obstacle: the ISVs support.
And at this point no ISV formally supported its applications inside KVM virtual machines.

Despite that, Virtual Bridges has been rewarded as IBM just closed an agreement with them to resell a bundle made by:

• Canonical Ubuntu Linux (which is adopting KVM in place of Xen since February)
• Virtual Bridges VERDE (a subset of WIN4VDI that only supports Linux guest OSes)
• IBM Lotus Symphony, Lotus Notes and the other Lotus applications (dubbed Open Collaboration Client Solution)

The whole package is available at $49 per concurrent user.

So the move is remarkable because IBM is the first big player supporting (and actively selling) KVM-based virtual infrastructures. But it’s also remarkable considering how heavily IBM invested in Xen in the past.
After the acquisition of XenSource by Citrix, a number of entities behind the open source hypervisor development were reportedly unhappy and decided to shift to KVM. And this seems the first concrete step that demonstrate how unhappy IBM is about Xen.

True or not, looking at what IBM just did, we can have an idea of what Red Hat could do.
The difference between the two vendors is that Red Hat is in a much better position to sell an out of the box VDI package: it controls the operating system, it (indirectly) controls the virtualization platform, it controls the connection broker, and its role in the industry as OS provider certainly gives much influence on what ISV applications will be supported on top.

Now, considering that, besides Qumranet, Virtual Bridges is currently the only other vendor offering a connection broker for KVM and that its experience has to be somewhat limited, the real question is: why IBM didn’t do this with Red Hat instead of Ubuntu and Virtual Bridges?

Labels: Alliances, IBM, KVM, Virtual Bridges

Two weeks ago the Red Hat CEO hinted at his upcoming virtualization strategy but was careful enough to not say when KVM would be integrated into the company enterprise distribution.

Now CBR reports that Red Hat may be ready by the first half of 2009.

By that time the company will completely replace Xen with KVM in Red Hat Enterprise Linux (RHEL), but will continue to offer support for the former virtualization plaform for another seven years.

The company Vice President for EMEA, Werner Knoblich, insisted that KVM is better than Xen (or VMware ESX) when talking about large-scale deployments (thousands of virtual machines) because the virtualization engine fully leverages the Linux kernel capabilities while the bare-metal hypervisors cannot.

True or not, such comment highlights how Red Hat is looking at KVM for cloud computing much more than for server consolidation.

Labels: KVM, Red Hat

Since months now a serious number of companies and open source contributors is looking at Red Hat to understand its new virtualization strategy.

The company took a major step in June when it thrown out of window years of efforts on Xen to fully replace it with KVM.
Just two months after, Red Hat acquired Qumranet, the company that started KVM, that maintains it, that managed to inject it into the Linux kernel, and that sells a very interesting VDI solution.

What Red Hat wants to do now with KVM and Qumranet (somebody hopes that their highly performing VDI protocol SPICE will be open sourced) is critical to understand what chances has Linux to impose itself as a valuable virtualization platforms against the popular hypervisors ESX (offered by VMware) and Xen (offered by every other vendor except Microsoft).

Some hints of the new strategy surface in a recent interview that InformationWeek arranged with Jim Whitehurst, the Red Hat CEO:

Q: What is Red Hat's strategy with virtualization?

A: …We'll be offering both server and desktop virtualization. The first use-case of server consolidation is just the tip of the iceberg. There's a long-term use for grids of servers running large numbers of desktops. We plan to be the leading virtualization vendor based on the server operating system…

Q: What about cloud computing?

A: Clouds will run Linux.

It’s clear that Red Hat sees in KVM a huge opportunity to differentiate from Citrix, Virtual Iron, Oracle and its worst competitor Novell.
Now the company has to to execute in a much better way that how it did with Xen.

Labels: KVM, Qumranet, Red Hat

At the end of last week AMD announced a breakthrough achievement: migrating a running virtual machine from a virtualization platform to another, each running different CPU brands.

Despite many progresses in this area (AMD-V Extended Migration and Intel Flex Migration), so far the only thing possible was to live migrate VMs between different CPU families of the same vendor.
AMD and Intel never cooperated as much to cross such boundary and in one case we are pretty sure that an Intel executive said that the thing would be unlikely to happen.

Now AMD has found a way to mask the CPU information and operate the migration from an Intel Xeon DP Quad Core E5420 to its own forthcoming 45nm Quad-Core Opteron.
To achieve the goal the company worked together with Red Hat so everybody would expect that the migration happened through Xen hypervisors. It’s not the case.

Red Hat fully embraced KVM as replacement of Xen in June and this is the virtualization platform that was used for the demo:

Labels: AMD, KVM, Red Hat

It may be just a coincidence but the just released Fedora 10 doesn’t include Xen. And this happens just a month after Red Hat unveiled its new virtualization strategy, adopting KVM and acquiring the startup that maintains it: Qumranet.

The reason behind this unexpected drop is explained in the official project newsletter:

No Dom0 Support in Fedora 10

…”There is pretty much zero chance that Fedora 10 will include a Xen Dom0 host. While upstream Xen developers are making good progress on porting Dom0 to paravirt_ops, there is simply too little time for this to be ready for Fedora 10. So if you need to use Fedora 10 as a host, then KVM is your only viable option at this time. If you can wait for Fedora 11 (or use RHEL-5 / CentOS-5) then Xen may be an option for you." …

The distribution lifecycle implies a new major release every six months on average.
This means that Fedora users will have a long time to explore the opportunities that KVM offers. And in the meanwhile Red Hat will be able to further attract them with some new interesting products based on Qumranet technology.

Thanks to Mike DiPetrillo for the news.

Labels: KVM, Qumranet, Red Hat, Xen

Now that Red Hat acquired Qumranet, the maintainer of KVM, the interest around the open source virtualization engine included into the Linux kernel is raising over the top.

Those customers considering the product should be happy to know that the newest version, KVM 75, introduces the memory ballooning.

The ballooning is the most common approach to achieve memory overcommit, a feature available only in VMware ESX at today.

While the real value of ballooning has been questioned several times, it’s really notable to see that the youngest newcomer in the virtualization arena is already stacking up the right features to compete with the most mature products.

Of course KVM is too new and its diffusion too limited to really prove its reliability against the well-known competitors. With or without cutting-edge features, Red Hat will have to work a lot to build confidence in the new platform.

Labels: KVM

Red Hat just announced that it acquired the VDI startup Qumranet for $107M.

The startup left the stealth mode in September 2007 and has just 60 employees, all of them will keep their work as Red Hat employees.

The move is critical and has a major impact on many aspects of the virtualization world.

The Qumranet strategy
Qumranet offers an interesting VDI solution made by a  management console, a connection broker and a new remote desktop protocol.
But more than that, Qumranet maintains KVM, the new virtualization platform that has been implemented in the Linux kernel after just six months of development.

KVM allows any Linux box to become a virtualization platform, and KVM is the only company at the moment able to offer a VDI solution for KVM.
This means that customers looking for cheap, large-scale virtual desktop infrastructures have to buy the Qumranet solution.

The Red Hat strategy
In the last few years, despite a number of announcements, Red Hat didn’t demonstrate a neat strategy about virtualization. But in June the company officially declared its intention to move from Xen to KVM.

Just two months after, a Red Hat executive formally revealed the company interest in VDI. At that point it was easy to forecast a special deal with Qumranet.

(it seems that when virtualization.info presumed the acquisition, the deal was already signed)

Buying Qumranet Red Hat just solved a number of problems:

• obtaining direct control on the development of a virtualization engine (something that the company was never able to do with Xen because of XenSource, and even less after XenSource was acquired by Citrix)
• obtaining a platform which is ready for virtualization ubiquity (KVM is flexible enough to be deployed on servers, desktops, embedded devices and anywhere Linux can fit)
• obtaining a strong position in the growing VDI market
• differentiating its virtualization offering from the competitor Novell (both are currently adopting Xen)
• enforcing its position of open source leader while the competitor Novell is seen as a suspicious Microsoft ally

Both Citrix and Red Hat acquired a virtualization company that develop and control an open source virtual machine monitor (VMM). But there’s a major difference between the two companies.

Citrix never had an involvement in the open source world, and despite the culture introduced by Simon Crosby and his staff (and their tireless efforts), the community has a hard time in recognizing Citrix as a company that can give back. When talking about virtualization Citrix is first and foremost seen as the best Microsoft ally against VMware.
Red Hat instead is a beloved, open source paladin. The company made some mistakes in the past, but its effort in supporting Fedora still makes it a leader in the Linux world.
This difference is now specially important: some entities currently contributing to the Xen development may find much more interesting to work with Red Hat rather than with Citrix (think about IBM).

At the same time some firms heavily relying on Red Hat (think about Oracle), may be in deep trouble now that the company is definitively replacing Xen with KVM.
These entities may need to look at Novell now, or start working on their own implementations.

In any case the acquisition of Qumranet is a major achievement for Red Hat, which has now a unique opportunity to become a real virtualization leader.

Labels: KVM