[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.