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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

>> 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.

>> 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.

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).

>>
>> I very frequently run multiple VMs with the same disk.  I do it 
>> strictly for the purposes of benchmarking.  There are ways to share a 
>> disk without using a clustered filesystem.
>
> I imagine only raw format disks, and only as non-root filesystems (or 
> with -shapshot, which should automatically set exclusive=off)?

Yup.

>>
>> If a higher level management tool wants to enforce a policy (like 
>> libvirt), then let it.  We should not be enforcing policies within 
>> QEMU though.
>
> I agree that qemu is not the place to enforce policies, but covering a 
> hole that users are likely to step into, while allowing its explicit 
> uncovering, is a good thing.  We're not enforcing the policy, only 
> hinting.

Unfortunately, the solution involves breaking backwards compatibility 
for legitimate use-cases (not to mention making those use-cases more 
awkward).  I think the only way to sanely do this is as a global 
configuration parameter.

Regards,

Anthony Liguori