Re: [Xen-devel] [PATCH] [RFC] Add lock on domain start

[Zhigang Wang <zhigang.x.wang@xxxxxxxxxx>]

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.

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.

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.

I ever considered your approach; You can refer to the  LockFile.py when you
polish your code.

thanks,

zhigang

Zhigang Wang wrote:
> Jim Fehlig wrote:
>> 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.
>>
>> If xend-domains-path is set to shared mount point, a domain will fail to 
>> start on host B if it is already running on host A.  I've added an 
>> option to XendOptions to control the behavior with default of no lock.
>>
>> The patch certainly needs some testing (and probably adjustment) to 
>> ensure the lock is handled properly on save, restore, migrate, domain 
>> crash, etc. but wanted to get folks' thought on this approach before 
>> continuing this endeavor.  Some simple improvements could include adding 
>> info (domain name/id, start time, vmm hostname) to the lock file, 
>> allowing such messages as "domain foo seems to be already running on 
>> host bar" and  a --force option to create/start to override the lock.  A 
>> per-domain config option could also be added to allow more fine-grained 
>> control.
>>
>> Comments, suggestions, alternative approaches, ... are welcome and 
>> appreciated :-).
>>
> 
> this patch xen-running-lock.patch add a external lock facility to get the same
> result. file-lock.c is a simple implement of the external lock utility.
> 
> the external locking facility can leverage the dlm if you are in a cluster
> environment.
> 
> cheers,
> 
> zhigang
> 
>> Regards,
>> Jim
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

#==============================================================================
# This library is free software; you can redistribute it and/or modify it under
# the terms of version 2.1 of the GNU Lesser General Public License as
# published by the Free Software Foundation.
#
# This library is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
# FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License for more
# details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with this library; if not, write to the Free Software Foundation, Inc.,
# 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
#==============================================================================
# Copyright (C) 2008 Oracle, Inc.
# Copyright (C) 2008 Zhigang Wang <zhigang.x.wang@xxxxxxxxxx>
#==============================================================================

import os

# Exceptions that can be raised by this module
class LockError(Exception):
    pass

class LockFile(object):
    '''Represent a lock that is made on the file system, to prevent concurrent
    execution of this code.

    Linux's open(2) manual page says O_EXCL does not work with NFS, but it
    actually does work if both the NFS client (Linux v2.6.6+) and the server
    support it. Apparently it is commonly implemented nowadays, so it should
    be quite safe to use in new systems. Unfortunately there is no easy way to
    check if it is safe or not.
    '''
    def __init__(self, filename):
        self.filename=filename
        self.locked=False

    def acquire(self):
        try:
            os.open(self.filename, os.O_CREAT|os.O_RDWR|os.O_EXCL)
            self.locked=True
        except OSError, e:
            raise LockError('Could not create lock file: %s' % e)

    def release(self):
        if self.locked:
            try:
                os.unlink(self.filename)
                self.locked=False 
            except OSError, e:
                raise LockError('Could not remove lock file: %s' % e)

    def __del__(self):
        self.release()

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel