On Mon, Mar 01, 2010 at 02:47:23PM -0500, Kwan Lowe wrote:
> Just wanted to share some success I had moving some Xen guests from
> one server to another.
> Problem Recap
> We had Xen host on a single core 32-bit CentOS 5.4 installation on an
> AMD Athlon 2.1 GhZ system that was giving hard drive errors and needed
> to move the LVM-backed Xen images to another server. The replacement
> server was a quad-core AMD Phenom system running 64-bit CentOS 5.4.
> Our original plan was to use LVM snapshots so that we wouldn't need a
> maintenance window. This worked fine in test, but we decided to bring
> down the Xen guests after all. After shutting down the systems we
> backed up the LVMs.
> To show the backing LV:
> lvdisplay /dev/rootvg/xm_c32_001
> >From this, we grabbed the "Current LE" field and LV Size. We used LV
> Size to create a temporary mount point. We used the "Current LE"
> parameter to create an identically sized LV on the replacement server
> On the failing server:
> dd if=/dev/rootvg/xm_c32_001 of=/mnt/backup/xm_c32_001.out
> We gzip'ed the resulting .out file and saved it as a backup.
> BTW, there are many recommendations to do the following on the virtual machine:
> dd if=/dev/zero bs=1024 count=xxxx of=/partition.out
> rm partition.out
> By creating the large empty file on each partition *in the guest
> istance* (/var, /, /home, etc.), it will improve the image
> compression. Space was not much of a concern and we were worried
> about blowing out a production system, so we opted not to do this.
> Once the backing LVM was created, we created the LV on the replacement server:
> lvcreate -l xxx -n xm_c32_001 rootvg
> Then used dd to recreate the file:
> dd if=xm_c32_001.out of=/dev/rootvg/xm_c32_001
> Next, we copied the /etc/xen/xm_c32_001 configuration file to the
> replacement server. We generated a new UUID using the "uuidgen"
> utility. We also created a new MAC address.
> Finally, we started the
> xm create xm_c32_001
> Everything came up, but no network. From the root console we logged
> in then edited the /etc/sysconfig/network-scripts/ifcfg-eth0. Xen had
> apparently renamed the script and put in a DHCP configuration.
It's not Xen renaming the script
You changed the MAC address, so the
centos network init scripts will rename the ifcfg file, and generate
new default one (with dhcp).
rhel/centos ifcfg-eth* are based on MAC addresses.
> We just
> renamed the backup file and commented out the MAC address line and
> restarted networking, *and* ifdown eth0 then ifup eth0.
> It took a few seconds for the network to properly discover the new MAC
> address. Once that was done, everything worked beautifully.
> CentOS mailing list
CentOS mailing list