[Qemu-devel] -fda fat:dir -snapshot

[Qemu-devel] -fda fat:dir -snapshot

[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?

Thanks!

/mjt

Re: [Qemu-devel] -fda fat:dir -snapshot

[Kevin Wolf]

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.

So we have a qcow2 file with a backing file tmp:dir. Now, backing file
paths are always resolved relative to the COW file, so we get
/tmp/fat:dir. Oops.

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.

Kevin

Re: [Qemu-devel] -fda fat:dir -snapshot

[Michael Tokarev]

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