<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 18, 2023 at 9:09 PM Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 2023-04-18 at 19:50 +0200, Vladislav Bogdanov wrote:<br>
> Btw, an interesting question. How much efforts would it take to<br>
> support a migration of a Master role over the nodes? An use-case is<br>
> drbd, configured for a multi-master mode internally, but with master-<br>
> max=1 in the resource definition. Assuming that resource-agent<br>
> supports that flow - <br>
> 1. Do nothing. <br>
> 2. Promote on a dest node. <br>
> 3. Demote on a source node.<br>
> <br>
> Actually just wonder, because may be it could be some-how achievable<br>
> to migrate VM which are on top of drbd which is not a multi-master in<br>
> pacemaker. Fully theoretical case. Didn't verify the flow in-the-<br>
> mind.<br>
> <br>
> I believe that currently only the top-most resource is allowed to<br>
> migrate, but may be there is some room for impovement?<br>
> <br>
> Sorry for the off-topic.<br>
> <br>
> Best<br>
> Vlad<br>
<br>
It would be worthwhile, but conceptually it's difficult to imagine a<br>
solution.<br>
<br>
If a resource must be colocated with the promoted role of another<br>
resource, and only one instance can be promoted at a time, how would it<br>
be possible to live-migrate? You couldn't promote the new instance<br>
before demoting the old one, and you couldn't demote the old one<br>
without stopping the dependent resource.<br>
<br>
You would probably need some really complex new constraint types and/or<br>
resource agent actions. Something like "colocate rsc1 with the promoted<br>
role of rsc2-clone, unless it needs to migrate, in which case call this<br>
special agent action to prepare it for running with a demoted instance,<br>
then demote the instance, then migrate the resource, then promote the<br>
new instance, then call this other agent action to return it to normal<br>
operation".<br></blockquote><div><br></div><div>Don't know if I got that correctly but wouldn't it rather have to be the</div><div>other way round?</div><div><br></div><div>- Migration source running on the promoted device</div><div>- Start target in receiving mode but without automatically starting once </div><div> state is complete (don't know it qemu supports that) and without access</div><div> to block-devices</div><div>- Start migration on the source side</div><div>- Once state difference is small enough disable VM on source side <a class="gmail_plusreply" id="plusReplyChip-0">+</a></div><div><a class="gmail_plusreply"> </a>transfer the leftover state</div><div>- Switch underlying filesystem/block-device to the destination</div><div>- Make qemu pick up at the state is has memorized and transferred</div><div><br></div><div>If we make the VM a promotable resource as well we could try to pull</div><div>the promoted state of fliesystem & VM to the other side once migration</div><div>is kicked off on the source-side.</div><div>Source side VM would refuse demotion as long as the state is passed</div><div>to the other side. We would need that measure of state difference is</div><div>small enough qemu is using when it kicks of the activation of the target.</div><div>At the end of demotion it would stop qemu and transfer the leftovers.</div><div>Then pacemaker could demote the source filesystem and promote on</div><div>the destination-side. That would trigger promoting the destination VM</div><div>which makes it run on the transfered state.</div><div>The above concept would probably work with cold migration to a </div><div>state-image on the destination side. But that is probably not interesting.</div><div>Don't know if qemu allows interception at the interesting points.</div><div>Don't know if we need the resource-interface to be extended for this.</div><div><br></div><div>Klaus <br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
Ken Gaillot <<a href="mailto:kgaillot@redhat.com" target="_blank">kgaillot@redhat.com</a>><br>
<br>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
<br>
</blockquote></div></div>