It arrived last night. So of course I had to spend the whole damn night setting it up, in spite of the fact that the colo guys won’t be there to let me in for a few days.
Isn’t it pretty? As you can see, it’s a former Google Search Appliance, but without the Google software. Google evidently didn’t want anybody messing with it, and they even included a modem that you were supposed to connect to it in the case of problems so they could remotely diagnose and/or fix it. Which leads to problem number 1.
See that faceplate offset from the box in this picture? When it first came, that faceplate obscured access to the disk caddies, the floppy and the CD-ROM. Which would cause some difficulties installing new hard drives and booting from a CD to install the OS. The screws holding the faceplate on had had their (whatever you call the part the screwdriver goes in) rounded out so you couldn’t use a screwdriver to remove them. That necessitated solution number 1.
We ran out to the hardware store and bought a Dremel tool, and used that to cut grooves in the top of the screws so I could get them off. Once that was done, it was remarkably easy to get everything up and running. The drives are in caddies that slide out the front, and each drive is on a separate IDE controller – it appears that /dev/hda is the first disk, /dev/hdc is the second, /dev/hdd is the CD-ROM, /dev/hdc is the third disk. The only catches in the installation are:
- There is a BIOS password that I don’t know – there is a jumper that says it will clear the CMOS, but I haven’t had the nerve to use it in case it clears something else that I don’t want cleared.
- There are two ethernet jacks, and the one recognized by the Linux controller as eth0 is not the one you’d expect. Also, if you set the jumper to disable the ethernet controller, both seem to stop working. Either that, or the other one is a different type of ethernet controller that the Xen kernel can’t deal with.
I’d been using my Windows box as a sacrificial test machine with a couple of scratch disks to emulate what I have at the colo facility to play around. For the last couple of weeks, I’d been convinced that this was going to mean that I was going to have to take the box home to transfer the disks and install the latest Xen kernel, because I couldn’t get it to work consistently. But the new box has two things going for it – it has three disk slots, and the current colo boxes are using LVM. Experimenting with the new box showed that I could install a basic Debian Sarge on it, upgrade it to Debian Etch, use the Xen packages in Debian Etch to get up and running, and then slap the disks from my test machine in, and even though they’re on different devices than they were on the test machine, LVM automagically recognized them and I was able to mount the domU partitions exactly the same as I had in the test machine. From there, it was a simple matter to copy the new /lib/modules/2.6.18-3-xen-686 to the partitions, make a few small changes to the domU config files, and start them up.
This is great – it means that the way things are now, I can take the new box over to the colo, swap the hard drives over, and boot it up and it will be in a state that I can do the rest of the setup from home, with no data loss and only a few hours of downtime. That is currently scheduled for next Wednesday.
Tomorrow morning, I go out to the colo box and replace the existing one with my spiffy “new” Yellow Menace. I’ve tested the hell out of this one and it can handle all three domUs and the dom0 all doing dd’s from /dev/zero to the hard disk over and over again, which will be a nice change from the existing one freezing up throwing ext3 errors whenever I’m doing something disk intensive.
