<tt>qemu-devel-bounces+oehmes=de.ibm.com@nongnu.org wrote on 08/28/2007 04:13:02 AM: > Anthony Liguori wrote: > >> In the scenario you mention, libvirt should probably do a sanity check for > >> this before letting you start the guest. libvirt already supports the idea > >> of 'shared' disk images where two or more guests can be > optionally configured > >> to have write access - basically assumes the admin requesting sharing knows > >> what they're doing. > >> > > > > I think this is the right level myself. Advisory locks work okay but > > not all filesystems support them. It's particularly nasty when you have > > a clustered filesystem in the host. I think it would do more harm than > > good to have a feature like that was supposed to provide a safe-guard > > but then frequently didn't work. > > > > There's still the unmanaged use case to worry about. I think qemu can > default to advisory locking, and management tools can do their own > locking and always override qemu. > > It's too easy to kill an image by starting up another instance right now. > </tt> <tt>i agree default should be advisory locking and a switch to disable it ..</tt> <tt>would that be hard to implement ?</tt> <tt>thanks. Sven</tt>