From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jrx5I-0007RL-8j for qemu-devel@nongnu.org; Fri, 02 May 2008 11:22:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jrx5H-0007Qz-Iq for qemu-devel@nongnu.org; Fri, 02 May 2008 11:22:03 -0400 Received: from [199.232.76.173] (port=52436 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jrx5H-0007Qk-CU for qemu-devel@nongnu.org; Fri, 02 May 2008 11:22:03 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jrx5H-0008Nm-Hr for qemu-devel@nongnu.org; Fri, 02 May 2008 11:22:03 -0400 Received: by py-out-1112.google.com with SMTP id u52so2366793pyb.10 for ; Fri, 02 May 2008 08:22:02 -0700 (PDT) Message-ID: <481B3191.9020502@codemonkey.ws> Date: Fri, 02 May 2008 10:21:53 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <200804282258.08426.nadim@khemir.net> <481AF262.4080305@qumranet.com> <481B2603.3050800@codemonkey.ws> <481B2C7C.8050108@qumranet.com> In-Reply-To: <481B2C7C.8050108@qumranet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [kvm-devel] Feedback and errors Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: nadim khemir , kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org 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