> > hi, > what is the "relaxed" equivalent of the `-hda file.qcow2` command line > argument to control file locking (`locking=off`) ? the documentation > says that `-hda a` can be replaced by `-drive file=a` and that locking > can be controlled with the `locking` option of the `blockdev` argument > : how to link `drive` and `blockdev` to obtain "relaxed" `-hda > file.qcow2` ? regards, lacsaP.
Let me give you an example of how disk controller device and disk drive devices are nested, i.e. the expanded form of the "-hda" arg. I start qemu by a script, and I use shell variables to put the long command line together. The following is a relevant excerpt of the script. See how the "-device" (controller) record maps to the "-drive" records via the id= and drive= attributes: DISK1="-drive if=none,id=ff,cache.direct=on,aio=native,discard=unmap,detect-zeroes=u nmap,file=/somepath/system.qcow2" DISK2="-drive if=none,id=fe,cache.direct=on,aio=native,discard=unmap,detect-zeroes=u nmap,file=/somepath/data.qcow2" DISK3="-drive if=none,id=fd,cache.direct=on,aio=native,discard=unmap,detect-zeroes=u nmap,file=/somepath/swap.qcow2" HDD_STUFF="$DISK1 $DISK2 $DISK3 -device virtio-scsi-pci -device scsi-hd,drive=ff -device scsi-hd,drive=fe -device scsi-hd,drive=fd" In my script, those are four long lines. Here they have wrapped... sorry :-) I run this on top of a filesystem that supports sparse files and snapshots, and can be told to avoid FS-level COW if it can (= to make it prefer in-place overwrites over COW). Now... I've found a more advanced description of image file locking in the official current documentation here: https://www.qemu.org/docs/master/system/qemu-block-drivers.html#disk-i mage-file-locking ...now try to combine this with my example above :-) Not sure what you mean by "relaxed". Do you need to map the same image file to multiple guests? For what purpose? HA failover? Both/all guests should have simultaneous write access? Similar to multipath SCSI ? Are you playing with the GFS2/OCFS2 or something? Or do you mean to use the same image by multiple guests as a shared read-only disk? I recall reading an article ages ago, on how to create "ephemeral fake writeable block devices" for individual guests, on top of a shared read-only "master image"... (as multiple COW snapshots) Frank