[Top][All Lists]

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

Re: [Qemu-devel] Re: [et-mgmt-tools] Image Corruption Possible with qemu

From: Daniel Veillard
Subject: Re: [Qemu-devel] Re: [et-mgmt-tools] Image Corruption Possible with qemu and qemu-kvm
Date: Mon, 27 Aug 2007 17:26:25 -0400
User-agent: Mutt/1.4.1i

On Mon, Aug 27, 2007 at 04:02:38PM -0500, Anthony Liguori wrote:
> On Mon, 2007-08-27 at 21:27 +0100, Daniel P. Berrange wrote:
> > On Mon, Aug 27, 2007 at 10:19:42PM +0200, Sven Oehme wrote:
> > > i know that in xen they deal with this problem somehow xen specific.
> > > wouldn't it be good to prevent multiple access to the same image by 
> > > default and add a switch to overwrite it ? 
> > 
> > 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.

  Well initially I was really of the position that checking had to be
done at the hypervisor level, but as this thread pointed out we can't
always do this (there is also the potential of conflict between different
hypervisor though that sounds more theorical than practical).


Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
address@hidden  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

reply via email to

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