Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> >> I now imagine that VM1 on cluster A becomes unreachable, so I want to > >> bring up VM1 on cluster B, and attach to it the replicated volume. > >> I have to make the volume primary on cluster B. > >> As long as the volume is primary on cluster A, I cannot make it primary > on > >> cluster B. > >> > >> I want to force the transition of the volume on cluster B from > secondary > >> to primary, without having to perform operations on cluster A. > >> > >> What is the proper sequence of operations / commands to accomplish > this? > >As in your expected experiment, you will need to cut the communication path > >between the two sites. > >The easiest way to do so is to run "drbdadm disconnect <resource>" on one > >of the sites; given your requirements, on cluster B. > > This changes the state of the volume on cluster B to "OutDated" and I am > unable > to change the volume to primary. I seem to still be missing something. No, that should be the correct way. (I'm not sure about your exact sequence of events - depending on what happens on cluster A, the "OutDated" might be okay (because the "original" Primary sees that there are outstanding writes), or it might be a DRBD 9 bug. (Would you please tell me what /proc/drbd says? I'll need the exact git hash.) > I tried to do --force to make the volume primary, but then I was unable to > import it to (OpenStack) cinder and attach it to an instance, since the id > was > not recognized. Hmmm, that's not related to DRBD.