Re: "relaxed" `-hda file.qcow2` equivalent ?

[Frantisek Rysanek]

> And, I have an idea: rather than refer to driver=qcow2 and 
> file.filename, how about referring to the loopback device (NBD) that
> you already have, courtesy of qemu-nbd ? Would that perhaps circumvent
> the file lock? ;-)
> 
> -blockdev node-name=xy,driver=raw,file.driver=host_device,\
> file.filename=/dev/loop0,file.locking=off
> 
> -device virtio-scsi-pci -device scsi-hd,drive=xy 
>

I mean: the QEMU device emulation would not run on top of the QCOW 
file directly (and the underlying filesystem, and its locking 
feature), but would instead share a block device with your host-side 
mount. Thus, it would also plug directly into any block-level 
buffering going on, on the host side.

On the guest, I'm wondering if you should mount the partition with 
-o direct. This should prevent any write-back buffering in the guest, 
which however you will not be doing, as you say.
On the other hand, if you make changes to the FS on the host side, 
while the QEMU guest instance is already running, the guest probably 
will not get to know about any changes, probably unless you umount 
and remount, that with "-o direct" (to avoid local read caching in 
the guest).

Even if this crazy stuff works in the end, I'm wondering if it's all 
worth the implied pitfalls :-)
Apparently you still need to keep stuff in sync in some way...

Frank