[linux-lvm] Mirror between different SAN fabrics
mathias.herzog at postfinance.ch
mathias.herzog at postfinance.ch
Fri Jan 5 12:27:56 UTC 2007
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 at redhat.com
> [mailto:linux-lvm-bounces at 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 at 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 at nrel.colostate.edu
> (970) 491-1186
> -===========================-
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4479 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20070105/29f8f9d7/attachment.p7s>
More information about the linux-lvm
mailing list