Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hello fellow drbd users
First post on the mailing list - thanks to the drbd devs and
contributors for this great piece of software. I've been using it for
years, it's been working flawlessly since then.
I have a production two-node pacemaker cluster (centos6) hosting a bunch
of virtual machines and I'm doing some tests for a planned upgrade to
centos7. With the elrepo rpm as well as the latest drbd-utils git, I get
the following syslog error message after "drbdadm up someresourcename":
NAME="$env{DEVICE}" ignored, kernel device nodes can not be renamed;
please fix it in /usr/lib/udev/rules.d/65-drbd.rules:8
Which effectively prevents /dev/drbd_blah from being created (eg,
"/dev/drbd_vm-mail-data"). This is easily fixed by symlinking:
-NAME=="", ENV{DEVICE}!="", NAME="$env{DEVICE}"
+ENV{DEVICE}!="", SYMLINK+="$env{DEVICE}"
(side question: I read that the by-res/ naming is 8.x legacy. Will the
9x series drop that and use exclusively /dev/drbd[0-9]+ and
/dev/drbd_{resourcename} devices ?)
Which leads me to a related issue with pacemaker: if I use
/dev/drbd_blah when defining resources without fixing the udv rules, the
drbd ocf resource file loops forever in my_udevsettle(). That's normal
since /dev/drbd_blah is not created, but there's no error message in
pacemaker log files so it took me a while to figure what the problem was
until I saw that the drbd ocf was stuck with sleep 1 processes (note to
others: look at the output of ps axf and any processes stuck under lrmd).
Isn't it possible to have more meaningful error reporting (or a
documented error code, but I don't see any in the OCF_ ones) ? Is it OK
to set a timeout in the ocf filer rather than relying on pacemaker's
defined timeout ? It would save some a lot of debugging time for the
8x->9x transition.
cheers
ivan