[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 Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |