* [linux-lvm] Steps to "clone" a volume group
@ 2007-11-22 15:18 Bryn M. Reeves
2007-11-22 16:05 ` Alasdair G Kergon
0 siblings, 1 reply; 6+ messages in thread
From: Bryn M. Reeves @ 2007-11-22 15:18 UTC (permalink / raw)
To: LVM general discussion and development
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Folks,
This question seems to come up from time to time and although it's
easily possible with the current tools the steps aren't obvious to everyone.
There are a number of reasons why people want to do this; accessing
SAN-based snapshots of LVM PVs, working with system images from
virtualised hosts etc.
I wrote some notes on how to do this using pvchange/vgchange/vgrename
which you'll find below. I'll add this to the wiki but if there are any
suggestions/corrections let me know & I'll include those before I set up
the page.
Regards,
Bryn.
Cloning LVM2 Volume Groups
==========================
These instructions describe the steps required to clone an LVM2 volume
group by creating a duplicate copy of the physical storage (PVs). This
requires the VG be deactivated while the clone is created and
re-named.
Linux loopback devices (/dev/loopN) are used in this example and
provide a convenient method for testing. The volume group being
cloned, t0 consists of two PVs originally present on /dev/loop0 and
/dev/loop1. A new volume group named t0-clone will be created on
devices /dev/loop2 and /dev/loop3.
1. Deactivate the VG
# vgchange -an t0
2. Create the cloned PV(s)
E.g., dd, clone LUNs on storage, break mirror etc.
# dd if=/dev/loop0 of=/dev/loop2
# dd if=/dev/loop1 of=/dev/loop3
3. For each original PV, create a filter entry in /etc/lvm/lvm.conf to
temporarily mask the PV from the LVM tools.
Preserve a copy of the original filtering rules so that it can be
restored at the end of the process, for example:
# cp /etc/lvm/lvm.conf /etc/lvm/lvm.conf.orig
To exclude the original loopback devices /dev/loop0 and /dev/loop1, the
filter line could look like this:
filter = [ "r|/dev/loop0|", "r|/dev/loop1|", "a|.*|" ]
Or, using a regex to match both devices with a single rule:
filter = [ "r|/dev/loop[01]|", "a|.*|" ]
Once the filters are set up, remove the LVM persistent cache:
# rm -f /etc/lvm/.cache [versions before 2.02.23]
OR
# rm -f /etc/lvm/cache/.cache [version 2.02.23 or later]
Verify that the filtering is correct by running pvscan:
# pvscan
PV /dev/loop2 VG t0 lvm2 [60.00 MB / 40.00 MB free]
PV /dev/loop3 VG t0 lvm2 [60.00 MB / 40.00 MB free]
Total: 2 [120.00 MB] / in use: 2 [120.00 MB] / in no VG: 0 [0 ]
Only the cloned PVs should be displayed. If the original PVs appear,
check the syntax of the filtering rule and clear the persistent cache
again.
4. Modify the cloned volume group name, ID and physical volume IDs to
avoid name and UUID clashes between the original and cloned devices:
For each cloned physical volume, run:
# pvchange --uuid /path/to/physical/volume
This will generate a new random UUID for the specified physical volume
and update the volume group metadata to reflect the changed identity.
For example:
# pvchange --uuid /dev/loop2
Physical volume "/dev/loop2" changed
1 physical volume changed / 0 physical volumes not changed
# pvchange --uuid /dev/loop3
Physical volume "/dev/loop3" changed
1 physical volume changed / 0 physical volumes not changed
Generate a new UUID for the entire volume group using vgchange:
# vgchange --uuid t0
Volume group "t0" successfully changed
Finally, rename the cloned VG:
# vgrename t0 t0-clone
5. Remove filtering rules & verify both VGs co-exist correctly
Restore the original filtering configuration and wipe the persistent cache:
# cp /etc/lvm/lvm.conf.orig /etc/lvm/lvm.conf
cp: overwrite `/etc/lvm/lvm.conf'? y
# rm -f /etc/lvm/.cache
Run pvscan to verify the new and old VGs are correctly displayed:
# pvscan
PV /dev/loop0 VG t0 lvm2 [60.00 MB / 40.00 MB free]
PV /dev/loop1 VG t0 lvm2 [60.00 MB / 40.00 MB free]
PV /dev/loop2 VG t0-clone lvm2 [60.00 MB / 40.00 MB free]
PV /dev/loop3 VG t0-clone lvm2 [60.00 MB / 40.00 MB free]
Total: 4 [240.00 MB] / in use: 4 [240.00 MB] / in no VG: 0 [0 ]
6. Activate volume groups
Both the original and cloned VGs can now be activated simultaneously:
# vgchange -ay t0
1 logical volume(s) in volume group "t0" now active
# vgchange -ay t0-clone
1 logical volume(s) in volume group "t0-clone" now active
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHRZ3T6YSQoMYUY94RAhnYAKCSiTbv2kf9VzKvuA/d0pHFnuerJwCeMiM4
9z4sfBZlkMDzNhuTd54cqSk=
=gi+p
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] Steps to "clone" a volume group
2007-11-22 15:18 [linux-lvm] Steps to "clone" a volume group Bryn M. Reeves
@ 2007-11-22 16:05 ` Alasdair G Kergon
2007-11-26 16:58 ` Bryn M. Reeves
0 siblings, 1 reply; 6+ messages in thread
From: Alasdair G Kergon @ 2007-11-22 16:05 UTC (permalink / raw)
To: LVM general discussion and development
Fine for testing, but if running this on a production system
you should tweak this so that your machine remains bootable
should it crash at any stage of the procedure.
On Thu, Nov 22, 2007 at 03:18:43PM +0000, Bryn M. Reeves wrote:
> 1. Deactivate the VG
Not necessary if done as follows.
> 2. Create the cloned PV(s)
> 3. For each original PV, create a filter entry in /etc/lvm/lvm.conf to
> temporarily mask the PV from the LVM tools.
Swap order there: the system's lvm.conf should mask out the new PVs
*before* they get created.
> Once the filters are set up, remove the LVM persistent cache:
Never required: the pvscan will do that for you.
Create a temporary alternative lvm system directory holding
a copy of lvm.conf that has filters to accept only
the new copies of the PVs and set LVM_SYSTEM_DIR to use it.
Only now do step 2.
> 4. Modify the cloned volume group name, ID and physical volume IDs to
> avoid name and UUID clashes between the original and cloned devices:
(with LVM_SYSTEM_DIR set)
> 5. Remove filtering rules & verify both VGs co-exist correctly
discard LVM_SYSTEM_DIR env var & directory
Alasdair
--
agk@redhat.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] Steps to "clone" a volume group
2007-11-22 16:05 ` Alasdair G Kergon
@ 2007-11-26 16:58 ` Bryn M. Reeves
0 siblings, 0 replies; 6+ messages in thread
From: Bryn M. Reeves @ 2007-11-26 16:58 UTC (permalink / raw)
To: LVM general discussion and development
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alasdair G Kergon wrote:
> Fine for testing, but if running this on a production system
> you should tweak this so that your machine remains bootable
> should it crash at any stage of the procedure.
>
> On Thu, Nov 22, 2007 at 03:18:43PM +0000, Bryn M. Reeves wrote:
>> 1. Deactivate the VG
>
> Not necessary if done as follows.
Thanks Alasdair!
I'll incorporate your fixes into the instructions and add them to the wiki.
Regards,
Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHSvs96YSQoMYUY94RApYJAKDZ0fkcF2+IqS+w6iWER66BvXZ/zwCaA9tw
INz7sk+N8WuS8pNG9ZjnRxY=
=R5TP
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] steps to clone a volume group
2008-11-15 2:55 ` Alasdair G Kergon
@ 2008-11-17 22:58 ` Michael Jensen
0 siblings, 0 replies; 6+ messages in thread
From: Michael Jensen @ 2008-11-17 22:58 UTC (permalink / raw)
To: LVM general discussion and development
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]
The information shown from a nov 2007 post has been very useful - much appreciated.
There are some circumstances with the case I am working on that complicates the process a bit.
After having removed the master volume from the host and presenting just a snapshot, I have been able to change the physical uuid, and rename the volume group. If I then re-introduce the master volume there is no conflict (no-duplicates) found by the lvm utilities and can mount both sucessfully.
The constraints I am operating under require the master volume not to disappear - i.e. production system and volume.
If I filter out the snapshot and leave the accept (a) portion - "a|.*|" in the filter line, then a conflict is reported by pvscan, but not between sda and sdb but between sdb and the device-mapper string that appears to use the FC WWN.
If I remove the accept portion then there is no conflict during pvscan.
If I attempt to do a --
pvchange --uuid /dev/sda
Failed to read physical volume /dev/sda
0 physical volumes changed / 0 physical volumes not changed
Is the filtered out device name (/dev/sda) supposed to be available to the lvm utilities?
thanks,
mike
________________________________
From: Alasdair G Kergon <agk@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Sent: Friday, November 14, 2008 6:55:15 PM
Subject: Re: [linux-lvm] Editing LVM 2 metadata
On Fri, Nov 14, 2008 at 06:37:51PM -0800, Michael Jensen wrote:
> I have a need to edit the metadata on an LVM2 PV.
Why?
If you really have to, please do this using the supplied tools - it's *much*
easier!
vgcfgbackup gives you a text file, edit it, vgcfgrestore puts it back.
If you need to edit the label too, careful use of pvcreate --restorefile --uuid
plus vgcfgrestore lets you do that.
Alasdair
--
agk@redhat.com
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
[-- Attachment #2: Type: text/html, Size: 3240 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] steps to clone a volume group
[not found] <1755237768.33050951226964401629.JavaMail.root@mail2.its.carleton.edu>
@ 2008-11-17 23:27 ` Rich Graves
2008-11-18 0:06 ` Michael Jensen
0 siblings, 1 reply; 6+ messages in thread
From: Rich Graves @ 2008-11-17 23:27 UTC (permalink / raw)
To: linux-lvm
I've had that problem too. Two workarounds. Here's what I usually do:
1a) Map the snapshot LUN to a *different* host than the production machine.
1b) Change the UUID and VG/LV there.
1c) *Then* map the LUN to the production machine.
Alternatively (untested):
2a) service haldaemon stop; service multipathd stop; service lvm2-monitor stop (not sure which of these is really necessary)
2b) Map the snapshot to the production server in the SAN.
2c) Manually add with echo '- - -' > /sys/class/scsi_host/hostN/scan
2d) Change UUID and VG/LV.
2e) Manually remove with echo 1 > /sys/block/sdX/device/delete
2f) service haldaemon start; service multipathd start; service lvm2-monitor start
--
Rich Graves http://claimid.com/rcgraves
Carleton.edu Sr UNIX and Security Admin
CMC135: 507-222-7079 Cell: 952-292-6529
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] steps to clone a volume group
2008-11-17 23:27 ` Rich Graves
@ 2008-11-18 0:06 ` Michael Jensen
0 siblings, 0 replies; 6+ messages in thread
From: Michael Jensen @ 2008-11-18 0:06 UTC (permalink / raw)
To: LVM general discussion and development
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
Option 1 we are doing now but trying to avoid due to software license fees, etc.
not a vet yet with linux syntax --
trying item 2c and subbing host0 for hostN -- getting --
bash: echo: write error: invalid argument
i'm sure its something very obvious, but not too me...
Mike
________________________________
From: Rich Graves <rgraves@carleton.edu>
To: linux-lvm@redhat.com
Sent: Monday, November 17, 2008 3:27:43 PM
Subject: Re: [linux-lvm] steps to clone a volume group
I've had that problem too. Two workarounds. Here's what I usually do:
1a) Map the snapshot LUN to a *different* host than the production machine.
1b) Change the UUID and VG/LV there.
1c) *Then* map the LUN to the production machine.
Alternatively (untested):
2a) service haldaemon stop; service multipathd stop; service lvm2-monitor stop (not sure which of these is really necessary)
2b) Map the snapshot to the production server in the SAN.
2c) Manually add with echo '- - -' > /sys/class/scsi_host/hostN/scan
2d) Change UUID and VG/LV.
2e) Manually remove with echo 1 > /sys/block/sdX/device/delete
2f) service haldaemon start; service multipathd start; service lvm2-monitor start
--
Rich Graves http://claimid.com/rcgraves
Carleton.edu Sr UNIX and Security Admin
CMC135: 507-222-7079 Cell: 952-292-6529
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
[-- Attachment #2: Type: text/html, Size: 2675 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-11-18 0:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-22 15:18 [linux-lvm] Steps to "clone" a volume group Bryn M. Reeves
2007-11-22 16:05 ` Alasdair G Kergon
2007-11-26 16:58 ` Bryn M. Reeves
-- strict thread matches above, loose matches on Subject: below --
2008-11-15 2:37 [linux-lvm] Editing LVM 2 metadata Michael Jensen
2008-11-15 2:55 ` Alasdair G Kergon
2008-11-17 22:58 ` [linux-lvm] steps to clone a volume group Michael Jensen
[not found] <1755237768.33050951226964401629.JavaMail.root@mail2.its.carleton.edu>
2008-11-17 23:27 ` Rich Graves
2008-11-18 0:06 ` Michael Jensen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).