[TriLUG] the Linux brain transplant

[Alan Porter]

During our recent move of the TriLUG server equipment, there was some
uncertainty about the timing of our old space going away and our new
space becoming available.

So as a backup plan, I tried an experiment.  It worked... very well, in
fact.  And I wanted to share the trick with the crowd here.

Basically, I cloned pilot (a physical server) onto a Linode.

I went to my Linode.com account and requested a new VM.  Then I
parititioned the storage into two devices: one 4GB for the default
Ubuntu installation and one 44GB for the clone of pilot (without the
user home directories).

I booted the Linode into the Ubuntu partition and mounted the other one
on /mnt.  Then I ran a rsync job from pilot to this mounted disk.  It
took a while, since our bandwidth was throttled at our old host.  But
when it was finished, I edited FOUR FILES, rebooted, and crossed my fingers.

The four files:
 - /etc/hosts - new IP
 - /etc/fstab - new filesystem devices
 - /etc/network/interfaces - new IP
 - /etc/udev/rules.d/70-persistent-net.rules - forget old MAC address
for eth0

It worked!

The really crazy thing about this story is that pilot has a pretty
complex disk structure, with LVM on top of RAID.  The Linode just
mounted the whole filesystem on custom block device (which probably maps
to some SAN in their data center).  But when "pilot2" booted, it did not
care.  It found the kernel (specified in the Linode configuration) and
it found the root filesystem on that block device, and so it was happy.

When the machine came up, all of the services started up properly, just
like they do on the real machine.  In fact, Kevin Otte told me to turn
off the clone of tribot, since it was competing with the real one on
#trilug.

This is, by far, one of the most compelling arguments that I have for
why sysadmins should love running Linux.  It just wakes up, looks around
at its environment, loads the proper drivers, and then runs the stuff
that it's supposed to.  No fuss.


Alan