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