WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [RFC] Making Xen cluster aware - locking domains on shar

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [RFC] Making Xen cluster aware - locking domains on shared storage
From: Maximilian Wilhelm <max@xxxxxxxxxxx>
Date: Sat, 3 May 2008 16:55:44 +0200
Delivery-date: Sat, 03 May 2008 07:56:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080427010203.GB17509@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: xen-devel@xxxxxxxxxxxxxxxxxxx
References: <20080427010203.GB17509@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)
Nobody interested in this?

> These days I had the idea, that it should not be that hard to pimp
> 'xm' to check if a domain already is running somewhere in the cluster
> if there is a shared storage available.
> 
> The basic idea is the following:
> 
>   Consider a cluster of n (>= 2) Xen nodes which share some storage
>   (e.g. a SAN or NAS or whatever) where the storage for the DomUs is
>   located and where some piece of shared (cluster) filesystem is located, too.
> 
>   Let's asume further the shared file system is mountet to /xen_cluster
>   on all nodes.
> 
>   Now it would come in handy if xm (or maybe some other part of the
>   Xen univserse) could create some kind of lockfile on this FS to indicate
>   that a given domain is already running somewhere in this cluster
>   (maybe the Dom0 could be written into this file).
> 
>   This way it would be quite easy to prevent trouble from people
>   running Xen in this kind of environment, as on domain could only be
>   started once on the cluster.
> 
> 
> So I've made up there patches
>  * [0] Example options for /etc/xen/xend-config.sxp
>  * [1] for options parsing for /etc/xen/xend-config.sxp
>  * [2] Basic implementation of lockfile checking/creation during 'xm create'
>        phase. The interesting part (shutdown, destroy, reboot(?),
>        migrate, ...) is missig.
> 
> So what do you think about all this?
> 
> I guess there is no big resistance against the idea as such.
> What about the implementation approach?
> Is this somethings you could imagine as a direction to go to?
> Or maybe handle all of this internally to drop the dependancy of the
> shared file system?
> 
> [0] http://files.rfc2324.org/patches/xen/xend-config.sxp.diff
> [1] http://files.rfc2324.org/patches/xen/XendOptions.py.diff
> [2] http://files.rfc2324.org/patches/xen/create.py.diff

Ciao
Max
-- 
        Follow the white penguin.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>