<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<pre>Hello Andrei,
you wrote:
>>As a workaround you could add dummy clone resource colocated with and
>>ordered after your DRBD masters and order VM after this clone.
Thanks for the idea. This looks like a good option to solve my problem.
I have also researched a little more and came up with an option which seems to work for my case.
Would you be so kind to evaluate if i understand it correctly?
As mentioned in the original thread
>> <i>Wed Apr 12 05:28:48 EDT 2023</i>
My system looks like this:
>>I am using a simple two-nodes cluster with Zvol -> DRBD -> Virsh in
>>primary/primary mode (necessary for live migration).
Where drbd-resources and zvol are clones.
So it is basically a chain of resources, first zvol then drbd then vm.
>From documentation i read that in those cases order constraints are not even necessary. This can be done with colocations constraints only
-> <a class="moz-txt-link-freetext" href="https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-orderconstraints-haar#s2-resourceorderlist-HAAR">https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-orderconstraints-haar#s2-resourceorderlist-HAAR</a>
There is stated:
>> A common situation is for an administrator to create a chain of ordered
>> resources, where, for example, resource A starts before resource B which
>> starts before resource C. If your configuration requires that you
>> create a set of resources that is colocated and started in order, you
>> can configure a resource group that contains those resources, as
>> described in <a class="xref" href="https://access.redhat.com/documentation/de-de/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-resourcegroups-HAAR">Section 6.5, “Resource Groups”</a>.
I can't create a Resource Group because apparently clone-resources are not supported. So i have the following setup now:
>> colocation colocation-mas-drbd-alarmanlage-clo-pri-zfs-drbd_storage-INFINITY inf: mas-drbd-alarmanlage clo-pri-zfs-drbd_storage
>> colocation colocation-pri-vm-alarmanlage-mas-drbd-alarmanlage-INFINITY inf: pri-vm-alarmanlage:Started mas-drbd-alarmanlage:Master
>> location location-pri-vm-alarmanlage-s0-200 pri-vm-alarmanlage 200: s0
Migration works flawless and also the startup is correct: zvol -> drbd -> vm
I am little bit concerned though. Does corosync work like an interpeter and knows the correct order when i do <colocation zvol/drbd> before <colocation drbd/vm>?
Another thing is the Multistate Constraint which i implanted -> pri-vm-alarmanlage:Started mas-drbd-alarmanlage:Master
Is this equivalent to the <order order-mas-drbd-alarmanlage-pri-vm-alarmanlage-mandatory mas-drbd-alarmanlage:promote pri-vm-alarmanlage:start> which i was trying to achieve?
Basically i just want to have zvol started then drbd stared and promoted to master state and then finally vm started. All on the same node.
Can you confirm that my cluster does this behavior permanently with this configuration.
Note that I would like to avoid any order constraints and dummy resources if possible. But if it is unavoidable let me know.
Thanks for the replies.
With kind regards
Philip.
</pre>
</body>
</html>