RE: [linux-lvm] Mirror between different SAN fabrics

[<mathias.herzog@postfinance.ch>]

[-- Attachment #1: Type: text/plain, Size: 6034 bytes --]

Hey

I use the same configuration as Ty and it seems that the lvm2 cluster
version doesn't like the stacked approach. When I'm creating the LV in
the last step, a locking error occurs:

---------------
#> lvcreate -m 1 -n MirrorLV -L 500M MirrorVG --corelog

    Logging initialised at Wed Dec  6 10:57:20 2006
    Set umask to 0077
    Loaded external locking library liblvm2clusterlock.so
    Finding volume group "MirrorVG"
    Archiving volume group "MirrorVG" metadata (seqno 1).
    Creating logical volume MirrorLV
    Creating logical volume MirrorLV_mimage_0
    Creating logical volume MirrorLV_mimage_1
    Creating volume group backup "/etc/lvm/backup/MirrorVG" (seqno 2).
  Error locking on node xxx: Internal lvm error, check syslog
  Error locking on node xxx: Internal lvm error, check syslog
  Failed to activate new LV.
    Wiping internal VG cache 
---------------

Syslog says:
lvm[3640]: Volume group for uuid not found: xxx

I can see the LV but since the state is NOT available I cannot access it

#> sudo vgdisplay -v MirrorVG
[...]
LV Name                /dev/MirrorVG/Mirror1LV
LV Status              NOT available
[...]


Mathias


> -----Original Message-----
> From: linux-lvm-bounces@redhat.com 
> [mailto:linux-lvm-bounces@redhat.com] On Behalf Of Matt P
> Sent: Freitag, 29 Dezember, 2006 00:25
> To: LVM general discussion and development
> Subject: Re: [linux-lvm] Mirror between different SAN fabrics
> 
> That's exactly the steps I used to test it out. The failure I 
> encountered was at the point of adding the StripeLVs to the 
> MirrorVG. I don't recall the error I got but I seem to recall 
> it being the same error as if the PV hadn't been pvcreated. 
> Although when I went through the process again just now, 
> without any errors... It's quite likely I mistyped or skipped 
> a step during my first attempt... 
> 
> I've gone through the whole process 4 times now from raw disk 
> to a mirrored LV without getting the error again.
> 
> It looks as though this could work and isn't nearly as crazy 
> as my initial configuration. I wonder now if anything wonky 
> will happen if we were to lose a disk or in the original post 
> if we lost one of the fabrics... 
> 
> 
> On 12/28/06, Ty! Boyack <ty@nrel.colostate.edu> wrote:
> 
> 	Actually, I'm quite surprised that this approach 
> mangles the lvm data.
> 	It seems that when you do a pvcreate on a block device, 
> LVM should (and
> 	I think, does) write the lvm metadata in a region of 
> that device, and 
> 	then never let anything touch that metadata.  This way, 
> if you do a 'dd
> 	if=/dev/zeros of=<PV-DEVICE>' it blanks out the device, 
> but the metadata
> 	is intact.
> 	
> 	So, if you do a 'pvcreate' on an LV, it should contain 
> a second copy of 
> 	the metadata, unique and independent from the first 
> copy on the original
> 	block device.  My tests on this has worked fine 
> (although my tests have
> 	been for building two VGs that have striped volumes 
> across the member 
> 	disks, and then a VG that creates a mirrored LV of the 
> striped volumes,
> 	so no multipathing is involved).  I'm wondering if we 
> can compare notes
> 	to see if I'm doing something that makes it look like 
> it's working -- I 
> 	don't want to be quietly destroying my lvm data and not 
> knowing it!!!
> 	
> 	I'm doing (roughly, block devices are a bit made-up):
> 	
> 	# prepare the physical volumes
> 	pvcreate /dev/sda
> 	pvcreate /dev/sdb 
> 	pvcreate /dev/sdc
> 	pvcreate /dev/sdd
> 	pvcreate /dev/sde
> 	
> 	# Create volume groups to contain uniquely striped volumes
> 	vgcreate Stripe1VG /dev/sda /dev/sdb
> 	vgcreate Stripe2VG /dev/sdc /dev/sdd
> 	
> 	# Create the striped volumes 
> 	lvcreate -i 2 -n Stripe1LV -L 1G Stripe1VG
> 	lvcreate -i 2 -n Stripe2LV -L 1G Stripe2VG
> 	
> 	# Make the striped volumes into PVs
> 	pvcreate /dev/Stripe1VG/Stripe1LV
> 	pvcreate /dev/Stripe2VG/Stripe2LV
> 	
> 	# Create the volume group for mirrored volumes 
> 	vgcreate MirrorVG /dev/Stripe1VG/Stripe1LV 
> /dev/Stripe2VG/Stripe2LV /dev/sde
> 	# (Had to use three PVs to have the mirror log in place)
> 	
> 	# Create the mirrored volume
> 	lvcreate -m 1 -n Mirror1LV -L 500M MirrorVG 
> 	
> 	# Filesystem, test, etc.  this will be GFS eventually, 
> but testing with
> 	ext3 for now.
> 	mke2fs -j -i16384 -v /dev/MirrorVG/Mirror1LV
> 	mkdir /mnt/mirror1lv
> 	mount /dev/MirrorVG/Mirror1LV /mnt/mirror1
> 	
> 	
> 	
> 	Is that about your procedure as well?  When does the 
> lvm data get mangled?
> 	
> 	(Sorry if this is going off topic - but if this is 
> solvable it might
> 	actually answer the original question...)
> 	
> 	-Ty!
> 	
> 	
> 	
> 	
> 	Matt P wrote:
> 	> This is basically the "messy" way I mentioned in my 
> reply above. I
> 	> found if you pvcreate the  LV device, you end up 
> mangling the lvm data
> 	> (this probably comes as little surprise) and it 
> breaks down after 
> 	> that. So, I ended up using losetup and an "image 
> file", one for/on
> 	> each fabric. Then did pvcreate on each loop device, 
> and made a new VG
> 	> containing both PVs and created the LV with mirroring.... It 
> 	> worked.... I did no performance, stability, or 
> failure testing...
> 	
> 	
> 	--
> 	-===========================-
> 	  Ty! Boyack
> 	  NREL Unix Network Manager
> 	  ty@nrel.colostate.edu 
> 	  (970) 491-1186
> 	-===========================-
> 	
> 	_______________________________________________
> 	linux-lvm mailing list
> 	linux-lvm@redhat.com
> 	https://www.redhat.com/mailman/listinfo/linux-lvm 
> <https://www.redhat.com/mailman/listinfo/linux-lvm> 
> 	read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> 	
> 
> 
> 

Sicherheitshinweis:
Dieses E-Mail von PostFinance ist signiert. Weitere Informationen finden Sie unter: 
https://www.postfinance.ch/e-signature.
Geben Sie Ihre Sicherheitselemente niemals Dritten bekannt.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4479 bytes --]