[DRBD-user] Testing new DRBD9 dedicated repo for PVE

Roland Kammerer roland.kammerer at linbit.com
Fri Dec 23 09:48:36 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 Thu, Dec 22, 2016 at 10:48:48PM +0100, Roberto Resoli wrote:
> (Bad start, forget the message with the wrong title...)
> I start a new thread, as suggested in [1];
> I would like to test the new Linbit repositorry for Proxmox Virtual
> Environment [2], and I need some preliminary information before starting.
> I refer to these statments from [1]:
> > For the second thing: There I would need more information. The version
> > we ship and the one from proxmox are very different. In between these
> > versions the architecture of DM was changed. Just as an example: If you
> > have two nodes in your cluster and you started DM only on one node, it
> > will never start up successfully. Or if only a minority of your overall
> > nodes is operational, drbdmanage will refuse to start, as it waits for a
> > majority.
> For the cluster I will do the test on: it is a three node PVE 4.4-2
> cluster, vm resides on two main nodes, while the third is dedicated to
> provide quorum and DRBD9 replication only. I will start the test on this
> node.
> First question. Is it possible to mix and match versions of drbdmanage
> on the cluster?
> I really would like to update the third node only at first, but now I
> don't think it is possible, given the differences between proxmox
> provided drbdmanage and linbit's one.

The obvious: You could update *all*, there are entries in the control
volume (the .drbdctrl resource acting as cluster DB) that are not used
any more, but they are just ignored on the new version.

A mix-and-match isn't a good idea in that scenario. Let's assume you
update the 3rd node only, then this would happen:

Assuming it is a node that has access to the .drbdctrl, it would try to
become the leader (i.e., switching .drbdctrl to primary). Here it
depends if the resource is already primary on another node or not. Let's
assume the "good" case, it loses the leader election and decides to
become a satellite. The old nodes would not talk to the new node via
TCP, but the new node expects the leader to talk to it, it would never
receive it's initial configuration. It would just idle around. In order
to remove any potential leftover (autogenerated .res files), the first
thing a node does is to remove all the old autogenerated .res files. So
by starting the new version, you lost all your DM .res files and can not
even manually "drbdadm up" them. For completeness the "bad" case: The
two old nodes idle around and have .drbdctrl as Secondary. The new one
comes and decides to become the leader and switches .drbdctrl to
Primary. The old nodes don't expect that, and would try to switch
.drbdctrl to Primary to store some information (how things worked in the
old version), but a leader never releases the .drbdctrl (new

So, this is essentially a stop-the-world and then upgrade scenario.

Regards, rck

More information about the drbd-user mailing list