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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home