Xen and the art of noise (management)

While I definitely appreciate the folks at Textdrive for being early, and continuing, supporters of Rails, I recently decided to switch to a VDS for essentially the same reasons as Octopod. Actually, I have him to thank for that little extra nudge provided by his blog entry. I hadn’t given the idea much thought until then because it seemed like overkill for hosting a couple personal sites. Silly me.

After quite a bit of research, I decided to go with Quantact as well. And thanks to Ezra’s great tutorial, I’m up and enjoying myself a lot. Well, mostly. I decided to use Debian 3.1, which I’ve never used before. However, since I’ve been using Ubuntu for the past several months (which was a pretty big switch after RH and Fedora for years), the process was mostly painless. The one area I’m not real comfortable with is the firewall. I’m using Bastille, but I haven’t closed the book on that yet. Actually, the idea that’s pinging around in my head is: I wonder how it would work to use Rake to write the rules for iptables. Has anyone tried something like this? I’ll let you know what I discover.

Okay, you might be wondering how the title fits in here. If you’ve checked out Quantact, you may have noticed they are using Xen for the VDS. Impressive technology. The rest? Well, when evaluating what I was finding most unsatisfactory about shared hosting, I realized it was the “noise”. All these processes, all these directories, all this stuff going on that had nothing to do with me. I was spending a lot of time in that noise, especially that webmin interface when I just wanted to type a few lines and be done. Now ps aux fills less than one screen of my xterm. I don’t think about special cases or file tickets for a port. Mind you, I’m not saying Textdrive has it all wrong. I’m just saying, my Xen VDS is nice and quiet.

2 Responses to “Xen and the art of noise (management)”

  1. Cliff Wells Says:
    Xen is cool, but a lot better for this type of application is OpenVZ: http://openvz.org/ The key difference is that Xen is a complete instance of the operating system, with it's own kernel and all the resource usage that entails. With OpenVZ, there is only one kernel and yet you attain the same level of virtualization (although you can clearly only run Linux ;-). Overhead is typically around 3%, not a bad price for virtualization. Despite the fact you are constrained to Linux, you are by no means constrained to a particular distro: each VE can run whatever distro you like (provided there is a template for it or you are willing to put in a tiny bit of work to create one). We are evaluating OpenVZ for use in our shared hosting environment where it's not as resource-intensive as Xen nor as intrusive as SELinux and yet provides most, if not all, of the same protections that those systems provide.
  2. Cliff Wells Says:
    Oh, and I forgot to mention one of the most fascinating and useful features of OpenVZ: the ability to migrate a VE across machines (even geographically distant ones) *with no downtime*. I don't think there's anything else out there that can claim that. Now if it could work on top of OpenMosix (maybe it can?), server downtime could become a thing of the past. And for those who care about such things, OpenVZ is open source (and they are seeking kernel inclusion) but has a commercial venture that offers support if you need it (and some additional tools and features): http://www.virtuozzo.com/

Sorry, comments are closed for this article.