[linux-lvm] multiple vg using the same name

Heinz J. Mauelshagen Mauelshagen at sistina.com
Mon Jun 18 09:52:58 UTC 2001


On Sun, Jun 17, 2001 at 02:11:27PM +0200, Anders Henke wrote:
> Hi,
> 
> I'm currently thinking about clustering our storage arrays into a san structure
> and how to organize usually identical systems with lvm. I'd like to avoid 
> giving each host a different name for its VG in order to have an identical
> /etc/fstab on every machine (you don't want to alter a mount-option for a
> single mountpoint on hundreds of machines by hand or by sed).

Changing /etc/fstab by sed is actually quite simple IMHO.
Put something along the lines of this into your startup script chain before
the local mounts after running vgscan.

#!/bin/sh
F=/etc/fstab T=/tmp/fstab.$$
sed "s?\(dev/vg_\)[^/]*/?\1${HOSTNAME}/?" $F > $T
cp $T $F; rm -f $T; unset F T

> 
> I've x machines with x local LVM installations. Each machine uses e.g. 
> /dev/vg/spool as a LV. These local LVs have been installed the usual way
> (pvcreate, vgcreate, lvcreate), so each VG has its own UUID and the LVM
> should use the suitable UUIDs to gather the PVs to the suitable VG.
> 
> Our idea is to take these PVs via a FC-SAN into one structure, the individual
> hosts can only see 'their' storage, but failover-nodes can see every PV in 
> the SAN so they can completely take a failed node offline (kick the big, red
> power button), remount its LV and perform a full take-over.
> 
> What happens if the physical volumes of one machine becomes additionaly
> available to a second machine, so that the second machine has to see
> e.g. 2, 4 or 8 logical volumes with originally the same name (/dev/vg/spool)? 
> 
> -lvm completely crashes 

No (hopefully not ;-)

> -only one vg shows up

That's how pv_read_all_pv_of_vg(), the library function which reads the metadata
in from the physical volumes behaves today. The PV uuid list is read from
the first physical volume found, which has the requested VG name in its
metadata. The second VG with the same name will be ignored :-(

BTW: future versions of the LVM will probably have uuid support on the
command line like for eg. "vgchange -ay -u VolumeGroupUUID VolumeGroupName".

> -the VGs or LVs are temporarily being renamed when doing 'vgscan -a'

No

> -the VGs or LVs are permanently being renamed when doing 'vgscan -a'

No. I think renaming the LVs is not needed anyway in case we had support
to rename the VG which would give us unique path names again.

> 
> What happens if one machine failes, doesn't perform a umount/'vgchange -a n'?
> Does the failover-node have a chance to use this VG/LV?

With the existing code only in case the VG names differ.

> 
> I now that somehow I have to figure a way out which VG belongs to which machine,
> but this may be solved via a map of each machines VG UUID, although just
> offering a /dev/vg_${hostname}/spool and 'seeing' the VG might be also cool :-)

That could be configurable with the existing LVM software and would cover
the take over quite happily, because the volume group names would be unique.

See above mentioned script.

> 
> 
> Anders
> -- 
> Schlund + Partner AG              Systemadministration and Security
> Erbprinzenstrasse 4-12            v://49.721.91374.50
> D-76133 Karlsruhe                 f://49.721.91374.212
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

-- 

Regards,
Heinz    -- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen at Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



More information about the linux-lvm mailing list