[Qemu-devel] Re: [et-mgmt-tools] Image Corruption Possible with qemu and qemu-kvm
Sven Oehme
oehmes at de.ibm.com
Wed Aug 29 12:44:16 UTC 2007
qemu-devel-bounces+oehmes=de.ibm.com at 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.
>
i agree default should be advisory locking and a switch to disable it ..
would that be hard to implement ?
thanks. Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/et-mgmt-tools/attachments/20070829/530775f9/attachment.htm>
More information about the et-mgmt-tools
mailing list