[Linux-cluster] virtual machine failover with gfs

[matt whiteley]

On Jun 25, 2008, at 4:41 PM, Joe Royall wrote:
> Why not use lvm backed vms, 1 per vm, share the entire partition  
> with all the lvms via ISCSI to each dom0 and run clvm on the dom0s.   
> The lvms do not need to be mounted in dom0.  You can then use RHCS  
> to failover vms between dom0s.  Consider putting all the vms on a  
> single node into a single resource group and only allow 1 group to  
> operate on a single node.  You can then configure N+1 redundancy.
> -- 
> Joe Royall
> Red Hat Certified Architect


We already have all of the nodes attached to a san vi fibre channel,  
so I would rather not just provide storage from the san through  
another box as an iscsi target to these 4. It seems like it would add  
a layer of complexity and performance bottlenecking.

It seems like I could do the first half of what you talk about,  
instead of making a gfs filesystem in the clvm lv and using files  
there for the vm backends, I could make multiple lvs in the clvm vg  
and use one for each vm. This gets around using gfs at all, and I  
could just have a resource per vm for it's lv. I am not sure how I  
would specify this in cluster.conf so that the lv would get mounted on  
the proper node that was going to run a vm. From what I have read, a  
<vm> element can't be a child of a <service> element and there doesn't  
seem to be any other way to define a relationship between the two.

Are all resources in a cluster only ever on one node at a time, or is  
there a way to specify that a resource should be on more than one or  
all nodes as they join a cluster?

I looked that the nfscookbook available from Red Hat and it seemed to  
describe a similar problem, I could create 4 services for the same gfs  
filesystem and have each in a failover domain for each node. At this  
point this seems like not even a good problem to use gfs for, I got  
the idea from that Red Hat Magazine article that seemed to be  
describing the very problem I am trying to solve.

-- 
matt whiteley <whiteley at pdx.edu>