[ClusterLabs] kvm live migration, resource moving

Cédric Dufour - Idiap Research Institute cedric.dufour at idiap.ch
Thu Feb 4 09:55:31 EST 2016


One thing you should keep it mind in the context of HA:

If migration is triggered by a node failing somehow (but still sane
enough to allow migration), and several VMs must be migrated
simultaneously, then beware of network bandwith vs. VMs size (RAM-wise)!
Migrations may timeout *way* before they're done.

Or, when manually migrating many VMs away from a node, make sure to
proceed with no more VMs-at-a-time than your bandwith and timeouts allow.

(been there for you ;-) )

On 04/02/16 14:17, Kyle O'Donnell wrote:
> Thanks very much Cédric
>
> I've added migrate_to/from to my config:
>
> primitive tome_kvm ocf:heartbeat:VirtualDomain \
>         params config="/ocfs2/d01/tome/tome.xml" hypervisor="qemu:///system" migration_transport="ssh" force_stop="false" \
>         meta allow-migrate="true" target-role="Started" \
>         op start timeout="120s" interval="0" \
>         op stop timeout="120s" interval="0" \
>         op monitor timeout="30" interval="10" depth="0" \
>         op migrate_to timeout="60s" interval="0" \
>         op migrate_from timeout="60s" interval="0" \
>         utilization cpu="4" hv_memory="4096"
>
> when I run crm resource migrate guest nodeX nothing happens now:
>
> # crm resource status tome_kvm
> resource tome_kvm is running on: ny4j1-kvm02 
> # crm resource migrate tome_kvm ny4j1-kvm01 
> # echo $?
> 0
> # crm resource status tome_kvm
> resource tome_kvm is running on: ny4j1-kvm02 
>
> .... and I just figured it out!
>
> I had:
> location cli-prefer-tome tome_kvm inf: ny4j1-kvm02
>
> removed that and I am all good!
>
> Thanks everyone!!!
>
>
> ----- Original Message -----
> From: "Cédric Dufour - Idiap Research Institute" <cedric.dufour at idiap.ch>
> To: "users" <users at clusterlabs.org>
> Sent: Thursday, February 4, 2016 8:09:10 AM
> Subject: Re: [ClusterLabs] kvm live migration, resource moving
>
> Hello,
>
> Here, we have live migration working like a charm through the cluster.
> Below the XML expert of a resource configuration:
>
> <resources>
>   <group id="FOOBAR">
>     <primitive id="FOOBAR-LibvirtQemu" class="ocf" provider="custom"
> type="LibvirtQemu">
>       <instance_attributes id="FOOBAR-LibvirtQemu-IA">
>         <nvpair id="FOOBAR-LibvirtQemu-IA-config" name="config"
> value="/havc/config/libvirt/FOOBAR.xml"/>
>       </instance_attributes>
>       <meta_attributes id="FOOBAR-LibvirtQemu-MA">
>         <nvpair id="FOOBAR-LibvirtQemu-MA-allow-migrate"
> name="allow-migrate" value="true"/>
>       </meta_attributes>
>       <operations>
>         <op id="FOOBAR-LibvirtQemu-OP-monitor" name="monitor"
> timeout="30s" interval="60s"/>
>         <op id="FOOBAR-LibvirtQemu-OP-start" name="start" timeout="60s"
> interval="0"/>
>         <op id="FOOBAR-LibvirtQemu-OP-stop" name="stop" timeout="60s"
> interval="0"/>
>         <op id="FOOBAR-LibvirtQemu-OP-migrate-to" name="migrate_to"
> timeout="60s" interval="0"/>
>         <op id="FOOBAR-LibvirtQemu-OP-migrate-from" name="migrate_from"
> timeout="60s" interval="0"/>
>       </operations>
>     </primitive>
>   </group>
> </resources>
>
> The LibvirtQemu agent is a custom one derived from the VirtualDomain
> agent (for reasons that are off-topic).
>
> The points worth seeing are:
>
> - the "allow-migrate" meta attribute (see
> http://www.linux-ha.org/wiki/VirtualDomain_%28resource_agent%29 "If the
> allow-migrate meta parameter is set to true, then a resource migration
> will not map to a domain shutdown/startup cycle, but to an actual,
> potentially live, resource migration between cluster nodes. ")
>
> - the "migrate-from" and "migrate-to" timeouts (which must be set
> relative to how big - RAM-wise - your VMs are and the bandwidth
> available for migration); passed this timeout, the migration will be
> interrupted and the VM will be shutdown/restarted
>
> Hope it helps,
>
> Cédric
>
>
>
> On 04/02/16 13:44, Kyle O'Donnell wrote:
>> That is helpful but I think I am looking at the wrong documentation:
>>
>> http://www.linux-ha.org/wiki/VirtualDomain_(resource_agent)
>> http://linux-ha.org/doc/man-pages/re-ra-VirtualDomain.html
>>
>> Can you point me to the docs you are referencing?
>>
>> ----- Original Message -----
>> From: "RaSca" <rasca at miamammausalinux.org>
>> To: "users" <users at clusterlabs.org>
>> Sent: Thursday, February 4, 2016 6:48:26 AM
>> Subject: Re: [ClusterLabs] kvm live migration, resource moving
>>
>> If your environment is successfully configured even from the libvirt
>> side, everything should work out of the box, if it does not work you can
>> pass migrate_options to make it work.
>>
>> From the resource agent documentation:
>>
>> migrate_options:  Extra virsh options for the guest live migration. You
>> can also specify here --migrateuri if the calculated migrate URI is
>> unsuitable for your environment. If --migrateuri is set then
>> migration_network_suffix and migrateport are effectively ignored. Use
>> "%n" as the placeholder for the target node name.
>> Please refer to the libvirt documentation for details on guest migration.
>>
>> Hope this helps,
>>
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://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
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://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





More information about the Users mailing list