Xen Not Ready for Prime-time, says Red Hat

daria42 writes "A senior Red Hat executive today maintained the Xen open source virtualisation environment was not yet ready for enterprise use, despite 'unbelievable' customer demand and the fact rival Novell has already started shipping the software."

Comments

what is ready?

[doktorjayd]

i run about 40-50 xen clients on a handful of moderate server hosts.

perfect for dev work. i mean PERFECT

quickly reproducible, adjustable resourcing, and lets me give devs root acces on their own clients.

i presume the redhat dude meant was 'redhat isnt ready to commercially support xen'

----
what, read the article? pfft.

Re:what is ready?

[LWATCDR]

And of course nVidia's driver doesn't like XEN. The free one does seem to work but then you are left without a lot of features.
Heck right now if you want a good Xen workstation you better forget about AMD.
Intel does have the VT extensions out and they have an okay 3d video chip set that has full FOSS support.
I have been an AMD fan since the K6-2. Right now for Xen Intel seems to be the way to go.
Drat.

Re:what is ready?

[Anonymous Coward]

AMD has its own virtualisation technology which goes far beyond what Intel has to offer, promising even more performance under virtualisation.

Keep one thing in mind

[Andy Dodd]

This isn't a case of RedHat FUDing a competitor - RedHat is a Xen partner and thus has (some sort of) a vested interest in Xen succeeding.

RedHat just doesn't yet feel that the time is right, but unlike other companies who like to FUD their competitors, RedHat wants the time to eventually become right so that they can comfortably include Xen into their products.

Re:Keep one thing in mind

[twiddlingbits]

Sun has heavily invested in Xen, and I wouldn't be surprised to see them BUY Xen. Then Xen technology is in the next release of Solaris. Solaris 10 is RH's #1 competitor at the Enterprise OS level (and beats it in many ways). So if they can throw out some FUD and screw up Sun they are going to do it. After all they learned from what MS has done to Linux and how well that worked. Right now, TODAY, if I had to do virtualization I chose VMWare or Solaris 10 using Containers.

RedHat's Ties to VMware

[GoRK]

This isn't really that much of a suprise. RedHat has some fairly deep ties into VMware. They are one of the only 'officially supported' Linux guest operating systems that VMware will run (of course it also runs everything else just fine). The VMware service console of ESX is based on RedHat, etc. They have a pretty good track record there, and I suppose that it is worth it from this standpoint to maintain the relationship. I also imagine that they get a kickback from VMware whenever ESX is sold since it basically includes RHEL3 -- either that or VMware is paying them a lot of money --

FWIW, I agree with them on Xen even though I hate RedHat. Xen is a great performer and a very capable platform, but management is difficult and it is still lacking a lot of important features that VMware implements. This is part of the reason for the performance hit of VMware ESX vs Xen. When Xen gets up to a very equivalent feature level I think that you'd see the performance gap is going to be a lot smaller. In a hosting application or something when your company can afford the overhead of maintaining Xen -- go for it. If you are actually worried about maintaing the VM's and can't take the extra headache of being a Xen admin as well, go for ESX.

Re:software virtualization is SO last century!

[rfc1394]

So Xen isn't ready for "prime time" yet. Yawn. So what? It's a software kludge that gives low-end (read: "x86") servers a subset of the partitioning capabilities that IBM's Power processors have had for years.

They simply said they felt that it is not ready now and not that it wouldn't be ready. If you had read the article further, it would have noted Red Hat has been working with the software and wants to implement it in their next release. Red Hat tends for more stability over functionality. Novell is including Xen in Suse because customers who want inexpensive virtuality (if you're willing to pay for expensive virtuality you buy VMWare) are willing to put up with the headaches that the software is in its current state, and for a technically savvy customer giving them something over nothing is a whole lot better. These are different choices in how you offer your operating system to the customer, and both are valid strategies.

If you want mission-critical reliability, you should be running hardware that is mission-critical reliable. Hint: that ain't Intel.

Most commodity hardware is extremely reliable (compared with the dreadful reliability of software) and is comparable to most consumer equipment; when is the last time a TV set failed or exploded (other than the software in it getting into a bad spot and you're having to turn it off to reset it)? The days of demanding very expensive extremely mission-critical systems are over because we don't need absolute reliability in the specific hardware, we need it in the overall system. What you really need in a mission-critical system is dependable fallover/failover in the event of failure of any specific component. If a processor fails you need a method to move work to one that has not failed, and so on. Mission critical hardware provides expensive reliability through redundant hardware and hardware-based monitoring systems. If you can get that through use of inexpensive commodity components, and perhaps some less-expensive system to monitor them, then it doesn't matter that you've used less-reliable (cheaper) components as long as your system will do fallover to non-failing components correctly if a component fails.

Let me give an example. If you were doing transmission routing for an internet-based company, you could spend $60,000 to buy a Cisco router. Nice, reliable technology. Or you could do the same thing by installing 60 used computers that each one alone could handle the routing load and cost $100 apiece, plus $100 for a gigabit ethernet card. What are the chances that your $6,000 stack of 60 boxes will all fail, even though some of them might? Now, granted they'll use more electricity, but if they together cost an extra $180 a month in power and a/c costs, in five years it still will only cost you less than $10,000. Your network will do the fallover automatically if one of your 60 "switches" fails. Now, for those reading this adjust for whatever you would use, but I think the concepts are valid; lots of inexpensive "fallible" commodity equipment can do the job of much more expensive and more reliable technology, even in mission-critical environments, provided the failover/fallover capability works correctly.

There is just one problem with this scenario: you have to know what you're doing. You can only spend brainpower for money if you have the knowledge, experience and capacity to do this. Or are willing to learn.