[Qemu-devel] Re: [kvm-devel] Feedback and errors

[Avi Kivity]

Anthony Liguori wrote:
> Avi Kivity wrote:
>   
> > Well, one user (me) has made this mistake, several times.
> >     
>
> I guess it's usage patterns.  I'm pretty religious about using -snapshot 
> unless I have a very specific reason not to.  I have never encountered 
> this problem myself.
>
>   

Most users cannot use -snapshot for their workloads.

> > > FWIW, the whole override thing for Xen has been an endless source of 
> > > pain.  It's very difficult (if not impossible) to accurately 
> > > determine if someone else is using the disk.  
> > >       
> > What's wrong with the standard file locking API?  Of course it won't 
> > stop non-qemu apps from accessing it, but that's unlikely anyway.
> >     
>
> Xen tries to be very smart about determining whether devices are mounted 
> somewhere else or not.
>
>   

I'm not talking about being too smart.  Just an flock().

> > > Also, it tends to confuse people trying to do something legitimate 
> > > more often than helping someone doing something stupid.
> > >       
> > -drive exclusive=off (or share=yes)
> >     
>
> The problem I have is that the default policy gets very complicated.  At 
> first thought, I would say it's fine as long as exclusive=off was the 
> default for using -snapshot or using raw images.  However, if you create 
> a VM with a qcow image using -snapshot, and then create another one 
> without using snapshot, you're boned.
>   

Well then, default to exclusive=on.  If you're using -shapshot you can 
add the extra parameter as well.

> What we really need is a global configuration file so that individual 
> users can select these defaults according to what makes sense for them.
>
> In the mean time, I think the policy vs. mechanism strongly suggests 
> that exclusive=off should be the default (not to mention maintaining 
> backwards compatibility).
>
>   

The problem is that this is bad for users.


--
error compiling committee.c: too many arguments to function