Sitting in my drafts folder forever.
Is Xen ready for the data center? Is that the right question?:
Actually I think that the question is “Is Xen ready for your datacenter and your staff? Or perhaps, are your staff ready for Xen?”
Globally speaking, the article covers the bases nicely and it’s true that Xen is a solid virtualisation solution quite capable of producing really excellent performance. However, the virtualization engine itself is only a small piece of the puzzle.
I deal in a consulting with companies of various sizes and requirements and I think that in a “real”* datacenter you should have little or no trouble finding the skills to deal with running a Xen based solution, especially when coupled with some of the various administrative toolsets that are out there. However, the reality of many environments is that their Linux skills are sorely lacking and even the Service Console of ESX scares them. I wish this were not the case, but it’s the reality in a lot of places.
“Sadly, most seem to think that IT professionals managing the data center are buffoons who are somehow incapable of working with anything that doesn’t include a highly refined set of GUI tools and setup wizards. Personal experience shines through when an author balks at the notion of editing a text or XML configuration file - a common task for any system administrator.”
Everything depends on your datacenter. Don’t forget that you’re also coupling a project that involves a whole slew of technologies that can be new to the environment and the staff - VLAN implementations, Fiber Channel and/or iSCSI SANs, synchronous and asynchronous replication, snapshots at various levels, and the like. If you’re asking them to go from being Windows sysadmins who’ve always worked with local storage to a Linux environment with shared storage that’s a huge learning curve.
Or you have the environment where your team is supporting a variety of stuff, but since it’s mostly Microsoft based, you’ve got your token Linux guy who does everything and with any luck leaves enough decent documentation for the others to deal with anticipated problems. But on his days off, everyone on the team prays that nothing screws up.
Consequently, a declaration of immaturity is often the result, without regard for the performance or functionality of the technology. In the case of Xen, this is particularly prevalent, as the Xen engine and management tools are distinctly separate. In fact, there are already several dozen management and provisioning tools available and/or in-development for the highly capable Xen engine, at varying degrees of maturity.
Another approach might be to say that many of the IT teams and their management are immature if they’re not ready to accept new technology.
And yet, I can’t help but think that comparing features of management tools is completely missing the point. Why are we focusing on the tools, rather than the technology? Shouldn’t we be asking, ‘where is virtualization heading’ and ‘which of these technologies has the most long term viability?’
Yes and no. There is certainly some value is asking these questions, but the other stronger question that is pushing people is “what can I do today?” If I were to put too much weight on the long term approach, I’d say that Microsoft’s Viridian might** in fact end up being the perfect solution to a mostly MS shop. However it’s still a year out (assuming all goes as planned) and I have projects that need to start now. As for long term viability, this is becoming a non-issue with the maturity of the various P2V and V2V tools. Honestly, who cares what platform you’re running as long as it meets your current and medium term requirements (read: duration of maintenance contract). Migrating to another platform is a pretty painless operation - after all, one of the big gains of virtualization is that the hard coupling with a platform is no longer an issue and that extends out past the hardware barrier.
In the long term the core virtualisation technology will become irrelevant and I suspect strongly that ESX will be given away free the way that Virtual Server and VMWare Server are today. What’s more important is the accessibility and depth of the management toolkit. If all I was after was virtualisation for the sake of encapsulation, I’d be running VMWare Server on a Linux host off of local storage (or Xen, granted). > And which technology has everyone moved to? That’s simple - paravirtualization on the Xen hypervisor. Solaris, Linux, several Unix variants, and, as a result of their partnership with Novell, Microsoft will all either run Xen directly or will be Xen compatible in a very short time.
Oh I doubt strongly that Viridian has any intention of supporting native Xen images. Remember, embrace and extend. They’ll make it easy to import the images, but I don’t expect much more than that.
Of course, those with the most market share will continue to sell their solutions as ‘more mature’ and/or ‘enterprise ready’ while continuing to improve their tools. Unfortunately, they will continue to lean on an outdated, albeit refined technology core. The core may continue to evolve, but the approach is fundamentally less efficient, and will therefore never achieve the performance of the more logical solution.
Performance isn’t everything (nor is logic). From what I’ve been able to gather from the various performance profiling battles going on is that the difference is usually 5-10% one way or the other depending on who defines the methodology. And honestly, that kind of difference is negligible in all but the highest volume environments. On top of that, the real bottleneck in large scale consolidation is almost always disk I/O which renders most of these discussions moot.
It reminds me of the ice farmers’ response to the refrigerator - rather than evolving their business, they tried to find better, more efficient ways to make ice, and ultimately went out of business because the technology simply wasn’t as good.
Umm - I think a better comparison would be two refrigerator manufacturers arguing over using one freon compound vs another. The fridge stills keeps things cold, and that’s all the customer is interested in. Mmmm…cold beer.
Of course, you could simply choose to wait for Veridian, but I would assert that there are several advantages to going with Xen now. First, you’ll already be running on Xen, so you’ll be comfortable with the tools and will likely incur little, if any conversion cost when Veridian goes golden. And second, you get to take advantage of unmatched, multi-platform virtualization technology, such as native 64bit guests, and 32bit paravirtualized guests on 64bit hosts.
Umm - we can already do that today on ESX.
So what’s the weak spot? Complexity and management. While the engine is solid, the management tools are distinctly separate and still evolving.
Bang. Nail, meet hammer. This is the show stopper. IT management makes the budget and technology decisions, and in almost all of the medium and small customer sites I’ve been to, the IT Manager wants to be able to look at a console and have someone explain it to them in under 5 minutes. If it’s more complicated than that, you’ve inspired fear. In larger, more open minded shops this is less of a barrier, but it’s a real barrier.
The other weak spot is the lack of depth of the surrounding ecosystem. In this case, Xen is the lucky benefactor of the ISVs surrounding VMWare who compete with one another by extending their functions to include Xen, but these folks’ priority is VMWare.
Ultimately the market will decide, but she’s a fickle, schizoid, irrational mistress. If ergonomics and accessibility drove the market, we’d all be using Macs. If price/performance calculations were king, we’d all be using Linux. Most of the world uses Windows. Go figure. * By real, I mean a datacenter composed of multiple environments, a staff of multiple teams with defined and differentiated roles,
** I said “might” not “is” or “will”