FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 03-01-2010, 06:47 PM
Kwan Lowe
 
Default Success moving Xen LVMs from 32 to 64bit host

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.

+++Footnote
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.
+++Footnote

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
instance:

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. 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@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 03-02-2010, 06:10 AM
henry ritzlmayr
 
Default Success moving Xen LVMs from 32 to 64bit host

> 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
> instance:

Since you moved your virtual machine, you wouldn´t have to create a new
UUID and no new MAC address. This is only required if you copy a virtual
machine and if you want both up at the same time.

> 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. We just
> renamed the backup file and commented out the MAC address line and
> restarted networking, *and* ifdown eth0 then ifup eth0.

This is because you changed the MAC address. If you would have left it
at the original value, the network would have started right away with
the old config.

Henry




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 03-02-2010, 08:14 AM
Pasi Kärkkäinen
 
Default Success moving Xen LVMs from 32 to 64bit host

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.
>
> +++Footnote
> 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.
> +++Footnote
>
> 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
> instance:
>
> 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.

-- Pasi

> 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@centos.org
> http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 03-02-2010, 02:20 PM
Kwan Lowe
 
Default Success moving Xen LVMs from 32 to 64bit host

Thanks Henry...

On Tue, Mar 2, 2010 at 2:10 AM, henry ritzlmayr <centos@rc0.at> wrote:
>> 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
>> instance:
>
> Since you moved your virtual machine, you wouldn´t have to create a new
> UUID and no new MAC address. This is only required if you copy a virtual
> machine and if you want both up at the same time.


Yes.. It's possible that we may have multiple copies of these
systems.. Also, I un
>> 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. We just
>> renamed the backup file and commented out the MAC address line and
>> restarted networking, *and* ifdown eth0 then ifup eth0.
>
> This is because you changed the MAC address. If you would have left it
> at the original value, the network would have started right away with
> the old config.




Yes.. My error caused by re-using a script that autogenerated the
config file. I had been playing with VMWare Lab Manager recently and
was looking to emulate the template functionality in Xen.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 03-02-2010, 02:22 PM
Kwan Lowe
 
Default Success moving Xen LVMs from 32 to 64bit host

On Tue, Mar 2, 2010 at 4:14 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:

> 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.

Thanks Pasi...
Pretty cool feature... I was overly enthusiastic in trying to figure
out why I couldn't see the vm after I booted it. If I'd waited or
re-arp'ed it would have worked without my meddling. Chalk a point up
for CentOS :P
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 03-03-2010, 03:07 AM
Ted Kaczmarek
 
Default Success moving Xen LVMs from 32 to 64bit host

The network should not have been an issue, are you sure you used the same vm config on both hosts?
That means the mac address would stay the same, and their should not be any L2 related issues, that
are related to vm anyway.

Ted


On Mar 1, 2010, at 2:47 PM, 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.
>
> +++Footnote
> 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.
> +++Footnote
>
> 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
> instance:
>
> 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. 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@centos.org
> http://lists.centos.org/mailman/listinfo/centos

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 03-03-2010, 07:10 AM
Kwan Lowe
 
Default Success moving Xen LVMs from 32 to 64bit host

On Tue, Mar 2, 2010 at 11:07 PM, Ted Kaczmarek <tedkaz@gmail.com> wrote:
> The network should not have been an issue, are you sure you used the same vm config on both hosts?
> That means the mac address would stay the same, and their should not be any L2 related issues, that
> are related to vm anyway.

It appears to have been my error and the vmware config didn't need to
be changed. I'd originally copied the file unchanged, but on the new
host the network did not seem to be working. If I'd have waited a few
more minutes the switches probably would have caught up.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 07:04 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org