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: Zhigang Wang <zhigang.x.wang@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [RFC] Add lock on domain start
From: Jim Fehlig <jfehlig@xxxxxxxxxx>
Date: Fri, 08 Aug 2008 11:07:18 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 08 Aug 2008 10:07:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <489A7992.5090205@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> <489A5CBF.1040405@xxxxxxxxxx> <489A7992.5090205@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20080707)
Hi Zhigang,

Sorry for the delay.

Zhigang Wang wrote:
When we implement such a lock, we should pay more attention to the live
migration scenario: it should allow two vms started at the same time.

Yes, certainly. Any such mechanism must accommodate live migration. To be precise, it must not break any existing functionality - save, restore, live/non-live migration, reboot, domain crash, ...

my patch still doesn't resolve it: it has a small time gap that allow other vms
to start. (when migrating VM1 on Sever1 to Server2 as VM2, VM1 release the lock
--> some prepare work for migration + network delay --> VM2 acquire the lock.)

maybe your suggestion of add a --force option can be used to solve this issue.

Hmm, perhaps but I was reserving that for cases where lock was not released do to 'unusual' circumstances. E.g. HVM domain crashed and tools were not aware of it and thus domain not cleaned up. But doing a destroy on the domain would invoke code path to release lock. Anyhow, --force would give a knowledgeable admin a way to override the lock.

My approach is most flexible (maybe specially useful in certain circumstance)
as your approach can be easily integrated to the current xend implement.

let's first decide which approach is best in the long run together.

AFAICT, we're essentially doing the same thing - writing out a lock (in the form of a file) on domain start and removing the lock on domain shutdown. Difference is in implementation. Perhaps first we should agree on some requirements.

* Location of lock must be accessible to multiple hosts
  - Provide xend config option to specify the location.  xend-domains-path
    already exists and could be used for this purpose
* Lock feature should be globally optional, disabled by default
  - Provide xend config option to globally turn on/off domain lock
* Lock feature should be per-domain optional, disabled by default
  - Provide domU config option to turn on/off lock
* Lock should contain some useful info
  - Put domain name/id/uuid, host, start time in lock file
* Lock mechanism should be configurable
  - Provide xend config option to specify lock facility
* Lock must accommodate domain lifecycle operations (save, restore,
  migrate, reboot, etc.)
* Lock should be 'overridable', e.g. with a --lock-override option to start/create
* Lock mechanism must be acceptable to community :-)

How does this sound? Am I missing anything? If you agree I can spin a patch that satisfies these requirements. With any luck it will satisfy the last one :-).


Xen-devel mailing list