> 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
