<html><body><p>Hi guys..<br><br>Well, today I confirmed that what Ulrich said is correct. If I update the VirtualDomain resource with the operation name "migrate_to" instead of<br>"migrate-to", it effectively overrides and enforces the <tt>1200ms</tt> default value to the new value. <br><br>I am wondering how I would have known that I was using the wrong operation name, when the initial operation name is already incorrect<br>when the resource is created? <br><br>This is what the meta data for my resource looked like after making the update: <br><br>[root@zs95kj VD]# date;pcs resource update zs95kjg110065_res op migrate_to 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 type=VirtualDomain)<br> Attributes: config=/guestxml/nfs1/zs95kjg110065.xml hypervisor=qemu:///system migration_transport=ssh<br> Meta Attrs: allow-migrate=true<br> Operations: start interval=0s timeout=120 (zs95kjg110065_res-start-interval-0s)<br> stop interval=0s timeout=120 (zs95kjg110065_res-stop-interval-0s)<br> monitor interval=30s (zs95kjg110065_res-monitor-interval-30s)<br> migrate-from interval=0s timeout=1200 (zs95kjg110065_res-migrate-from-interval-0s)<br> <font color="#FF0000">migrate-to interval=0s timeout=1200 (zs95kjg110065_res-migrate-to-interval-0s) <<< Original op name / value</font><br> <font color="#0000FF">migrate_to interval=0s timeout=360s (zs95kjg110065_res-migrate_to-interval-0s) <<< New op name / value</font><br><br><br>Where does that original op name come from in the VirtualDomain resource definition? How can we get the initial meta value changed and shipped with a valid operation name (i.e. migrate_to), and <br>maybe a more reasonable migrate_to timeout value... something significantly higher than 1200ms , i.e. 1.2 seconds ? Can I report this request as a bugzilla on the RHEL side, or should this go to my internal IBM bugzilla for KVM on System Z development? <br><br>Anyway, thanks so much for identifying my issue. I can reconfigure my 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><img width="16" height="16" src="cid:1__=8FBB0A26DF9642808f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Ken Gaillot ---01/19/2017 10:26:13 AM---On 01/19/2017 01:36 AM, Ulrich Windl wrote: >>>> Ken Gaillot "><font color="#424282">Ken Gaillot ---01/19/2017 10:26:13 AM---On 01/19/2017 01:36 AM, Ulrich Windl wrote: >>>> Ken Gaillot <kgaillot@redhat.com> schrieb am 18.01.</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Ken Gaillot <kgaillot@redhat.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, users@clusterlabs.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">01/19/2017 10:26 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">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>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 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 schema, the names could be verified at least (not meaning that the 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></tt><br><br><BR>
</body></html>