forked from rpms/libvirt
74 lines
3.1 KiB
Diff
74 lines
3.1 KiB
Diff
|
From 9842eb7301f985e4cc08001aff48c269492b2456 Mon Sep 17 00:00:00 2001
|
||
|
|
Message-Id: <9842eb7301f985e4cc08001aff48c269492b2456@dist-git>
|
||
|
|
From: Michal Privoznik <mprivozn@redhat.com>
|
||
|
|
Date: Tue, 6 Sep 2022 13:45:51 +0200
|
||
|
|
Subject: [PATCH] qemu_process.c: Propagate hugetlbfs mounts on reconnect
|
||
|
|
|
||
|
|
When reconnecting to a running QEMU process, we construct the
|
||
|
|
per-domain path in all hugetlbfs mounts. This is a relict from
|
||
|
|
the past (v3.4.0-100-g5b24d25062) where we switched to a
|
||
|
|
per-domain path and we want to create those paths when libvirtd
|
||
|
|
restarts on upgrade.
|
||
|
|
|
||
|
|
And with namespaces enabled there is one corner case where the
|
||
|
|
path is not created. In fact an error is reported and the
|
||
|
|
reconnect fails. Ideally, all mount events are propagated into
|
||
|
|
the QEMU's namespace. And they probably are, except when the
|
||
|
|
target path does not exist inside the namespace. Now, it's pretty
|
||
|
|
common for users to mount hugetlbfs under /dev (e.g.
|
||
|
|
/dev/hugepages), but if domain is started without hugepages (or
|
||
|
|
more specifically - private hugetlbfs path wasn't created on
|
||
|
|
domain startup), then the reconnect code tries to create it.
|
||
|
|
But it fails to do so, well, it fails to set seclabels on the
|
||
|
|
path because, because the path does not exist in the private
|
||
|
|
namespace. And it doesn't exist because we specifically create
|
||
|
|
only a subset of all possible /dev nodes. Therefore, the mount
|
||
|
|
event, whilst propagated, is not successful and hence the
|
||
|
|
filesystem is not mounted. We have to do it ourselves.
|
||
|
|
|
||
|
|
If hugetlbfs is mount anywhere else there's no problem and this
|
||
|
|
is effectively a dead code.
|
||
|
|
|
||
|
|
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2123196
|
||
|
|
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
|
||
|
|
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
|
||
|
|
(cherry picked from commit 0377177c7856bb87a9d8aa1324b54f5fbe9f1e5b)
|
||
|
|
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2152083
|
||
|
|
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
|
||
|
|
---
|
||
|
|
docs/kbase/qemu-passthrough-security.rst | 6 ------
|
||
|
|
src/qemu/qemu_process.c | 3 +++
|
||
|
|
2 files changed, 3 insertions(+), 6 deletions(-)
|
||
|
|
|
||
|
|
diff --git a/docs/kbase/qemu-passthrough-security.rst b/docs/kbase/qemu-passthrough-security.rst
|
||
|
|
index 106c3cc5b9..ef10d8af9b 100644
|
||
|
|
--- a/docs/kbase/qemu-passthrough-security.rst
|
||
|
|
+++ b/docs/kbase/qemu-passthrough-security.rst
|
||
|
|
@@ -172,9 +172,3 @@ command before any guest is started:
|
||
|
|
::
|
||
|
|
|
||
|
|
# mount --make-rshared /
|
||
|
|
-
|
||
|
|
-Another requirement for dynamic mount point propagation is to not place
|
||
|
|
-``hugetlbfs`` mount points under ``/dev`` because these won't be propagated as
|
||
|
|
-corresponding directories do not exist in the private namespace. Or just use
|
||
|
|
-``memfd`` memory backend instead which does not require ``hugetlbfs`` mount
|
||
|
|
-points.
|
||
|
|
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
|
||
|
|
index 4b52d664c7..062a0b6dac 100644
|
||
|
|
--- a/src/qemu/qemu_process.c
|
||
|
|
+++ b/src/qemu/qemu_process.c
|
||
|
|
@@ -4039,6 +4039,9 @@ qemuProcessBuildDestroyMemoryPathsImpl(virQEMUDriver *driver,
|
||
|
|
return -1;
|
||
|
|
}
|
||
|
|
|
||
|
|
+ if (qemuDomainNamespaceSetupPath(vm, path, NULL) < 0)
|
||
|
|
+ return -1;
|
||
|
|
+
|
||
|
|
if (qemuSecurityDomainSetPathLabel(driver, vm, path, true) < 0)
|
||
|
|
return -1;
|
||
|
|
} else {
|
||
|
|
--
|
||
|
|
2.39.0
|
||
|
|
|