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/
Home Products Support Community News


[Xen-devel] [RFC] Making Xen cluster aware - locking domains on shared s

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [RFC] Making Xen cluster aware - locking domains on shared storage
From: Maximilian Wilhelm <max@xxxxxxxxxxx>
Date: Sun, 27 Apr 2008 03:02:03 +0200
Delivery-date: Sat, 26 Apr 2008 18:02:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)

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

        Follow the white penguin.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [RFC] Making Xen cluster aware - locking domains on shared storage, Maximilian Wilhelm <=