Bug 453594 - wrong start order: clvmd starts after qdiskd
wrong start order: clvmd starts after qdiskd
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: lvm2-cluster (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: LVM and device-mapper development team
Cluster QE
: Documentation
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-01 10:25 EDT by Herbert L. Plankl
Modified: 2010-07-23 10:36 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-23 10:35:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Herbert L. Plankl 2008-07-01 10:25:03 EDT
Description of problem:
I'm using a RHEL5.2 Cluster with lvm2, gfs2 and qdiskd (cluster designed for 2
datacentres).
To be able to use a (c)mirrored-qdisk I'm using a clustered volume-group for a
lv which is used by qdiskd. I don't know why, but per default qdiskd starts
before clvmd and so qdiskd cannot be started. I changed the order and everything
works fine.

Here are my changes:

qdiskd:
from: "# chkconfig: - 22 78" to: "# chkconfig: - 24 76"

clvmd:
from "# chkconfig: - 24 76" to: "# chkconfig: - 22 78"


Version-Release number of selected component (if applicable):
RHEL5.2
Comment 3 Lon Hohberger 2010-07-23 10:35:58 EDT
qdiskd is required for quorum and does not run on top of clvmd without being started manually; this is documented in section 1.4 under "Limitations" in the qdisk man page:

       *  Currently, the quorum disk daemon is difficult to use with CLVM if the quorum disk resides on a CLVM logical volume.  CLVM requires a quo-
       rate cluster to correctly operate, which introduces a chicken-and-egg problem for starting the cluster: CLVM needs  quorum,  but  the  quorum
       daemon needs CLVM (if and only if the quorum device lies on CLVM-managed storage).  One way to work around this is to *not* set the cluster’s
       expected votes to include the quorum daemon’s votes.  Bring all nodes online, and start the quorum daemon *after* the whole cluster  is  run-
       ning.  This will allow the expected votes to increase naturally.

Note You need to log in before you can comment on or make changes to this bug.