A virtual virgin writes…
I’ve been doing virtual machines since 2000, which makes me a bit of an old-timer, I would think. I invented the laptop rac using a single virtual machine and taught it in Oracle University classrooms from about 2002 on, which was something of a world first. I’ve been banging on about the virtues of virtualisation for a long time… you’d think I’d therefore get it right when it comes to putting it into production, wouldn’t you? But no. I’ve stuffed up. In fact, I’ve behaved like I’d never met a virtual machine before. A virtualised virgin, if you like.
Beguiled by the swift, elegant simplicity of the Citrix XenServer installation and included management tools, I’ve persuaded the powers that be at work to dedicate a 32GB, 8 CPU monster server to running XenServer. I’ve even persuaded them to do something of a first this financial year and part with about AU$6000 so that I can upgrade the storage from a paltry 400GB to a more useful 3000GB, all with a view to combining every test and dev database we’ve got onto a single server, but running in discrete, virtual servers for the purpose of easy snapshotting, backing up, migration and so on.In the process, we would free up two physical servers, one of which could house a small database that all our other databases link to for ‘globally unique’ information. That would free up 6GB of RAM on one of our other servers, thus enabling the two databases running there to increase their buffer caches and get their web response times down further from their already pretty good 0.6 seconds. Wins all round.
Except I chose Citrix XenServer.
It’s not a bad virtualisation product. It’s just immature compared to the likes of VMware. A core requirement was the easy ability to create snapshots, to then navigate back and forth up and down the snashot tree as required. XenServer is bloody awful at snapshotting anything (promised to be fixed in the next release). Another core requirement was the ability to export a virtual machine for backup purposes: one of my 80GB VMs took 11 hours to export with Citrix. On VMware ESXi, it takes 36 minutes. God knows why, but the difference -functionally- is enormous. Finally, as reported in these parts yesterday, XenServer throws a complete mental fit when confronted with Centos 5.4; ESXi just took it in its stride. (Oh, and as another aside, XenServer refuses to run Windows in a VM unless hardware virtualisation extensions are present; ESXi doesn’t appear to give a stuff, and runs them just fine and with seemingly perfectly acceptable performance results).
The XenServer is going, in other words. And we’re switching to ESXi.
I have my problems with ESXi, too, which I’ll no doubt document before long. The fact that its GUI management tool doesn’t run on Windows 7 was a bit of a killer, for example, but I have found a way around that. The licensing is also a complete pig’s breakfast and I’m still trying to get my head around that. But, all in all, ESXi does what we needed virtualisation to do, today, whereas Citrix XenServer doesn’t and won’t until the proverbial “next release”.
I apologise to my reader(s) for having eulogised a fundamentally dud technology (at least as far as we are concerned at work) for far too long. Normal service will be resumed soon, I hope!
October 28th, 2009 at 2:57 am
I’m sorry you found XenServer not to be a good match for your needs. I’m curious, though, about some of those needs.
You talk about a core requirement being navigating around in a snapshot tree. We have been very clear about the fact that XenServer 5.5 supports snapshot FOR BACKUP ENABLEMENT including Virtual Shadow-Copy Service for Windows quiesced backups, and NOT point-in-time development rollback. We can’t do everything at once, and the production requirements had to come first.
I don’t disagree with you on the subject of export, except to point out that export to a remote system is done through an SSL-secured tunnel, which takes significant time. Have you tried export to a local or NFS-connected store with the -nossl option on the command line?
We made a design decision that we could build a much simpler, easier-to-maintain hypervisor if we took advantage of hardware virtualization assist instead of writing a complex emulator to handle every case in which x86 is a “bad virtualization citizen” — but, yes, that means that we don’t support Windows guests on servers that are more than about three years old. Since most clients we have worked with have bought new systems for virtualization projects, or at least used their most up-to-date and powerful ones, that has not been too much of an issue. i’m sorry it’s inconvenienced you. (On the other hand, of course, it also means you’re probably consuming lots more power to run your VMs on those older, far less efficient systems.)
As for supporting new operating systems, yes, we do need to make sure their installers work properly in a paravirtualizing environment, and that our tools work properly too. so we typically release support for new guests in the product release that follows the guest OS’s general availability — again, since most people do not take a brand new OS release and drop it in production the day it hits the distribution sites.
I’m sorry XenServer isn’t a fit for you Several hundred thousand folks would disagree, and you’re as right for your needs as they are for theirs.
October 28th, 2009 at 7:02 am
You talk about a core requirement being navigating around in a snapshot tree. We have been very clear about the fact that XenServer 5.5 supports snapshot FOR BACKUP ENABLEMENT including Virtual Shadow-Copy Service for Windows quiesced backups, and NOT point-in-time development rollback. We can’t do everything at once, and the production requirements had to come first.
I’ve no complaints on that score. My reading on the forums shows this ‘prioritisation’ factor being mentioned a number of times. And obviously, you do what you have to do to accord with your business model. It’s just that your timescales don’t on this occasion accord very well with our production requirements! That’s our problem, of course, not yours… but it still means an initial enthusiasm for XenServer has dimmed somewhat.
I don’t disagree with you on the subject of export, except to point out that export to a remote system is done through an SSL-secured tunnel…
I hadn’t realised that, actually. My fault. I would suggest, though, that since I’m exporting from one server behind our firewall to another server behind our firewall (in fact, the two servers are about 2 feet apart in the same server room) that the automatic and default use of SSL is a little, er, ‘over the top’?! It would be nice to have a GUI option that recognises that sometimes a business might value and require speed over security since their security needs are being met by other means.
…but, yes, that means that we don’t support Windows guests on servers that are more than about three years old.
It’s a complicated story, but I’ve Xen-ified a very powerful, capable server on which Windows VMs are not a problem. No complaints there at all. We also happen to have a 16GB, Dual Opteron server which is, I’d guess, about 3.5 years old (maybe a bit older). It’s no longer a production quality machine …but 16GB and dual CPUs is not exactly a piece of dross, either. I wanted to use it as a sort of ‘Xen-spare’: when the main server needs re-configuring (as it does this week with 6×500GB hard disks instead of 6×72GB, for example), the idea was to move some of the VMs off the “production” box onto the ancient ’spare’, just for an hour or so whilst the new storage was configured and provisioned. Then move things back. But if the ’spare’ can’t run the Windows VMs that the ‘production’ box is running, that’s not an option. I suppose that’s a highly specific usage scenario… but it happens to be one we’re facing this week. Again, I’m not saying XenServer is rubbish or anything close to it… it just doesn’t fit these specific needs particularly well.
…again, since most people do not take a brand new OS release and drop it in production the day it hits the distribution sites
I will take issue with you on that one. One of the entire points of virtualisation, I would have said, would be to *experiment* with new OSes pretty much as soon as they are out. Especially when the “newness” consists of a point release from 5.3 to 5.4 (I could understand your argument rather better if it had been a 5.3 to 6.0 jump, for example). It’s precisely because I don’t want to drop Redhat 5.4 straight into production use that I want to be able to test it and evaluate it in a virtualised environment for weeks and months beforehand. The template release scheme XenServer has, however, would mean me sitting around for months before being able to do that (given that we don’t have a bunch of physical servers sitting around doing nothing except waiting for me to do some testing, obviously!). I really think you need to be able to develop a ‘drop in new template’ functionality that doesn’t require your users to be sitting around for months waiting for the next XenServer release date.
Several hundred thousand folks would disagree,…
I’m sure they would. As I’ve said in these pages many a time, I *like* XenServer, a lot. Installing it’s a doddle; the client tool is lovely; the speed at which its VMs run is excellent.
But the largely non-functional snapshotting (of the VMware kind, I mean) and the inability to download independent templates to deal with new OSes pretty close to as they are released are absolute show-stoppers in our particular environment. And I can say that I think that would be true for many hundred thousand folk too!
I’m not attacking XenServer, or criticising it unduly, I think -especially if you read the general tone of the entire sequence of my XenServer posts. It has its foibles (such as no GUI Linux installs), but they can be worked around and I’ve had no problem doing so, or *having* to do so. Foibles can be endearing as well as a little frustrating: part of the charm of getting to know a product. But when a foible becomes an obstacle, that’s a different matter… and all I’m saying here is that, for what we need, there are four show-stoppers (speed of export; ability to run Windows VMs without hardware virtualisation capabilities; highly-functional snapshotting; lack of new templates as new OSes are released) that mean a switch to ESXi for us is a practical necessity at this time.
October 29th, 2009 at 2:58 am
Laptop RAC: http://www.oaktable.net/userFiles.jsp
Who did it first in 2002?
October 31st, 2009 at 8:24 pm
Who did it first? Me. In 2001, actually, though it took me a while to nail it down and be bothered to write it up. I published two papers on the Oak Table website (since I was a member at that time) under the pseudonum ‘Harrison Redhouse’ (there was a clue in the use of ‘HR’ as initials, and ‘Red House’ (the name of the home of Benjamin Britten in Aldeburgh) for those that could see it), describing a two-VM windows RAC first, followed by (about a month later) a one-VM, two-instance version which ran a lot better on the available hardware at the time.
I did actually invent Windows laptop RAC. I also invented purely-VM RAC for Windows *and* Linux. James Morle invented a hybrid physical-virtual RAC earlier than that, running Linux; but I worked out both the very first purely virtual 2-node, 2-instance and 1-node, 2-instance RAC running Windows (and swiftly thereafter converted to Linux). And thems is just the facts. Don’t like ‘em: tough. (And, though I realise it’s a minor detail, I worked out how to do VM-RAC without having ever read James Morle’s original ’secret Papa’s recipe’ paper, since I did the relevant work before I joined the Oak Table).
As it happens, I suspect James Morle could confirm the facts, since it was my emails to him that persuaded the Oak Table website to host my original papers without attributing them to me personally; and it was my subsequent emails to him which ensured the relevant documents were withdrawn from the website. He has probably kept the correspondence I didn’t bother to keep, since he’s well-organised and I never suspected that people like you would ever question the fact that I got there first.
November 1st, 2009 at 7:26 am
“I never suspected that people like you would ever question the fact that I got there first.”
Are you familiar with the term Malignant Narcissist?
November 1st, 2009 at 6:37 pm
You asked the question. I gave you the entirely factual answer. You either accept those facts, or you don’t. I don’t particularly care which option you take, but your entirely ad hominem response doesn’t actually change the facts. There is nothing naricssistic about claiming to be first if, in actual fact, you *were* first. And in the concept of developing a purely virtual way of doing RAC on a single PC, I *was* first. Like it or lump it.
Evidently, you prefer to lump it, and that’s your choice. My choice is to not put up with any more of your silly personal attacks. The delete button looms.
November 3rd, 2009 at 12:53 am
Hi Dizwell, i’ve read your comment on my blog, i’m very grateful to you. I’m not very expert on virtualisation technologies but i’m very interested on them. i don’t know Citrix XenServer, i’ve still to test it and only when i will have tested and used it really maybe i will understand what exacly templates are. I’ve made some tests with xen in Oracle Enterprise Linux 5 (so with xen 3.0) and here i’m able to create a new machine with OEL 5.3 without nothing else that OEL5.3 DVD installation ISO which already includes “xen-aware” kernel.
I suspect that the difference is that with templates the process of creations of a new machine in more fast because you have not to do a new operating system installation, is it true?
November 3rd, 2009 at 10:46 am
I’m not sure, but I don’t think so: I’m no virtualisation expert as regards XenServer, that’s for sure! That said…
First of all, there are different kinds of templates. Ones called “full templates” DO include the OS (I believe XenServer’s Debian 4.0 template is one of those). Otherwise, the basic templates (such as the one for Red Hat 5.3) are just a set of default configuration options (including virtual hardware setups). You still have to install an OS, and you still have to supply your own installation DVDs or ISOs for doing so.
But, and this is the bit I was getting at, even the basic template causes a paravirtualised kernel to be switched into your VM after you’ve installed it from the original installation DVD. (See http://forums.citrix.com/thread.jspa?threadID=254027&tstart=0 for example: there, in the third post made, a Citrix employee explains that “The templates for Linux will swap in a PV-enabled kernel as you are already aware”)
So, if you use even a basic template, it’s certainly convenient, but you the main point is to get a properly-paravirtualised Xen-aware kernel. You don’t get that when you use the ‘Other’ template, however.