<html><body><p>Ken (and <font face="Default Sans Serif">Ulrich</font>), <br><br>Found it! You're right, we do deliver a man page... <br><br>man]# find . -name *Virtual* -print<br>./man7/ocf_heartbeat_VirtualDomain.7.gz<br><br># rpm -q --whatprovides /usr/share/man/man7/ocf_heartbeat_VirtualDomain.7.gz<br>resource-agents-3.9.7-4.el7_2.kvmibm1_1_3.1.s390x<br><br>Much obliged, sir(s). <br><br>Scott Greenlese ... IBM z/BX Solutions Test, Poughkeepsie, N.Y.<br> INTERNET: swgreenl@us.ibm.com <br> PHONE: 8/293-7301 (845-433-7301) M/S: POK 42HA/P966<br><br><br><img width="16" height="16" src="cid:1__=8FBB0A29DFC976058f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Ken Gaillot ---02/01/2017 10:33:07 AM---On 02/01/2017 09:15 AM, Scott Greenlese wrote: > Hi all..."><font color="#424282">Ken Gaillot ---02/01/2017 10:33:07 AM---On 02/01/2017 09:15 AM, Scott Greenlese wrote: > Hi all...</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">users@clusterlabs.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">02/01/2017 10:33 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [ClusterLabs] 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 02/01/2017 09:15 AM, Scott Greenlese wrote:<br>> Hi all...<br>> <br>> Just a quick follow-up.<br>> <br>> Thought I should come clean and share with you that the incorrect<br>> "migrate-to" operation name defined in my VirtualDomain<br>> resource was my mistake. It was mis-coded in the virtual guest<br>> provisioning script. I have since changed it to "migrate_to"<br>> and of course, the specified live migration timeout value is working<br>> 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<br>> for pacemaker resource man pages? I don't see any resource man pages<br>> installed<br>> on my system anywhere. I found this one online:<br>> </tt><tt><a href="https://www.mankier.com/7/ocf_heartbeat_VirtualDomain">https://www.mankier.com/7/ocf_heartbeat_VirtualDomain</a></tt><tt> but is there a<br>> more 'official' page I should refer our<br>> Linux KVM on System z customers to?<br><br>All distributions that I know of include the man pages with the packages<br>they distribute. Are you building from source? They are named like "man<br>ocf_heartbeat_IPaddr2".<br><br>FYI after following this thread, the pcs developers are making a change<br>so that pcs refuses to add an unrecognized operation unless the user<br>uses --force. Thanks for being involved in the community; this is how we<br>learn to improve!<br><br>> Thanks again for your assistance.<br>> <br>> Scott Greenlese ...IBM KVM on System Z Solution Test Poughkeepsie, N.Y.<br>> INTERNET: swgreenl@us.ibm.com<br>> <br>> <br>> Inactive hide details for "Ulrich Windl" ---01/27/2017 02:32:43 AM--->>><br>> "Scott Greenlese" <swgreenl@us.ibm.com> schrieb am 27."Ulrich Windl"<br>> ---01/27/2017 02:32:43 AM--->>> "Scott Greenlese" <swgreenl@us.ibm.com><br>> schrieb am 27.01.2017 um 02:47 in Nachricht<br>> <br>> From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de><br>> To: <users@clusterlabs.org>, Scott Greenlese/Poughkeepsie/IBM@IBMUS<br>> Cc: "Si Bo Niu" <niusibo@cn.ibm.com>, Michael Tebolt/Poughkeepsie/IBM@IBMUS<br>> Date: 01/27/2017 02:32 AM<br>> Subject: Antw: Re: [ClusterLabs] Antw: Re: Live Guest Migration timeouts<br>> for VirtualDomain resources<br>> <br>> ------------------------------------------------------------------------<br>> <br>> <br>> <br>>>>> "Scott Greenlese" <swgreenl@us.ibm.com> schrieb am 27.01.2017 um<br>> 02:47 in<br>> Nachricht<br>> <OF63CD0E10.D58C4C3D-ON002580B5.0005C410-852580B5.0009DBDE@notes.na.collabserv.c<br>> <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<br>> 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<br>> (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<br>> with<br>>> a valid operation name (i.e. migrate_to), and<br>>> maybe a more reasonable migrate_to timeout value... something<br>> 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></tt><br><br><BR>
</body></html>