xen and the art of rackspace

Thu, 12 May 2011 23:34:00 GMT

I have been trying to find the time and the resources to get a xen testbed up and working because my hosting company, Rackspace (and before that Slicehost) used xen to power their cloud servers and I thought it would be worth having some experience in that area since I currently depend on it, and even if I do switch providers I will likely be looking for one that provides a xen based solution. My first attempt was when I got a new CPU server/workstation recently. Unfortunately I discovered that xen and Nvidia don't play nice together so I wound up using KVM instead. I am actually glad, because KVM is more flexible and makes possible, if not always easy, to migrate from VMware. There is a definite performance advantage to xen, because the guest and host kernels cooperate.

Anyway, I finally was able to repurpose my old CentOS/VMware server as a Debian/Xen server I started hacking around. I noticed the disk devices in the xen VMs that I created were using /dev/xvda instead of the usual /dev/sda, even though I seemed to remember that on Rackspace (and before that Slicehost) the devices are /dev/sda. I took a look at the MAJOR and MINOR codes on the devices in my xen VMs and the ones on the Rackspace VM, and sure enough, the Rackspace VMs are using /dev/xvda too, they have just changed the name, presumably because that is what people are used to seeing. Next out of curiosity, I tried to fdisk /dev/sda on the Rackspace VM, only it isn't there. When I created it using mknod and tried to fdisk it again I got a permission error. I am sure this is a security thing and I wasn't really worried about it, but I tweeted something about it as a sort of joke. Rackspace responded:

@plicease Could you email details to us? We'll help you figure out what it is. twitter @Rackspace .com

I hadn't put Rackspace in a # or used @ to refer to them or anything I guess they just troll the Interwebs for any mention of them in a sort of proactive tech support? They have always claimed to have fanatical tech support. Is this fanatical though, or maybe a bit creepy? Twitter is a public forum, and I post my tweets publicly so I can't really complain.

For the most part, they have always been quite good, although I have to say they seem to be a wee bit better when I had a dedicated server with them than they are now when I have VMs (there was a period for a number of years between those two scenarios when I had different hosting companies). Bad hardware has caused two of my VMs to go down on two separate occasions occasions (one VM each time). That sort of thing happens from time to time, and I'm not really complaining but over a much longer period, I never had a fault with my dedicated server.

nullray.wdlabs.com

Tue, 03 Jan 2006 00:37:00 GMT

I told Chuck that I was moving a couple of months ago. We agreed that nothing had to change, that I could do my job running the server as easily from down under as anywhere. I was nervous that he'd freak that I was leaving, but when he didn't it was one less thing that I had to worry about in the move. Then New Year's day I get this phone call from him and an e-mail telling me, more than asking, that the server billing needs to be transferred him, and that I need to show Jay how to do the few several tasks which are required to be done manually. Apparently he sent me a snail mail asking about it just before I went to Salt Lake for Christmas, but I never got it. I felt blindsided by this whole thing.

Anyway, I suppose I should have expected it. When I originally started the account with RackSpace (who have been wonderful, btw-), Chuck would insist that he get the bill and I'd say, "but that is not what we agreed to." Then a couple of weeks later he'd be back at it. It died down for a while. It hadn't come up for years.

So I've decided to get my own server. Everyone with belmont accounts (there are like four of you out there) will get an account on the new machine instead: nullray. The downside is that I have to configure the system to support all of the services that belmont currently takes care of. The upside to this thing is that the new machine will be much faster (2.4GHz), have more memory (1GB), larger hard drives (2x160GB) and newer operating system (Fedora 4).

For those of you with email or shell accounts I will let you know more when there is more to know. I expect the transition to be largely transparent, but you will at least have to remember to ssh nullray instead of ssh belmont during the switchover.

The Twilight Report

xen and the art of rackspace

nullray.wdlabs.com