From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NrB9W-0001Bm-Pp for qemu-devel@nongnu.org; Mon, 15 Mar 2010 10:20:18 -0400 Received: from [199.232.76.173] (port=36953 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NrB9V-0001B7-Mi for qemu-devel@nongnu.org; Mon, 15 Mar 2010 10:20:17 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NrB9U-0000Ld-4F for qemu-devel@nongnu.org; Mon, 15 Mar 2010 10:20:17 -0400 Received: from isrv.corpit.ru ([81.13.33.159]:60008) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NrB9T-0000Kp-OA for qemu-devel@nongnu.org; Mon, 15 Mar 2010 10:20:16 -0400 Message-ID: <4B9E421A.8010804@msgid.tls.msk.ru> Date: Mon, 15 Mar 2010 17:20:10 +0300 From: Michael Tokarev MIME-Version: 1.0 Subject: Re: [Qemu-devel] -fda fat:dir -snapshot References: <4B9BE4F1.6030202@msgid.tls.msk.ru> <4B9E0AAA.3090307@redhat.com> In-Reply-To: <4B9E0AAA.3090307@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel Kevin Wolf wrote: > Am 13.03.2010 20:18, schrieb Michael Tokarev: >> Apparently this does not work, and for a loooong time: >> >> $ kvm -fda fat:dir >> [ it opens the sdl window ] >> $ kvm -fda fat:dir -snapshot >> qemu: could not open disk image fat:dir: No such file or directory >> >> Is it supposed to work? > > Wow, that's a crazy case. I guess nobody has ever tested this, and > indeed it looks like it never has worked. As you might know, -snapshot > internally creates a temporary qcow2 image which takes the image you > originally asked for as a backing file. Yeah, I looked at strace output at least. [] > We could just disable this for protocols as a quick fix, but I think in > fact you do want to have this behaviour when using protocols as a > backing file for a persistent COW image. I guess this needs some more > thought, especially in respect to the discussions of making > file/host_device/... protocols. > > If you really have a use case for this, you can use an absolute path > after fat: as a workaround, it won't touch the path then. Initially it was a bugreport against kvm in Debian - see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504049 "Virtual FAT drive doesn't work with -snapshot", I'm not really sure what use case there is. But for me, I already had a more-or-less valid use case - trying a new driver in windows, supplying it in a virtual floppy (hence fat:dir) and checking if it works (hence -snapshot). I actually tried to do something in the past, but didn't know the fat: thing (apparently it is not mentioned in the manpage). But the whole thing indeed looks somewhat.. messy. ;) Thanks! /mjt