Re: [PATCH 1/2] conf: add locking option to disk source
On Wed, Feb 14, 2024 at 14:17:57 +0900, Hiroki Narukawa wrote:
There is a case that locking hits a bug and users wants to disable
locking like bug in Linux kernel.
This commit adds option to configure locking for file source.
Signed-off-by: Hiroki Narukawa <hnarukaw(a)yahoo-corp.jp>
---
docs/formatdomain.rst | 5 +++++
src/conf/domain_conf.c | 8 ++++++++
src/conf/schemas/domaincommon.rng | 5 +++++
src/conf/storage_source_conf.h | 3 +++
4 files changed, 21 insertions(+)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 0a4f9d9000..95869d573c 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -2782,6 +2782,11 @@ paravirtualized driver is specified via the ``disk`` element.
via the filesystem. The filename passed via ``file`` can still be used
to generate paths to write into image metadata when doing block operations
but libvirt will not access these natively.
+
+ :since:`Since 10.1.0` a new optional attribute ``locking`` can be added
+ which can take "on" or "off". Basically this option should be
kept
+ default, but it can be used explicitly for workaround about bug in
+ locking.
This is not the first time this is being suggested and I'm still not
persuaded that we want this. We definitelly do not want this as a
generic production attribute.
A possibility would be to do it as part of the qemu XML namespace along
with tainting the VM that such config is being used.
https://libvirt.org/drvqemu.html#pass-through-of-arbitrary-qemu-commands
The main reason is that you never actually want to use this, except for
the very specific case of bugs you are mentioning.
``block``
The ``dev`` attribute specifies the fully-qualified path to the host
device to serve as the disk. :since:`Since 0.0.3`