[Pacemaker] migration only between nodes with identical hardware

[Dejan Muhamedagic]

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.harper at bendigoit.com.au> wrote:
> 
> > > 
> > > On Mon, Oct 1, 2012 at 5:49 PM, James Harper
> > > <james.harper at 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 at 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