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


Re: [Xen-devel] [PATCH] [RFC] Add lock on domain start

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [RFC] Add lock on domain start
From: Jim Fehlig <jfehlig@xxxxxxxxxx>
Date: Mon, 11 Aug 2008 10:45:23 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Zhigang Wang <zhigang.x.wang@xxxxxxxxxx>
Delivery-date: Mon, 11 Aug 2008 09:45:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <18592.7953.353263.676403@xxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060911)
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.

> 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.


Xen-devel mailing list