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] [PATCH] [RFC] Add lock on domain start

To: Jim Fehlig <jfehlig@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [RFC] Add lock on domain start
From: Pasi Kärkkäinen <pasik@xxxxxx>
Date: Wed, 5 Aug 2009 10:41:28 +0300
Cc: Zhigang Wang <zhigang.x.wang@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Delivery-date: Wed, 05 Aug 2009 00:41:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48A06CA3.2080801@xxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <48993F48.9030705@xxxxxxxxxx> <18592.7953.353263.676403@xxxxxxxxxxxxxxxxxxxxxxxx> <48A06CA3.2080801@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.13 (2006-08-11)
On Mon, Aug 11, 2008 at 10:45:23AM -0600, Jim Fehlig wrote:
> Ian Jackson wrote:
> > Jim Fehlig writes ("[Xen-devel] [PATCH] [RFC] Add lock on domain start"):
> >   
> >> This patch adds a simple lock mechanism when starting domains by placing 
> >> a lock file in xend-domains-path/<dom_uuid>.  The lock file is removed 
> >> when domain is stopped.  The motivation for such a mechanism is to 
> >> prevent starting the same domain from multiple hosts.
> >>     
> >
> > I think this should be dealt with in your next-layer-up management
> > tools.
> >   
> 
> Perhaps.  I wanted to see if there was any interest in having such a
> feature at the xend layer.  If not, I will no longer pursue this option.
> 

Replying a bit late to this.. I think there is demand for this feature! 

Many people (mostly in a smaller environments) don't want to use
'next-layer-up' management tools..

> > Lockfiles are bad because they can become stale.
> >   
> 
> Yep.  Originally I considered a 'lockless-lock' approach where a bit it
> set and counter is spun on a 'reserved' sector of vbd, e.g. first
> sector.  Attempting to attach the vbd to another domain would fail if
> lock bit is set and counter is incrementing.  If counter is not
> incrementing assume lock is stale and proceed.  This approach is
> certainly more complex.  We support various image formats (raw, qcow,
> vmdk, ...) and such an approach may mean changing the format (e.g.
> qcow3).  Wouldn't work for existing images.  Who is responsible for
> spinning the counter?  Anyhow seemed like a lot of complexity as
> compared to the suggested simple approach with override for stale lock.
> 

I assume you guys have this patch included in OpenSuse/SLES Xen rpms.

Is the latest version available from somewhere? 

-- Pasi

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

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