[Pacemaker] migration only between nodes with identical hardware

[Arnold Krille]

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().

Have fun,

Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20121002/5b31bbf5/attachment-0003.sig>