[DRBD-user] DRBD9 drbdadm complains about fencing being in wrong section

Adam Goryachev mailinglists at websitemanagers.com.au
Thu Feb 18 12:50:31 CET 2016

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On 18/02/2016 22:34, Lars Ellenberg wrote:
> Of course, eventually we need to provide a more or less convenient way 
> to move 8.4 clusters to 9. And we will. But for now, if you have an 
> existing, working, production DRBD 8.4 cluster, I see no reason at all 
> to move that to DRBD 9, not in this year anyways. 
Aha, (light bulb moment). I think this perhaps clarifies the correct 
(current) state of things.

Please correct my statements below, as I suspect what I think is flawed...
1) A new production install should use DRBD9 because it is the most 
stable, the best performing, and has the really cool drbdmanage "magic"

2) If currently using drbd 8.4 (in production), there is no need or 
point in upgrading to drbd 9 (yet)

3) If we want to use the multi-peer technology in DRBD, then you can 
upgrade to drbd 9 and continue to use manually managed config files

4) If we want to use the multi-peer technology in DRBD, then you can 
upgrade to drbd 9 and manually convert/migrate to drbdmanage

I'm currently in the situation of 3 or 4, my concerns are that drbd9 is 
not yet production ready/stable, and that documentation for doing 3 or 4 
doesn't seem to be complete. You say there is no tool for 4 because it 
would need to handle every situation, and people do weird stuff (I agree 
with this view BTW, even if it would be nice to eventually get a tool 
that handles 70% of cases), however, it should be possible to at least 
document one example (which is a fairly common scenario) and leave the 
application/extension of this example to the admin.

Can you alleviate my concerns in relation to DRBD9 being stable? I'd 
really like to use the multiple peer technology, and from linbit 
reports, there are also some significant performance gains available.

I don't mind dealing with "rough edges" like difficult migration tools, 
or even lack of documentation, as long as things work reliably once 


More information about the drbd-user mailing list