> > 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? James _______________________________________________ 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
