Red Hat Challenges Ubuntu With KVM Support
After placing its bets for years on Xen, Red Hat moved recently towards official support for KVM, the virtualization hypervisor built into the Linux kernel. Here’s a look at what this change might mean for Ubuntu, which has promoted KVM from the beginning.
Once upon a time, the only reliable virtualization products for the enterprise were expensive proprietary offerings like VMware. In recent years, that’s changed as the virtualization market has diversified widely, with open-source virtualization solutions now readily available for enterprises seeking more flexibility or cost efficiency than closed-source vendors provide.
Xen vs. KVM
Xen, one of the first open-source virtualization hypervisors to become mature enough for production use, was endorsed by commercial Linux vendors like Red Hat and Suse from an early date. In contrast, Canonical, Ubuntu’s parent company, has thrown most of its weight behind KVM, creating tools like ubuntu-vm-builder to simplify management of KVM environments.
These days, Xen and KVM are comparable in performance and features. KVM still has a bit of maturing to do on some fronts, but since it’s integrated into the Linux kernel, it offers less overhead than Xen, as well as a simplified infrastructure.
Red Hat vs. Ubuntu
Red Hat’s decision to offer official support for KVM likely stems from efforts to safeguard its enterprise market share against encroachment by Canonical, which continues to pour resources into developing a foothold on the Linux-server front. But whether the move will pay off for Red Hat remains to be seen.
On the one hand, support for KVM in RHEL 5.4 may convince some customers who would have switched to Ubuntu in order to take advantage of its virtualization tools to stick instead with Red Hat. But in order to keep those patrons, Red Hat needs to deliver a virtualization suite for KVM that’s on par with the infrastructure already built into current Ubuntu releases.
That shouldn’t be a difficult task for a huge vendor like Red Hat to accomplish, especially since the company already has sophisticated management tools like oVirt in place. Ubuntu’s head start in the KVM realm, however, provides an important advantage that might be difficult to overcome–especially since Ubuntu server edition is available totally free of charge, while RHEL requires a license.
The one certainty is that KVM, and by extension all Linux distributions that support it, will benefit from Red Hat’s integration, while the showdown between Ubuntu server edition and RHEL intensifies.
… wtf?!
Red Hat’s decision to support (and encourage the use of) KVM is almost entirely related to: (a) that KVM is actually maintained in the mainline Linux kernel branch while Xen is not, (b) the messy, non-community-focused approach to Open Source and Linux from XenSource, and (c) the acquisition of XenSource by Citrix, which is unlikely to change its previous behaviour for the better.
That Red Hat might take any cues from Canonical in the enterprise/server space right now is laughable, no matter how much we may love Ubuntu.
This may be an Ubuntu-focused site, but please don’t let your analysis be tainted by fantasy.
What Jeff said, plus there’s the little fact that Red Hat own Qumranet who are the people behind kvm.
http://arstechnica.com/software/news/2008/09/red-hat-acquires-qumranet-will-embrace-kvm.ars
Chris:
Define what you mean by advantage. Are you suggesting that Canonical will be able to better monetize their virtualization efforts because KVM equipped Ubuntu has been available now for a while. What do you count as success… number of deployments? That is the absolute wrong metric. What matters is sustainability. Is the effort Canonical is expending on their virtualization strategy producing enough revenue to pay for itself. There is no evidence that it is. Be careful about the sort of business strategies that you are supporting. You don’t run a marathon like you run a sprint.
The very fact that RHEL requires a license may mean Red Hat’s approach is the more sustainable approach for the development of entire virtualization stack. From KVM up into libvirt up into virt-manager up into thincrust. The development of these projects are sustained by the licensing fees being paid to Red Hat. Whose paying Canonical? I can count on one hand the number of Ubuntu supporters who have told me they are paying Canonical for a service contract. Large deployment numbers do not mean its a sustainable business model. Canonical has to find those people out there who are willing to pay or Ubuntu as a project collapses. So cheer on the no acquisition cost model that Canonical is pushing at your own peril.
-jef
While we all love Ubuntu you need a reality check. This article is so far from reality it’s painful.
There needs to be a balance between playing to your audience and basic facts.
“Ubuntu’s head start in the KVM realm ….might be difficult to overcome”
What head start? Red Hat has been developing on KVM for a few years and shipping since Fedora 7.
If you go and look at who is actually developing KVM you’ll find Red Hat, Intel, IBM and Qumranet employees who are now of course Red Hat employees and a few others, you won’t see any Canonical developers there. Why would someone trust a company to run their virtualization platform when that company isn’t equipped to bug fix it !
Or maybe it’s headstart in terms of features? Nope – that can’t be the case because Ubunutu is behind – there’s no memory page sharing (KMS) in Ubuntu’s KVM or SPICE support for accelerated graphics or even PV drivers for Windows guests.
What new features are Ubuntu planning on adding to KVM virtualization? If a Canonical customer wants a new feature they better hope Red Hat or IBM decide to write it. Even Novell are submitting to kvm and they don’t have KVM supported in their distribution.
The tools ubuntu has been shipping like vm builder are all based on Red Hat tools and frameworks like libvirt – the command line tools like virsh and gui’s like virt-manager all come from Red Hat. Even the tool you use to view your VM’s console is developed by Red Hat.
Jeff, Alan, Jef and Ian: you all raise valid points. But in response, I’d argue:
1) if Xen’s design and development context made it inferior from the start, why didn’t Red Hat push KVM from an earlier date rather than focusing on Xen? True, Red Hat shipped KVM along with Xen (it would have been strange not to, since KVM has been in the kernel for a while), but it promoted Xen above all else to customers. It only recently decided to start pushing KVM.
2) it’s true that Red Hat has been a significant contributor to projects like libvirt, virsh and virt-manager (none of which is KVM-specific) and KVM itself, more than Canonical (which isn’t surprising, since Red Hat is much larger). But that doesn’t negate the value of Ubuntu’s early adoption of KVM as its chief virtualization technology, while Red Hat remained focused on Xen. Ubuntu’s infrastructure has been oriented towards KVM from an early date, and that counts for something when it comes to delivering support, packages, etc.
It’s not my intention to downplay Red Hat’s relevance or the importance of its contributions; I just think there’s some value in Ubuntu’s being ahead of the game in regards to KVM.
I think it’s laughable that you even compare Canonical to Red Hat in the server space. Canonical’s developers do little more than organize work other developers have done, and patch some user-space tools. Red Hat on the other hand, does some seriously heavy lifting when it comes to the kernel and virtualization development – especially KVM. I believe they have not opted to use KVM in RHEL until now because their first priority is reliability, and KVM has been rather buggy in the recent past. Given that they are the single largest contributer to KVM, I think it’s safe to say it was always their plan to use it in their offerings.
Don’t forget about VirtualBox.
Chris:
What value does Canonical have by being ahead? They are not staffing KVM developers. For a service company what advantage do they have here really?
I think you need to go back and read up on the full history of xen development and get perspective. There’s a long history associated with xen as a codebase which dates back to 2003. Red Hat’s support for xen was customer driven. I’m going to let that sink in for a second…I know the concept of paying customers is a difficult one to grasp. Red Hat even made a push back in the 2004 timeframe to get xen upstreamed.
And even in 2006, they still felt is was immature. Novell was actually first to market with official Xen support. The Xen history is proof that first to market doesn’t necessarily mean you have any advantage over competitors who are offering the same tech.
http://www.crn.com/software/192201681;jsessionid=BWQWE4VI4KUUTQE1GHPSKH4ATMY32JVN
It’s a complicated history. Casting Red Hat as the champion on Xen is a bit revisionist considering Novell’s role.
You also need to realize that Canonical’s virtualization strategy is still banking quite heavily on Xen. Do I need to remind you that Amazon’s EC2 is Xen based? Canonical backed into support Xen to a significant degree in order to support official Ubuntu EC2 offerings. Its not a KVM or nothing affair for Canonical anymore. Customer demand for Ubuntu Xen guests have affected Canonical’s strategy significantly.
And be careful how you throw around that “but Canonical is so much smaller” argument. You maybe able to use that argument to justify Canonical’s lack of involvement in critical upstream projects to other Ubuntu supporters in a group hug exercise contrived to help everyone feel better about themselves. But when Red Hat and Canonical go toe to toe for customer dollars..that argument will work against Canonical. Size matters not..technical expertise does.
Business is not about hugs and rainbows. Business is about extracting as much value from every dollar spent as you possibly can. When there is actually money being spent on a service contract…who is better equipped to provide service and to help extend the technology for a customers needs? It’s Red Hat’s demonstrable technical expertise that wins them business..paying customers. Canonical’s focus on easy-of-use may win them non-paying friends and supporters…but its not winning them service contracts from people who have difficult problems to solve and are willing to pay for solutions to those problems. And now with Red Hat firmly in the driver seat for KVM development, kvm related service contracts will most likely be going to them..regardless of Canonical’s first to market historic footnote with regard to KVM. We’ll put that footnote on the shelve of irrelevant facts with Novell’s first to market Xen footnote.
-jef
Christopher,
If you go back in time to when Red Hat started to build a supported Xen in RHEL. There wasn’t even a glimpse of KVM. The only reason Ubuntu started offering KVM as their first choice is because they came late in the Linux virtualization game when KVM was the obvious choice.
And Red Hat is not only a significant contributor to libvirt and related technologies, they founded and started their development. And guess why ? To move away the focus and reliance on Xen. So if Ubuntu is able to ship KVM today in its current form, it’s because Red Hat decided they needed to move away from it. Hell, they bought Qumranet before Ubuntu could spell KVM. You think this is strategical or were they cornered by Mark Shuttleworth ? 🙂
One last bit, the reason why Red Hat only now ships KVM with RHEL is because they cannot offer an alternative if it doesn’t meet the same functionality and integration as Xen and something they can support until the product goes EOL.
It must be hard to rewrite history with those pesky Internet users 😉
For once in my life, I’ll completely agree with jdub (Jeff Waugh). You realize that Canonical “threw it’s weight” behind KVM after Redhat bought Qumranet, right? You realize that Avi and the crew from Qumranet were the ones that wrote KVM in the first place, right? I’m guessing not… Do you perhaps work with Matt Drudge?
Chris, addressing your points in turn
“1) if Xen’s design and development context made it inferior from the start, why didn’t Red Hat push KVM from an earlier date rather than focusing on Xen? True, Red Hat shipped KVM along with Xen (it would have been strange not to, since KVM has been in the kernel for a while), but it promoted Xen above all else to customers. It only recently decided to start pushing KVM.”
RHEL 5 shipped 2 months after KVM was merged into the kernel, KVM had been written 3 months before that, that certainly doesn’t qualify as “ready for prime time”. The upstream kernel community (including Red Hat) were all over KVM at this point working it to make it enterprise worthy.
The whole reason for developing tools like libvirt was to abstract the hypervisor to make a transition from Xen to KVM more straightforward
“2) it’s true that Red Hat has been a significant contributor to projects like libvirt, virsh and virt-manager (none of which is KVM-specific)”
Not just a significant contributor – you’re downplaying it – they wrote and maintain it – Canonical are just shipping those tools
“2. …. and KVM itself, more than Canonical (which isn’t surprising, since Red Hat is much larger).”
Canonical aren’t exactly part of KVM – do they even contribute to project? If you scan the kvm patches (and the kernel patches, even X, Gnome, etc) you’ll find that Canonical’s contributions are extremely low – even considering their size, in most cases we’re talking about 0.0x %
“2 …But that doesn’t negate the value of Ubuntu’s early adoption of KVM as its chief virtualization technology, while Red Hat remained focused on Xen”
Red Hat and the rest of the community were supporting Xen while developing KVM. If Red Hat wasn’t contributing to KVM then Ubuntu couldn’t ship it – this applies even before the acquisition
“2 … Ubuntu’s infrastructure has been oriented towards KVM from an early date, and that counts for something when it comes to delivering support, packages, etc.”
Infrastructure? KVM is in the kernel there is no extra infrastructure. The only supporting packages you need are the management packages – which are of course Red Hat packages (libvirt, virt-manager, virt viewer etc)
Raising support is an interesting point to make – do you think Canonical is better equipped to support KVM then anyone else? Considering that Canonical doesn’t (or barely) contributes to the KVM project or libvirt/other tools there ability to support it and fix bugs is limited
“It’s not my intention to downplay Red Hat’s relevance or the importance of its contributions; I just think there’s some value in Ubuntu’s being ahead of the game in regards to KVM.”
But that’s exactly what you did say.
I don’t been to belittle Canonical/Ubuntu here, they play a vital role in the community in terms of user adoption, bug reports, widescale desktop deployments etc. Canonical have/are playing a hugely important role in the community. This does help to balance out the areas where they don’t contribute – eg. core Linux development.
The issue here is that when “fan-boys” blindly criticise other Linux contributors and vendors and disproportionately promote Ubuntu then you’re going to get some factually challenges here.
You also forgot some of the REALLY cool stuff like ovirt (http://www.ovirt.org) which is very close to a stable release. This project will be the foundation of the RHEV virtual management for servers part of the game. Did Canonical write this? nope.
This article is very inaccurate and misleading. It suggests that somehow Red Hat is competing against Ubuntu for enterprise market and playing catch up. This is so far from reality and ridiculous.
Reality: Red Hat created the enterprise linux market and is by far the leader there. Ubuntu is practically non existent in this market and has almost no ISV support at all.
Reality: Red Hat was the largest contributor to KVM even before it bought Qumranet, the developers of KVM.
Reality: Red Hat was the first to include KVM by default in Fedora 7, long before Ubuntu
Reality: Red Hat wrote libvirt, virt-manager and a wide range of virtualization tools
Reality: Ubuntu has zero KVM patches or good virtualization tools on its own. It includes tools that Red Hat developed originally.
One minor nit to pick. In your sentence: “Ubuntu’s head start in the KVM realm, however, provides an important advantage that might be difficult to overcome–especially since Ubuntu server edition is available totally free of charge, while RHEL requires a license.” Technically, that’s not correct. RHEL requires payment for a service contract, I believe. The release, itself, is free.
Ubuntu just has a debian-like community sense which is what Red Hat left for about a decade. Red Hat only has room in the enterprise because of historical reasons, not technical ones. Because WE promoted Red Hat in the enterprise, back in the old days.
Red Hat deserves merrit for the developers they employ, but their business model works very much against Linux propagation in the enterprise.
Microsoft is right when they compare their prices with those from Red Hat; that sucks!
The Red Hat call center even declines their ‘enterprise grade’ support if you upgraded the stone-aged RHEL kernel to the latest vanilla one. Unbelievable for an open source provider; these kind of policies will make them irrelevant; and it’s a pity for those developers with good intentions working for them. Upgrading to the latest vanilla kernel is however necessary a lot of times to deal with new SATA chipsets (so to get the darn thing installed).
But hey, they surely like to backport things… instead of acknowledging that their old reasoning of a linux kernel to needing to be ‘proven by time’ is an outdated reasoning. Which might have been valid in the pre-2.6 days. Or when we tried to look at Sun Microsystems for a valid business model. As Sun has complete control over their own SPARCbased hardware, it doesn’t really matter.
By alienating the community years ago, Red Hat is left with Fedora as an unstable testbed with a very small rpm package base, with a doubtable quality of packages, especially when compared to those in the Debian/Ubuntu world.
yum works much slower than apt-get, isn’t configured by default and compare for example the result of an: apt-get install tomcat5 with a yum install tomcat5, or any more or less non-super-standard yet much used package… the users know why they’re choosing for Ubuntu.
And it makes Debian more popular as ever on the server side. With even Ubuntu server popping up here and there, next to the ubuntu-powered workstations/laptops, in small-to-medium businesses, or even as a pre-configurable choice of distro at large colocation facilities.
RHEL? Oracle is the last reason to deploy RHEL, and as much as we can, we suggest people who run Oracle to use CentOS instead; we feel betrayed by Red Hat and their business model based upon their worthless support and trademark.
RHEL is currently the worst to maintain and support Linux distribution of them all, and hopefully their switch Xen -gt; KVM is a sign that they’re ‘getting it’.
But I don’t think so…
They also should stop patching the linux kernel. That’s only arrogant behavior in which they claim to know it better than the LKML. How do you sell to a customer that the last version of RHEL doesn’t run on his brand new machine and you need to fiddle a few hours extra with it before getting it to boot?
We charge half a day extra if new server setups include RHEL, with ubuntu not. And that’s not purely thanks to ubuntu, but thanks to the people on the LKML who do such a great job of providing us with a great kernel. Ubuntu merely follows the kernel releases more frequently, but that’s all what we ask as users from a distribution provider.
Half a day extra, at our consultancy price; that buys you a cheap last minute ticket to India or the Middle East. Not everybody counts, and some people just like to stick to what they know. But most Linux users change distributions every 3 years or so – I guess that’s the only certainty…
internet,
You are either being clueless or deliberately spreading FUD. Red Hat is by far the #1 linux distribution for the enterprise and they are by far the largest commercial contributor to the Linux kernel. They backport patches and that is the model copied by Novell, Canonical etc.
“The Red Hat call center even declines their ‘enterprise grade’ support if you upgraded the stone-aged RHEL kernel to the latest vanilla on”
This is definitely a lie. Red Hat does not support the “vanilla kernel” on EL at all. It only supports the kernel that it actually ships.
Neo,
I think you nailed it – he’s clueless.
Thank you Jeff, Alan, Ian, Neo.
I feel the true purpose of the article was to create non-existing controversy in the attempt to get this article indexed by as many sites as possible. “It worked, I read it.” And ultimately get some folks to click on the affiliate links on this site.
Oliger:
What you just spoke to is a systemic problem in the newer insta-media culture. It’s not just a technical laypress problem but you see it in more established topical areas like politics. Misinformation can spread like wildfire. You can argue that a certain amount of inaccuracy actually drives readership and the bloggers and journalists are just meeting expectations set by the readership of the new culture. So in a lot of ways the problem stems from how we choose our media sources as readers. We get the quality we deserve and nothing more.
But while the problem is generally applicable across topic boundaries…technology journalism suffers more acutely because technology journalism has grown up in this insta-media culture and there isn’t really a standard bearer for journalistic excellence in the area. Who do you really point to for factual, timely, sober analysis of technology developments and more particularly open source developments? I’ve started to keep a score card for accuracy. Maybe I should start calling people out and driving readership to the people who are consistently better at providing factually correct information.
I will say that at least this site wears its bias openly on its sleeve for everyone to see. The factual inaccuracies are problematic for sure, but having the slant out there as the premise for the site helps as you know exactly why the writers try very hard to paint the picture a certain way. That’s not as clear on some sites.
-jef
What are those KVM management tools for Ubuntu you speak of? The only one I know of is oVirt and while a good tool it’s many years behind VMware in terms of both ease of use (at least in SAN + VLAN deployments) and guest support (for example virtualizing old NT4 boxes is laboursome). I hope that the situation will improve in RHEL6, but I don’t know how an Ubuntu admin does it.
I worked at a reasonably large F500 company and developed their Linux architecture – they were very “big iron”-biased in the UNIX side of their IT shop (e.g., Solaris, HP-UX) – and I can tell you RHEL was the only enterprise-supported Linux under serious consideration for their architecture. We looked at SuSE but I didn’t see the point of going to an also-ran in the Enterprise Linux market. You think a billion-dollar company is going to bank on Ubuntu Server? No way. I think Ubuntu is fine for geeks and to drive Linux desktop adoption (which does have tremendous potential value to the community – though interestingly RH’s Fedora often seems to parallel Ubuntu’s accomplishments in that arena), but clearly RedHat does far more for the Linux kernel and certainly for KVM, than Ubuntu does.