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.duf...@idiap.ch> To: "users" <users@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" <ra...@miamammausalinux.org> > To: "users" <users@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@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@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