All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: Jim Fehlig <jfehlig@novell.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] [RFC] Add lock on domain start
Date: Mon, 11 Aug 2008 10:22:47 +0800	[thread overview]
Message-ID: <489FA277.2010300@oracle.com> (raw)
In-Reply-To: <489C7D46.5030805@novell.com>

Hi Jim,

some comments inline.

Jim Fehlig wrote:
> 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
yes we can leverage it. it is easy for xend managed domains. but shall we
consider none-xend-managed domains?
> * 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
when we implement --lock-override, this is easy.
> * Lock should contain some useful info
>    - Put domain name/id/uuid, host, start time in lock file
this is useful.
> * Lock mechanism should be configurable
>    - Provide xend config option to specify lock facility
do you want to implement a hook for external locking facilities to use?
> * Lock must accommodate domain lifecycle operations (save, restore,
>    migrate, reboot, etc.)
we should find the right place to acquire/release the lock, see my patch for
reference.
> * 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 :-).
> 
we should consider XenAPI support too. I think we can first implement in the
API level, then other features (--lock-override, etc) can be implemented later.
maybe there are better solutions when we considering XenAPI.

the patch I give before is in use in our Oracle VM 2.1.2, the external lock is
using dlm, which is part of ocfs2 (we use ocfs2 as the cluster fs in Oracle VM).

If a patch can fulfill all the requirements you mentioned, it will definitely
satisfy our use.

please go ahead and wrap up a new patch, then we can try to make it accepted by
the community.

thanks,

zhigang

> Regards,
> Jim
> 

  reply	other threads:[~2008-08-11  2:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-06  6:06 [PATCH] [RFC] Add lock on domain start Jim Fehlig
2008-08-07  2:23 ` Zhigang Wang
2008-08-07  4:26   ` Zhigang Wang
2008-08-08 17:07     ` Jim Fehlig
2008-08-11  2:22       ` Zhigang Wang [this message]
2008-08-11 11:14 ` Ian Jackson
2008-08-11 16:45   ` Jim Fehlig
2009-08-05  7:41     ` Pasi Kärkkäinen
2009-08-05  8:39       ` Zhigang Wang
2009-08-05  9:33         ` Pasi Kärkkäinen
2009-08-05 16:30           ` Jia Ju Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=489FA277.2010300@oracle.com \
    --to=zhigang.x.wang@oracle.com \
    --cc=jfehlig@novell.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.