On Tue, Oct 02, 2012 at 09:25:43PM +0200, Arnold Krille wrote: > On Tue, 2 Oct 2012 10:02:05 +0000 > James Harper <james.har...@bendigoit.com.au> wrote: > > > > > > > On Mon, Oct 1, 2012 at 5:49 PM, James Harper > > > <james.har...@bendigoit.com.au> wrote: > > > >> > > > >> On 2012-09-28 16:24, James Harper wrote: > > > >> > I have two nodes running identical hardware which run Xen > > > >> > VM's, and want > > > >> to add a third node to the cluster which can access the same > > > >> clvm and iscsi resources, but it will not be identical hardware. > > > >> The non-identical hardware means that to move a VM to this third > > > >> node it it must be stopped then started, a migration will not > > > >> work. > > > >> > > > > >> > This situation may not really come up as in most cases I'll use > > > >> > location > > > >> resources to restrict VM's to only the first two nodes (third > > > >> node will mostly be for a different purpose), but just in case I > > > >> want to do that for one or two VMs, is it possible to come up > > > >> with some sort of > > > rule like: > > > >> > > > > >> > A->B = migration allowed > > > >> > B->A = migration allowed > > > >> > A->C = no migration allowed > > > >> > B->C = no migration allowed > > > >> > > > >> create an asymmetrical cluster. > > > > > > > > My cluster is already asymmetric > > > > > > > >> add a node property, e.g. > > > >> > > > >> > node xxx attributes service="web" > > > >> > > > >> create corresponding location rules, e.g. > > > >> > > > >> > location loc-web-fs-www web-fs-www \ > > > >> > rule $id="loc-web-webfs-www-rule" 100: service eq web > > > >> > > > > > > > > A location rule like that will stop the service running on that > > > > node > > > altogether won't it? That's not what I want. The services can run > > > on nodes with non-identical hardware, they just can't live-migrate > > > there, they have to be stopped on the old node then started on the > > > new node. > > > > > > I don't think we have any way to express that. Sorry. > > > > > > > I kind of guessed that, but thanks for the confirmation. > > > > Do you think I could build this into the RA? If each node defined an > > architecture type (doesn't matter what, as long as it is different > > for different architectures), could the RA read that attribute from > > both the source and destination nodes and act accordingly? > > Just a thought: You could derive your own RA from the VirtualDomain-RA > and implement your own migration logic: If target- and source-platforms > match, do the live migration, if they don't match make migrate_to() call > stop() and migrate_from() call start().
We're still accepting patches :) > Have fun, > > Arnold > _______________________________________________ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
