LVM

mickj · 11-13-2008, 03:59 PM

Using SUSE 10.1

Have storage connected to server that has snapshot capabilities.
In addition, it permits alterations (writes) to the the snapshot that do not affect the volume it was snapshoted from.

I want to mount the snapshot, but as LVM was used to create a VG on the main volume, the snapshot carries the same VG ID, LV ID and PV ID. I want to edit the metadata on the snapshot volume and modify the ID('s) so LVM doesn't think that the snapshot is a duplicate (as reported by vgscan).
I have used dd to read in the first 256 blocks and then used vi to edit some of characters of the ID fields (this info is in clear ASCII but I used the %!xxd option to display in hex/ascii format). I then wrote the modified file back to the storage (/dev/sda) using dd.

Reading notes on the metadata format, I confirmed it is writtten twice to the disk(storage) at 1200x and 1600x.

Question - is it "wrapped" with a CRC or other check characters??

So far, it is not clear that the contents of the modified file are read back from storage after having been written there with dd.

thanks
Mike

JZL240I-U · 11-14-2008, 06:13 AM

There is "lvrename", "vgrename". Why do you want to change the physical volume name?

mickj · 11-14-2008, 12:13 PM

I need to rename the PV so that the scan performed by vgscan or LVM at startup does not think the snapshot and master volume are the same PV.
If this check passes, then it should be possible to mount the snapshot via LVM as a different volume.

I have also found that the label written in the second sector carries the binary form of the PV ID.

JZL240I-U · 11-17-2008, 07:25 AM

I see. As a workaround you could create the second PV by hand and copy the rest over.

I presume you were not talking about the LVM snapshot facility? What signature of the PV does that create by the way?

Have you hex-edited the PV information or what did you do?

mickj · 11-18-2008, 11:07 AM

>As a workaround you could create the second PV by hand and copy the rest over

That would be, I think, labor intensive for the host and storage. Since the storage can create and manage thinly provisioned snapshots, would like to capitalize on that as much as possible.

>I presume you were not talking about the LVM snapshot facility?
No - haven't used that facility.

>What signature of the PV does that create by the way? - unsure of the question - I am guessing that the lvm creates a suitable PV metadata structure for its snapshot.

>Have you hex-edited the PV information or what did you do?
Yes - used dd to copy in the first 256 sectors from the device (/dev/sda) and then edited with vi and placing the screen in hex display mode - (:%!xxd). Unfortunately, after making the edits to the PV uuid in the label area (binary) and the PV uuid in the metadata area (2 copies, ASCII), the LUN was not recognized by pvscan utility.

I have been using the available tools - filter, pvchange, vgrename, but so far appears that when the new LUN is filtered out (to avoid conflict with the master volume), the tools will not operate on that LUN.

suggestions??

JZL240I-U · 11-19-2008, 01:22 AM

http://www.ibiblio.org/pub/Linux/doc...#snapshotintro

Would that help?

SpLaSh212 · 12-16-2008, 09:37 AM

Hey man,
I've needed to mount 2 cloned vg's on the same machine, one of them is the running vg (Production) and the other one is a cloned (or snapshot) version on the production VG.
Here is what you need to do to accomplish this task
1. MAKE SURE that no one is running LVM command while you'r doing this steps !
2. Create a temporary lvm dir (lets name it lvmtemp)

Code:

mkdir /lvmtemp

now copy the lvm.conf file from /etc/lvm to /lvmtemp

Code:

cp /etc/lvm/lvm.conf /lvmtemp

Export the variable LVM_SYSTEM_DIR to point to the temporary dir

Code:

export LVM_SYSTEM_DIR=/lvmtemp/

* This step is needed if you somehow reboot your system while editing your lvm.conf file and your system won't boot up

3.Change filter in your temporary /lvmtemp/lvm.conf file to only see the cloned LUN and your boot LUN

Code:

filter = [ "a|/dev/mapper/CLONE|","a|/dev/mapper/BOOT|","r/.*/" ]

4. Run pvscan command (you should see only the cloned LUN and the boot LUN)

5.Change the UUID's of the cloned PV & VG and rename to avoid duplicates and avoid clashes with the application LUN

Code:

pvchange --uuid /dev/mapper/CLONE --config 'global{activation=0}'  

vgchange --uuid vgAPP --config 'global{activation=0}'  

vgrename vgAPP vgAPP-clone --config 'global{activation=0}'

* The key here is the switch --config 'global{activation=0}' this deactivates device-mapper interaction and thus the commands only change the LVM metadata and not the devices on the system (otherwise the system will think you are changing the VG used for the production application)

6.Remove temporary LVM system directory and lvm.conf

Quote:

unset LVM_SYSTEM_DIR
rm -rf /lvmtemp

7. Run pvscan , vgscan & lvscan and see both physical volumes, volume groups and logical volumes now appear without any error messages about duplicate PV/VG UUID's

8.Activate the clone's VG

Code:

vgchange -ay vgAPP-clone

9. Recreate the LVM /dev/ nodes:

There is a minor bug in the vgchange command, even though we specified --config 'global{activation=0}' there was still minor interaction in /dev/vgAPP, renaming it to /dev/vgAPP-clone.

Without affecting any production application/volume group you can recreate these device node entries in /dev/:

Code:

vgmknodes

10.You should now be able to mount your /dev/vgAPP-clone volume groups, file systems and recover data as required