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" <[email protected]> > To: "users" <[email protected]> > 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" <[email protected]> >> To: "users" <[email protected]> >> 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: [email protected] > 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: [email protected] > 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: [email protected] 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
