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 ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
