Desperately Seeking Xen 192
AlexGr sends us to an excellent article on the state of Xen by Jeff Gould (Peerstone Research). He concludes that the virtualization technology has some maturing to do and will face increasing competition for the privilege of taking on VMWare. Quoting: "What's going on with Xen, the open source hypervisor that was supposed to give VMware a run for its money? I can't remember how many IT trade press articles, blog posts and vendor white papers I've read about Xen in the last few years... The vast majority of those articles — including a few I've written myself — take it as an article of faith that Xen's paravirtualizing technical approach and open source business model are inherently superior to the closed source alternatives from VMware or Microsoft."
Re:vm ware (Score:5, Insightful)
Xen (and virtualization) is for the Enterprise (Score:5, Insightful)
Xen's Maturity (Score:4, Insightful)
I RTFA and it says very little about the maturity of the actual Xen technology. The article is more a point about several non-related factors;
1.) There is a lack of pretty management interfaces.
True, but these are in the works from Red Hat, Novell, XenSource, and various other ends. Already some of them look pretty promising, but if you are a real admin you don't need them in the first place. There is nothing wrong with using the command line tools to manage your Xen virtual guest environment.
2.) There is a lack of references for companies using Xen.
How does this relate to the viability of the Xen virtualization? Yeah it makes management feel nice and fuzzy that others are using something, but this does not relate to how well the Xen technology performs. I also suspect that like many open source projects, there are many people using it that do not report it. Novell has personally contacted me and my company to ask us to assist in their new paravirtualized Windows drivers initiative and then be a reference for the technology. It seems that at least some companies are moving to address this, at any rate.
3.) There aren't many benchmarks about Xen versus VMWare.
VMWare does not allow benchmarks they do not approve of. It's in that draconian EULA you agreed to by using it.
4.) It's awkward to paravirtualize Windows.
Yes, it is. Novell signed the soul sapping agreement with MS and as such is pushing some paravirtualized drivers for Windows. The article continually talks about woes with Xen on Red Hat. Red Hat didn't sign the agreement and will require some much more intelligent coding to make this happen. It might never happen, so for Windows it's full virtualization with VT (or AMD's equivalent) or bust. Sorry, use SUSE for it or use full virtualization. It's an MS issue not a Xen issue.
5.) MS's new Viridan Virtualization Platform is using paravirtualization as well.
Yep, that should be a testament to the approach versus VMWare. Though it is interesting that VMWare now has a Linux kernel virtualization implementation similar to KVM. It seems VMWare is headed to paravirtualization as well. Obviously Xen did something right.
6.) There is a lot of competition.
True. How again is this relating to Xen as a virtualization technology.
Again, I'm not saying Xen is perfect. It definitely has issues and room to grow. I'm just saying that the article makes little, if any, relevant points to Xen's virtualization technology.
Re:Xen "Just Works" (I know. I use it every day) (Score:3, Insightful)
Well you can try to do that with Xen if you want, but you might be sorry.
Hopefully the Summer release remedies this situation.
C//
Data Center USA (Score:5, Insightful)
I stopped reading the article with this quote:
Are sysadmins at "Data Center USA" morons? "Oh nooo, command line time, I hate that. Oh nooo, my option I want is all grayed out! Help me, help me! Oh I am so sad now."
Deploying vm stuff is not the same as using a word processor. "Data Center USA" is in real trouble if their sysadmins aren't any smarter than regular desktop users.
Two words: OpenVZ (Score:3, Insightful)
If you are running the same OS on each VM on a server, OpenVZ is the best.
Performance is great, good control over resources (with the glaring exception of disk IO operations, which they are working on).
Re:Xen's Maturity (Score:3, Insightful)
I'll agree with this, although it isn't the hypervisor's fault - it's the userland stuff that's at fault. For example, Xen doesn't appear to support IPv6 *at all* in routed mode, I had to hack up my own scripts to do it (and I'm seriously considering moving over to bridged mode in an effort to simplify and standardise my system). But I'm curious - do other virtualisation systems handle these sorts of things any better?
I've never understood why some people - OSS unix geeks in particular - consider the quality of software to be inversely related to how easy it is to use.
I certainly don't. However, experience has taught be that software with shiny GUIs is often inferior in other, more important areas. That's not to say that I think making things hard is a good thing, but maybe the programmers are fixing problems they consider to be more important. Afterall, Free software is usually written out of necessity (i.e. developers implement the features that _they_ want) rather than having some corporate agenda to make it "easy" for "normal people".
Also, in my experience software with GUIs is also often missing a decent commandline interface - GUIs are all very well but once you have learnt to use a commandline interface then it is (a) much faster to use and (b) usable over a low bandwidth network connection (I don't want to try tunnelling an X11 based configurator over GPRS just to tweak a setting on my server).
If I'd known before I started pursuing Xen what I know now, my advice to myself would be the same to my advice to most people looking into enterprise-level virtualisation - get VMWare ESX.
I've not had any significant problems with Xen (other than the above note about IPv6 support) so in my case VMWare would be a waste of money. I guess each person's needs are different, but for me the act of actually going and buying VMWare (and having to keep it up to date) would make it more effort than just using Xen which happens to be already there on recent distros and Just Works out of the box for most situations.
You might think it's expensive, but it's almost a certainty you'll spend more money on Xen in wasted manpower trying to get it up to half the functionality and relability.
I'm not sure where your reliability concerns come from - I've been running a number of Xen VMs across a number of real machines for quite some time and I've never had one break on me. Also, as mentioned, for what I'm using virtualisation for, I would be expending more man-hours administering VMware than I am administering Xen so I think your arguement is possibly only applicable in some very specific situations.
Re:Xen "Just Works" (I know. I use it every day) (Score:2, Insightful)
ESX can do live migration from one physical server to another provided the virtual machine image lives on a shared storage.
Xen can do live migration on a paravirtualized image from one physical server to another provided the image lives on shared storage.
Xen cannot do live migration on a fully virtualized server from one machine to another.
KVM doesn't specify full or para virtualization on their migration page, but it does some sort of live migration, and I'll bet it needs shared storage.
Re:Currently using Xen... (Score:3, Insightful)
I understand the latency of the switchover. It will be dependent on the size of the volatile set of memory that needs to be transferred between the save/restore cycles. I.e., this will be virtual machine-dependent, and tend to increase linearly with the virtual machine's memory footprint and memory utilization.
"Data center readiness," to me, does not mean a few servers running Xen. It means many, many servers, taken from at least superset of servers taken from all the mainstream enterprise server vendors, in all the common configurations. IOW, if I have a set of Dell 1955 Blades with Net App 3050 NFS storage heads running Xen and it crashes during live migration, (and I do), Xen is not ready for data center deployment, QED.
An example of someone else who's jimmied together a successful rig does not serve as evidence of "data center readiness." I have tried SLES10 out of the box, SLES10+patches, RHEL5, RHEL5+patches, and Open Source Xen with careful compilation of specific kernel options... all with live migration. They are all terribly unstable on our hardware configuration.
Show me an enterprise deployment of hundreds of Xen hypervisors deployed servicing guests with a minimum of four nines of availability guarantee with a contractual financial penalty for availability violations... then we can start talking seriously about the "data center readiness" of Xen.
Today Xen is
Maybe next year.
Not today.
If you ask me, Xen's going to get clobbered by KVM; a different subject for a different day.
C//
Re:Data Center USA (Score:3, Insightful)
Like, uh... a script? I had always problems trying to understand the rationale of "documented an reproductible" and "GUI" in the same sentence. Can you really talk about "can be documented and can be reproduced" on bold face when all you have is a doc document an some screen captures? Can you really talk about "can be documented and can be reproduced" when something suddenly starts to fail and you don't have the slightest idea about what was changed from yesterday?
"Do you really think editing a bloody XML file is a good idea?"
Not at all. But the ability to diff it to yesterday's version to see what changed it is. As it is running an script from cron instead of waiting for somebody to click on a GUI's box. As it is to have an scripted deployment environment you can guarantee repeatability with instead of depending on the read abilities of a sysop going through a doc with screen captures.
Re:Pointless? (Score:3, Insightful)
--Testing (Freebsd / PC-BSD / Nexenta / Solaris / Linux) + ZFS + Samba in a VM when you don't have extra hardware to dedicate to it.
--If you're not already a VM-type person, you wouldn't understand.