Re: [Qemu-devel] Re: Image Corruption Possible with qemu and qemu-kvm

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

 




qemu-devel-bounces+oehmes=de.ibm.com@xxxxxxxxxx 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.
>

i agree default should be advisory locking and a switch to disable it ..
would that be hard to implement ?

thanks. Sven
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux