Skip to: Site menu | Main content

Blog > Rackspace Shmackspace

>> Rackspace Shmackspace

Wed, Feb 27th 10:09am 2008: Bad People

Don't you hate it when what appears to be a good reputation turns out to actually be just overpowered marketing? We're running upwards of 80 servers here in Melbourne and growing all the time, but we need to start rolling out some infrastructure in the US as well. I've used a few US-based dedicated server providers in the past including Servepath, Dreamhost, and others, and had generally good experiences with them. This time though I wanted to start with a machine that we could do virtualisation on and start small, with just a few VMs initially and then provision more physical and virtual hosts as needed, and being so far away I wanted to be sure any problems we had would be fixed ASAP since we don't have physical access to the boxes. And what I really wanted was either an Ubuntu or Debian host so it would be consistent with our server SOE and our purpose-built cluster management tools would work nicely with it. In the end I decided to go with Rackspace on the strength of their reputation for tech support: 24 hour phone hotline, dedicated account manager, etc. They couldn't provide an Ubuntu or Debian machine, but said they could provide RHEL which has good Xen support. That sucked a bit because it means we can't integrate the machine into our management infrastructure, but I was willing to put up with that annoyance (and pay more than twice what I would have elsewhere) to get the "fanatical support" that they promise. A trade-off, but I thought it was worthwhile. The problems began right from the start. I don't think I've ever asked a single question of their tech support and got a straight answer the first time. It's usually been a case of asking the question, getting a useless answer, saying "no, that's not what I wanted to know, the original question was...", getting another obtuse answer, repeat until enough information could be gleaned. In all my dealings with them it's been as if they simply don't hear what I say, and I have to keep repeating myself until they do. A classic example of missing the point was early on when they supplied the server with RHEL4 after I had spent much time on the phone explaining exactly what/why we needed the server: primarily as a virtualisation platform. But RHEL4 doesn't have good Xen support, so it wasn't any use to us! So they suggested reinstalling the server with RHEL5 in order to provide all the necessary Xen packages, which they then did. After it had been reinstalled I logged in and tried to get the Xen tools installed and found they weren't available through Yum, and I couldn't even install a Xen-capable kernel. After hassling tech support a bit about why there were no Xen packages available, they responded saying that when the server was reinstalled they'd forgotten to enable the virtualisation channel. Hello? Is anyone listening? That was a trivial problem compared with the network shenannigans. I had asked for additional IP addresses so we could use them for virtual machines, and the entries in the trouble ticket go something like this (paraphrased for brevity): Me: "I've been provided one additional IP address but no details of netmask, gateway, etc. I have brought up a dummy interface to test it but I need to know what the details should be". Them: "Here are the details of your interface: " (they then pasted in the 'ifconfig' output from the dummy interface that *I* had created!) Me: "No, that's the one I created and it didn't answer my question about what the netmask and gateway should be." (Then while I'm logged into the server eth0 mysteriously vanishes, and I'm cut off) Me: "Eth0 has gone away." Them: "Sorry, we dropped it by mistake. Here are the additional network details:" (they provided a single address with a .248 netmask, with the address not at the start of the range but at the second available host address and no further explanation). Me: "This server was set up for virtualisation. The additional address provided is on a different subnet to the host address and can't be bridged to the host adaptor." (I experiment a bit to figure out what's going on with the routing of the subnet they've specified) Me: "It looks like the entire /29 is being routed to our server, but we've been told we have a single additional IP address available. What about the rest of the range?" (I experiment a bit more, adding one of the other IP addresses in the range as an alias to the host adaptor, set up a virtual bridge, set up a virtual machine, set the route on the VM through the aliased IP on the host, and check that it works. It does, but at this point I've effectively hijacked an IP address that I hadn't been authorised to use). Me: I explain what I've done above, and ask *again* for clarification on what additional IP's we've actually been assigned and the network configuration. Them: Reply saying that yes, my analysis was correct and in fact the entire /29 is routed to our server after all. Elapsed from first request to actual helpful answer (which was really just saying that what I had figured out for myself was correct): 20 hours, and 10 comments in the trouble ticket. Grrr, why couldn't they have just answered the bloody question in the first place? Those weren't the only problems I had, but they're indicative of my whole Rackspace experience. Maybe I was just having a bad run. Maybe because our requirements are a bit outside the norm they're having trouble providing us with support. That's understandable, so let's part as friends and terminate the contract, no major harm done. So I went looking for a cancellation form on their site or in their support area. No dice. Then I submitted a support ticket asking about the cancellation procedure. Not only did the response not answer my actual question (as usual), but I got a hard-ass response saying that we were locked into a contract and they were going to hold us to it until the day it expires. *That* blew my top. I'm not giving them the benefit of the doubt anymore: now I'm just pissed off. Any company that actually cared about customer service would understand that the small financial gain from holding a disgruntled customer to the exact terms of their contract are far outweighed by the resentment and bad will that it causes. Until that response to my cancellation request I would have walked away disappointed that it hadn't worked out, but not upset. Now I'm mad. Then to really rub salt in the wound, the response also said: "With specific regards to your configuration, the Managed Department of Rackspace does not support Virtualization at all, and I believe that the majority of your issues with our Support Team originate with this fact." They don't support virtualisation at all? Hmmm. I've written enough already, so I'll end with this screencap from the Rackspace homepage. Pay close attention to the message across the top, then the bit in the bottom right corner. Fanatical support indeed.

Bookmark and Share