[ClusterLabs] Live Guest Migration timeouts for VirtualDomain resources

Scott Greenlese swgreenl at us.ibm.com
Wed Feb 1 15:15:49 UTC 2017


Hi all...

Just a quick follow-up.

Thought I should come clean and share with you that the incorrect
"migrate-to" operation name defined in my VirtualDomain
resource was my mistake.  It was mis-coded in the virtual guest
provisioning script.  I have since changed it to "migrate_to"
and of course, the specified live migration timeout value is working
effectively now.  (For some reason, I assumed we were letting that
operation meta value default).

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
on my system anywhere.   I found this one online:
https://www.mankier.com/7/ocf_heartbeat_VirtualDomain  but is there a more
'official' page I should refer our
Linux KVM on System z customers to?

Thanks again for your assistance.

Scott Greenlese ...IBM KVM on System Z Solution Test Poughkeepsie, N.Y.
  INTERNET:  swgreenl at us.ibm.com




From:	"Ulrich Windl" <Ulrich.Windl at rz.uni-regensburg.de>
To:	<users at clusterlabs.org>, Scott Greenlese/Poughkeepsie/IBM at IBMUS
Cc:	"Si Bo Niu" <niusibo at cn.ibm.com>, Michael
            Tebolt/Poughkeepsie/IBM at IBMUS
Date:	01/27/2017 02:32 AM
Subject:	Antw: Re: [ClusterLabs] Antw: Re: Live Guest Migration timeouts
            for VirtualDomain resources



>>> "Scott Greenlese" <swgreenl at us.ibm.com> schrieb am 27.01.2017 um 02:47
in
Nachricht
<OF63CD0E10.D58C4C3D-ON002580B5.0005C410-852580B5.0009DBDE at notes.na.collabserv.c

m>:

> Hi guys..
>
> Well, today I confirmed that what Ulrich said is correct.  If I update
the
> VirtualDomain resource with the operation name  "migrate_to" instead of
> "migrate-to",  it effectively overrides and enforces the 1200ms default
> value to the new value.
>
> I am wondering how I would have known that I was using the wrong
operation
> name, when the initial operation name is already incorrect
> when the resource is created?

For SLES 11, I made a quick (portable non-portable unstable) try (print the
operations known to an RA):
 # crm ra info VirtualDomain |sed -n -e "/Operations' defaults/,\$p"
Operations' defaults (advisory minimum):

    start         timeout=90
    stop          timeout=90
    status        timeout=30 interval=10
    monitor       timeout=30 interval=10
    migrate_from  timeout=60
    migrate_to    timeout=120

Regards,
Ulrich

>
> This is what the meta data for my resource looked like after making the
> update:
>
> [root at zs95kj VD]# date;pcs resource update zs95kjg110065_res op
migrate_to
> timeout="360s"
> Thu Jan 26 16:43:11 EST 2017
> You have new mail in /var/spool/mail/root
>
> [root at zs95kj VD]# date;pcs resource show zs95kjg110065_res
> Thu Jan 26 16:43:46 EST 2017
>  Resource: zs95kjg110065_res (class=ocf provider=heartbeat
> type=VirtualDomain)
>   Attributes: config=/guestxml/nfs1/zs95kjg110065.xml
> hypervisor=qemu:///system migration_transport=ssh
>   Meta Attrs: allow-migrate=true
>   Operations: start interval=0s timeout=120
> (zs95kjg110065_res-start-interval-0s)
>               stop interval=0s timeout=120
> (zs95kjg110065_res-stop-interval-0s)
>               monitor interval=30s
(zs95kjg110065_res-monitor-interval-30s)
>               migrate-from interval=0s timeout=1200
> (zs95kjg110065_res-migrate-from-interval-0s)
>               migrate-to interval=0s timeout=1200
> (zs95kjg110065_res-migrate-to-interval-0s)   <<< Original op name / value
>               migrate_to interval=0s timeout=360s
> (zs95kjg110065_res-migrate_to-interval-0s)  <<< New op name / value
>
>
> 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
> 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?
>
> Anyway, thanks so much for identifying my issue.  I can reconfigure my
> resources to make them tolerate longer migration execution times.
>
>
> Scott Greenlese ... IBM KVM on System Z Solution Test
>   INTERNET:  swgreenl at us.ibm.com
>
>
>
>
> From:		 Ken Gaillot <kgaillot at redhat.com>
> To:		 Ulrich Windl <Ulrich.Windl at rz.uni-regensburg.de>,
>             users at clusterlabs.org
> Date:		 01/19/2017 10:26 AM
> Subject:		 Re: [ClusterLabs] Antw: Re: Live Guest Migration
timeouts for
>             VirtualDomain resources
>
>
>
> On 01/19/2017 01:36 AM, Ulrich Windl wrote:
>>>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 18.01.2017 um 16:32 in
> Nachricht
>> <4b02d3fa-4693-473b-8bed-dc98f9e3f3f3 at redhat.com>:
>>> On 01/17/2017 04:45 PM, Scott Greenlese wrote:
>>>> Ken and Co,
>>>>
>>>> Thanks for the useful information.
>>>>
>>
>> [...]
>>>>
>>>> Is this internally coded within the class=ocf provider=heartbeat
>>>> type=VirtualDomain resource agent?
>>>
>>> Aha, I just realized what the issue is: the operation name is
>>> migrate_to, not migrate-to.
>>>
>>> For technical reasons, pacemaker can't validate operation names (at the
>>> time that the configuration is edited, it does not necessarily have
>>> access to the agent metadata).
>>
>> 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).
>> BTW: Would a "crm configure verify" detect this kijnd of problem?
>>
>> [...]
>>
>> Ulrich
>
> Yes, it's in the resource agent meta-data. While pacemaker itself uses a
> small set of well-defined actions, the agent may define any arbitrarily
> named actions it desires, and the user could configure one of these as a
> recurring action in pacemaker.
>
> Pacemaker itself has to be liberal about where its configuration comes
> from -- the configuration can be edited on a separate machine, which
> doesn't have resource agents, and then uploaded to the cluster. So
> Pacemaker can't do that validation at configuration time. (It could
> theoretically do some checking after the fact when the configuration is
> loaded, but this could be a lot of overhead, and there are
> implementation issues at the moment.)
>
> Higher-level tools like crmsh and pcs, on the other hand, can make
> simplifying assumptions. They can require access to the resource agents
> so that they can do extra validation.
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20170201/86e8c173/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20170201/86e8c173/attachment-0002.gif>


More information about the Users mailing list