I think this is something we see. The workaround has basically
been to disabled clustering (lvm wise) when doing this kind of change, and to
handle it manually:
vgchange –c n <vg> to disable the cluster flag
lvmconf –disable-cluster on all nodes
rescan/discover lun, whatever, on all nodes
lvcreate on one node
lvchange –refresh on every node
lvchange –a y on one node
gfs_grow on one host (you can run this on the other to confirm,
it should say it can’t grow anymore)
When done, I’ve been putting things back how they were
with vgchange –c y, lvmconf –disable-cluster, though I think if I
you just left it unclustered it’d be fine… what you won’t
want to do is leave the vg clustered, but not –enable-cluster… if
you do this when you reboot the clustered volume groups won’t be
Hope this helps… if anyone knows of a definitive fix for
this I’d like to hear about it, we haven’t pushed for it since it
isn’t too big of a hassle and we aren’t constantly adding new
volumes, but it is a pain.
Brian Fair, UNIX Administrator, CitiStreet
From: linux-cluster-bounces redhat com
[mailto:linux-cluster-bounces redhat com] On Behalf Of Randy Brown
Sent: Tuesday, November 27, 2007 12:23 PM
To: linux clustering
Subject: [Linux-cluster] Adding new file system caused problems
I am running a two node cluster using Centos 5 that is
basically being used as a NAS head for our iscsi based storage. Here are
the related rpms and their versions I am using:
This morning I created a 100GB volume on our storage unit and proceeded to make
it available to the cluster so it could be served via NFS to a client on our
network. I used pvcreate and vgcreate as I always do and created a new
volume group. When I went to create the logical volume I saw this
Error locking on node nfs1-cluster.nws.noaa.gov: Volume group for uuid not
I figured I had done something wrong and tried to remove the Lvol and
couldn't. Lvdisplay showed that the logvol had been created and vgdisplay
looked good with the exception of the volume not being activated. So, I
ran vgchange -aly <Volumegroupname> which didn't return any error, but
also did not activate the volume. I then rebooted the node which made
everything OK. I could now see the VG and lvol, both were active and I
could now create the gfs file system on the lvol. The file system
mounted and I thought I was in the clear.
However, node #2 wasn't picking this new filesystem up at all. I stopped
the cluster services on this node which all stopped cleanly and then tried to
restart them. cman started fine but clvmd didn't. It hung on the
vgscan. Even after a reboot of node #2, clvmd would not start and
would hang on the vgscan. It wasn't until I shut down both nodes
completely and started cluster that both nodes could see the new filesystem.
I'm sure it's my own ignorance that's making this more difficult than it needs
to be. Am I missing a step? Is more information required to
help? Any assistance in figuring out what happened here would be greatly
appreciated. I know I going to need to do similar tasks in the future and
obviously can't afford to bring everything down in order for the cluster to see
a new filesystem.
P.S. Here is my cluster.conf:
[root nfs2-cluster ~]# cat /etc/cluster/cluster.conf
<cluster alias="ohd_cluster" config_version="114"
<clusternode name="nfs1-cluster.nws.noaa.gov" nodeid="1"
<device name="nfspower" port="8"
<clusternode name="nfs2-cluster.nws.noaa.gov" nodeid="2"
<device name="nfspower" port="7"
<failoverdomain name="nfs-failover" ordered="0"
<failoverdomainnode name="nfs1-cluster.nws.noaa.gov" priority="1"/>
<failoverdomainnode name="nfs2-cluster.nws.noaa.gov" priority="1"/>
<ip address="188.8.131.52" monitor_link="1"/>
force_unmount="0" fsid="30647" fstype="gfs"
options="no_root_squash,rw" path="" target="184.108.40.206/24"/>
force_unmount="0" fsid="54233" fstype="gfs"
<service autostart="1" domain="nfs-failover"
<fencedevice agent="fence_apc" ipaddr="192.168.42.30"