<html><body><p>Hi all... <br><br>Just a quick follow-up. <br><br>Thought I should come clean and share with you that the incorrect "migrate-to" operation name defined in my VirtualDomain<br>resource was my mistake. It was mis-coded in the virtual guest provisioning script. I have since changed it to "migrate_to" <br>and of course, the specified live migration timeout value is working effectively now. (For some reason, I assumed we were letting that<br>operation meta value default). <br><br>I was wondering if someone could refer me to the definitive online link for pacemaker resource man pages? I don't see any resource man pages installed<br>on my system anywhere. I found this one online: <a href="https://www.mankier.com/7/ocf_heartbeat_VirtualDomain">https://www.mankier.com/7/ocf_heartbeat_VirtualDomain</a> but is there a more 'official' page I should refer our<br>Linux KVM on System z customers to? <br><br>Thanks again for your assistance. <br><br>Scott Greenlese ...<tt>IBM KVM on System Z Solution Test</tt> Poughkeepsie, N.Y.<br> INTERNET: swgreenl@us.ibm.com <br><br><br><img width="16" height="16" src="cid:1__=8FBB0A29DFC20B778f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for "Ulrich Windl" ---01/27/2017 02:32:43 AM--->>> "Scott Greenlese" <swgreenl@us.ibm.com> schrieb am 27."><font color="#424282">"Ulrich Windl" ---01/27/2017 02:32:43 AM--->>> "Scott Greenlese" <swgreenl@us.ibm.com> schrieb am 27.01.2017 um 02:47 in Nachricht</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de></font><br><font size="2" color="#5F5F5F">To: </font><font size="2"><users@clusterlabs.org>, Scott Greenlese/Poughkeepsie/IBM@IBMUS</font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">"Si Bo Niu" <niusibo@cn.ibm.com>, Michael Tebolt/Poughkeepsie/IBM@IBMUS</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">01/27/2017 02:32 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Antw: Re: [ClusterLabs] Antw: Re: Live Guest Migration timeouts for VirtualDomain resources</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>>>> "Scott Greenlese" <swgreenl@us.ibm.com> schrieb am 27.01.2017 um 02:47 in<br>Nachricht<br><OF63CD0E10.D58C4C3D-ON002580B5.0005C410-852580B5.0009DBDE@notes.na.collabserv.c <br>m>:<br><br>> Hi guys..<br>> <br>> Well, today I confirmed that what Ulrich said is correct. If I update the<br>> VirtualDomain resource with the operation name "migrate_to" instead of<br>> "migrate-to", it effectively overrides and enforces the 1200ms default<br>> value to the new value.<br>> <br>> I am wondering how I would have known that I was using the wrong operation<br>> name, when the initial operation name is already incorrect<br>> when the resource is created?<br><br>For SLES 11, I made a quick (portable non-portable unstable) try (print the operations known to an RA):<br> # crm ra info VirtualDomain |sed -n -e "/Operations' defaults/,\$p"<br>Operations' defaults (advisory minimum):<br><br> start timeout=90<br> stop timeout=90<br> status timeout=30 interval=10<br> monitor timeout=30 interval=10<br> migrate_from timeout=60<br> migrate_to timeout=120<br><br>Regards,<br>Ulrich<br><br>> <br>> This is what the meta data for my resource looked like after making the<br>> update:<br>> <br>> [root@zs95kj VD]# date;pcs resource update zs95kjg110065_res op migrate_to<br>> timeout="360s"<br>> Thu Jan 26 16:43:11 EST 2017<br>> You have new mail in /var/spool/mail/root<br>> <br>> [root@zs95kj VD]# date;pcs resource show zs95kjg110065_res<br>> Thu Jan 26 16:43:46 EST 2017<br>> Resource: zs95kjg110065_res (class=ocf provider=heartbeat<br>> type=VirtualDomain)<br>> Attributes: config=/guestxml/nfs1/zs95kjg110065.xml<br>> hypervisor=qemu:///system migration_transport=ssh<br>> Meta Attrs: allow-migrate=true<br>> Operations: start interval=0s timeout=120<br>> (zs95kjg110065_res-start-interval-0s)<br>> stop interval=0s timeout=120<br>> (zs95kjg110065_res-stop-interval-0s)<br>> monitor interval=30s (zs95kjg110065_res-monitor-interval-30s)<br>> migrate-from interval=0s timeout=1200<br>> (zs95kjg110065_res-migrate-from-interval-0s)<br>> migrate-to interval=0s timeout=1200<br>> (zs95kjg110065_res-migrate-to-interval-0s) <<< Original op name / value<br>> migrate_to interval=0s timeout=360s<br>> (zs95kjg110065_res-migrate_to-interval-0s) <<< New op name / value<br>> <br>> <br>> Where does that original op name come from in the VirtualDomain resource<br>> definition? How can we get the initial meta value changed and shipped with<br>> a valid operation name (i.e. migrate_to), and<br>> maybe a more reasonable migrate_to timeout value... something significantly<br>> higher than 1200ms , i.e. 1.2 seconds ? Can I report this request as a<br>> bugzilla on the RHEL side, or should this go to my internal IBM bugzilla<br>> for KVM on System Z development?<br>> <br>> Anyway, thanks so much for identifying my issue. I can reconfigure my<br>> resources to make them tolerate longer migration execution times.<br>> <br>> <br>> Scott Greenlese ... IBM KVM on System Z Solution Test<br>> INTERNET: swgreenl@us.ibm.com <br>> <br>> <br>> <br>> <br>> From: Ken Gaillot <kgaillot@redhat.com><br>> To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>,<br>> users@clusterlabs.org <br>> Date: 01/19/2017 10:26 AM<br>> Subject: Re: [ClusterLabs] Antw: Re: Live Guest Migration timeouts for<br>> VirtualDomain resources<br>> <br>> <br>> <br>> On 01/19/2017 01:36 AM, Ulrich Windl wrote:<br>>>>>> Ken Gaillot <kgaillot@redhat.com> schrieb am 18.01.2017 um 16:32 in<br>> Nachricht<br>>> <4b02d3fa-4693-473b-8bed-dc98f9e3f3f3@redhat.com>:<br>>>> On 01/17/2017 04:45 PM, Scott Greenlese wrote:<br>>>>> Ken and Co,<br>>>>><br>>>>> Thanks for the useful information.<br>>>>><br>>><br>>> [...]<br>>>>><br>>>>> Is this internally coded within the class=ocf provider=heartbeat<br>>>>> type=VirtualDomain resource agent?<br>>>><br>>>> Aha, I just realized what the issue is: the operation name is<br>>>> migrate_to, not migrate-to.<br>>>><br>>>> For technical reasons, pacemaker can't validate operation names (at the<br>>>> time that the configuration is edited, it does not necessarily have<br>>>> access to the agent metadata).<br>>><br>>> BUT the set of operations is finite, right? So if those were in some XML<br>> schema, the names could be verified at least (not meaning that the<br>> operation is actually supported).<br>>> BTW: Would a "crm configure verify" detect this kijnd of problem?<br>>><br>>> [...]<br>>><br>>> Ulrich<br>> <br>> Yes, it's in the resource agent meta-data. While pacemaker itself uses a<br>> small set of well-defined actions, the agent may define any arbitrarily<br>> named actions it desires, and the user could configure one of these as a<br>> recurring action in pacemaker.<br>> <br>> Pacemaker itself has to be liberal about where its configuration comes<br>> from -- the configuration can be edited on a separate machine, which<br>> doesn't have resource agents, and then uploaded to the cluster. So<br>> Pacemaker can't do that validation at configuration time. (It could<br>> theoretically do some checking after the fact when the configuration is<br>> loaded, but this could be a lot of overhead, and there are<br>> implementation issues at the moment.)<br>> <br>> Higher-level tools like crmsh and pcs, on the other hand, can make<br>> simplifying assumptions. They can require access to the resource agents<br>> so that they can do extra validation.<br>> <br>> _______________________________________________<br>> Users mailing list: Users@clusterlabs.org <br>> </tt><tt><a href="http://lists.clusterlabs.org/mailman/listinfo/users">http://lists.clusterlabs.org/mailman/listinfo/users</a></tt><tt> <br>> <br>> Project Home: </tt><tt><a href="http://www.clusterlabs.org">http://www.clusterlabs.org</a></tt><tt> <br>> Getting started: </tt><tt><a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a></tt><tt> <br>> Bugs: </tt><tt><a href="http://bugs.clusterlabs.org">http://bugs.clusterlabs.org</a></tt><tt> <br><br><br><br></tt><br><br><BR>
</body></html>