From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [PATCH] [RFC] Add lock on domain start Date: Mon, 11 Aug 2008 10:45:23 -0600 Message-ID: <48A06CA3.2080801@novell.com> References: <48993F48.9030705@novell.com> <18592.7953.353263.676403@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <18592.7953.353263.676403@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: xen-devel@lists.xensource.com, Zhigang Wang List-Id: xen-devel@lists.xenproject.org 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/. 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. Thanks, Jim