9.3.3. Migrating Resources
Normally, when the cluster needs to move a resource, it fully restarts the resource (i.e. stops the resource on the current node and starts it on the new node).
However, some types of resources, such as Xen virtual guests, are able to move to another location without loss of state (often referred to as live migration or hot migration). In pacemaker, this is called resource migration. Pacemaker can be configured to migrate a resource when moving it, rather than restarting it.
Not all resources are able to migrate; see the Migration Checklist below, and those that can, won’t do so in all situations. Conceptually, there are two requirements from which the other prerequisites follow:
The cluster is able to accommodate both push and pull migration models by requiring the resource agent to support two special actions: migrate_to (performed on the current location) and migrate_from (performed on the destination).
In push migration, the process on the current location transfers the resource to the new location where is it later activated. In this scenario, most of the work would be done in the migrate_to action and, if anything, the activation would occur during migrate_from.
Conversely for pull, the migrate_to action is practically empty and migrate_from does most of the work, extracting the relevant resource state from the old location and activating it.
There is no wrong or right way for a resource agent to implement migration, as long as it works.
Migration Checklist
The resource may not be a clone.
The resource must use an OCF style agent.
The resource must not be in a failed or degraded state.
The resource agent must support migrate_to and migrate_from actions, and advertise them in its metadata.
The resource must have the allow-migrate meta-attribute set to true (which is not the default).
If an otherwise migratable resource depends on another resource via an ordering constraint, there are special situations in which it will be restarted rather than migrated.
For example, if the resource depends on a clone, and at the time the resource needs to be moved, the clone has instances that are stopping and instances that are starting, then the resource will be restarted. The scheduler is not yet able to model this situation correctly and so takes the safer (if less optimal) path.
Also, if a migratable resource depends on a non-migratable resource, and both need to be moved, the migratable resource will be restarted.
