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

[Avi Kivity <avi@qumranet.com>]

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