On Sat, Jan 23, 2021 at 11:12:15AM +0100, Peter Krempa wrote:
On Fri, Jan 22, 2021 at 21:32:05 -0500, Masayoshi Mizuma wrote:
From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Introduce locking option for disk source of qemu. It may be useful to avoid file lock issues.
Lock issues usually mean that you are doing something wrong.
locking option supports three switches; 'auto', 'on' and 'off'. The default behaivor will work if locking option isn't set.
Example of the usage:
<disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/tmp/QEMUGuest1.img' locking='off'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk>
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> --- docs/schemas/domaincommon.rng | 9 +++++++++ src/conf/domain_conf.c | 8 ++++++++ src/conf/storage_source_conf.c | 9 +++++++++ src/conf/storage_source_conf.h | 14 ++++++++++++++ src/libvirt_private.syms | 1 + src/qemu/qemu_block.c | 5 +++++ 6 files changed, 46 insertions(+)
Few quick notes:
- I'm not entirely persuaded that we should at this at all - qemu locking works to prevent user mistakes - you really need to know what to expect if you use images which are used by multiple VMs
- you really need to add some form of justification, the current one definitely is insufficient and thus I'm inclined to NACKing the concept of enabling setting of the locks completely
I agree - we should be providing higher level conceptual logic that indirectly maps into the different locking states. For example we have <readonly/> and <shareable/> elements that influence the type of locks held. A flag to unconditionally disable locking entirely feels like it is just hacking around some undefined problem that should be fixed in a better way. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|