[ClusterLabs] ocf:lvm2:VolumeGroup Probe Issue
Marc Smith
marc.smith at mcc.edu
Tue Nov 8 17:37:06 CET 2016
Hi,
First, I realize ocf:lvm2:VolumeGroup comes from the LVM2 package and
not resource-agents, but I'm hoping someone on this list is familiar
with this RA and can provide some insight.
In my cluster configuration, I'm using ocf:lvm2:VolumeGroup to manage
my LVM VG's, and I'm using the cluster to manage DLM and CLVM. I have
my constraints in place and everything seems to be working mostly,
except I'm hitting a glitch with ocf:lvm2:VolumeGroup and the initial
probe operation.
On startup, a probe operation (monitor) is issued for all of the
resources, but ocf:lvm2:VolumeGroup is returning OCF_ERR_GENERIC in
VolumeGroup_status() (via VolumeGroup_monitor()) since clvmd hasn't
started yet... this line in VolumeGroup_status() is the trouble:
VGOUT=`vgdisplay -v $OCF_RESKEY_volgrpname 2>&1` || exit $OCF_ERR_GENERIC
When clvmd is not running, 'vgdisplay -v name' will always return
something like this:
--snip--
connect() failed on local socket: No such file or directory
Internal cluster locking initialisation failed.
WARNING: Falling back to local file-based locking.
Volume Groups with the clustered attribute will be inaccessible.
VG name on command line not found in list of VGs: biggie
Volume group "biggie" not found
Cannot process volume group biggie
--snip--
And exits with a status of 5. So, my question is, do I patch the RA?
Or is there some cluster constraint I can add so a probe/monitor
operation isn't performed for the VolumeGroup resource until CLVM has
been started?
Any other advice? Is ocf:heartbeat:LVM or ocf:lvm2:VolumeGroup the
more popular RA for managing LVM VG's? Any comments from other users
on experiences using either (good, bad)? Both appear to achieve the
same function, just a bit differently.
Thanks,
Marc
More information about the Users
mailing list