From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JscFp-0004P2-Cw for qemu-devel@nongnu.org; Sun, 04 May 2008 07:19:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JscFn-0004Oq-Lr for qemu-devel@nongnu.org; Sun, 04 May 2008 07:19:40 -0400 Received: from [199.232.76.173] (port=36947 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JscFn-0004On-Aw for qemu-devel@nongnu.org; Sun, 04 May 2008 07:19:39 -0400 Received: from bzq-179-150-194.static.bezeqint.net ([212.179.150.194] helo=il.qumranet.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JscFm-0005iw-Aw for qemu-devel@nongnu.org; Sun, 04 May 2008 07:19:39 -0400 Message-ID: <481D9BC2.8030704@qumranet.com> Date: Sun, 04 May 2008 14:19:30 +0300 From: Avi Kivity MIME-Version: 1.0 References: <200804282258.08426.nadim@khemir.net> <481AF262.4080305@qumranet.com> <481B2603.3050800@codemonkey.ws> <481B2C7C.8050108@qumranet.com> <481B3191.9020502@codemonkey.ws> In-Reply-To: <481B3191.9020502@codemonkey.ws> 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: Anthony Liguori Cc: nadim khemir , kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org 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