qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks.


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks.
Date: Mon, 7 Dec 2009 09:38:42 +0000
User-agent: Mutt/1.4.1i

On Fri, Dec 04, 2009 at 11:15:12AM -0600, Anthony Liguori wrote:
> Richard W.M. Jones wrote:
> >[from the commit message ...]
> >
> >Allow qemu to acquire shared and exclusive locks on disk images.
> >This is done by extending the -drive option with an additional,
> >optional parameter:
> >
> >  -drive [...],lock=none
> >  -drive [...],lock=shared
> >  -drive [...],lock=exclusive
> >
> >lock=none is the default, and it means that we don't try to acquire
> >any sort of lock.
> >
> >lock=shared tries to acquire a shared lock on the disk image.
> >Multiple instances of qemu may all hold this sort of lock.
> >
> >lock=exclusive tries to acquire an exclusive lock on the disk
> >image.  An exclusive lock excludes all other shared and exclusive
> >locks.
> >
> >If acquisition of a lock fails, opening the image fails.
> >
> >The implementation of locks only works for raw POSIX and Win32
> >files.  However many of the other block types are implemented
> >in terms of these drivers, so they "inherit" locking too.  Other
> >drivers are read-only, so don't require locking.  Below we note
> >only the cases where locking is *not* implemented:
> >
> >  cloop - directly open()s the file, no locking implemented
> >  cow - same as cloop
> >  curl - protocol probably doesn't support locking
> >  nbd - same as curl
> >  
> 
> The problem with something like this is that it gives a false sense of 
> security.
> 
> You can still run into problems if you have an application accessing the 
> image that doesn't attempt to acquire the lock.

The same is true of any UNIX application that uses POSIX locking, but
that doesn't mean they should not bother to use locking. POSIX advisory
locking relies on applications to play nicely together. If management
applications using QEMU take advantage of this functionality then it will
provide a useful level of protection within a host, and (depending on the
type of disk storage) may also provide protection between hosts.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]