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(). Have fun, Arnold
signature.asc
Description: PGP signature
_______________________________________________ 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
