|
 |
3a9410 |
From 2aeb222d9d61868ef40932b4349af84696415e11 Mon Sep 17 00:00:00 2001
|
|
|
3a9410 |
Message-Id: <2aeb222d9d61868ef40932b4349af84696415e11@dist-git>
|
|
|
639072 |
From: Michal Privoznik <mprivozn@redhat.com>
|
|
|
639072 |
Date: Tue, 6 Sep 2022 13:45:51 +0200
|
|
|
639072 |
Subject: [PATCH] qemu_process.c: Propagate hugetlbfs mounts on reconnect
|
|
|
639072 |
|
|
|
639072 |
When reconnecting to a running QEMU process, we construct the
|
|
|
639072 |
per-domain path in all hugetlbfs mounts. This is a relict from
|
|
|
639072 |
the past (v3.4.0-100-g5b24d25062) where we switched to a
|
|
|
639072 |
per-domain path and we want to create those paths when libvirtd
|
|
|
639072 |
restarts on upgrade.
|
|
|
639072 |
|
|
|
639072 |
And with namespaces enabled there is one corner case where the
|
|
|
639072 |
path is not created. In fact an error is reported and the
|
|
|
639072 |
reconnect fails. Ideally, all mount events are propagated into
|
|
|
639072 |
the QEMU's namespace. And they probably are, except when the
|
|
|
639072 |
target path does not exist inside the namespace. Now, it's pretty
|
|
|
639072 |
common for users to mount hugetlbfs under /dev (e.g.
|
|
|
639072 |
/dev/hugepages), but if domain is started without hugepages (or
|
|
|
639072 |
more specifically - private hugetlbfs path wasn't created on
|
|
|
639072 |
domain startup), then the reconnect code tries to create it.
|
|
|
639072 |
But it fails to do so, well, it fails to set seclabels on the
|
|
|
639072 |
path because, because the path does not exist in the private
|
|
|
639072 |
namespace. And it doesn't exist because we specifically create
|
|
|
639072 |
only a subset of all possible /dev nodes. Therefore, the mount
|
|
|
639072 |
event, whilst propagated, is not successful and hence the
|
|
|
639072 |
filesystem is not mounted. We have to do it ourselves.
|
|
|
639072 |
|
|
|
639072 |
If hugetlbfs is mount anywhere else there's no problem and this
|
|
|
639072 |
is effectively a dead code.
|
|
|
639072 |
|
|
|
639072 |
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2123196
|
|
|
639072 |
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
|
|
|
639072 |
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
|
|
|
639072 |
(cherry picked from commit 0377177c7856bb87a9d8aa1324b54f5fbe9f1e5b)
|
|
|
639072 |
|
|
|
639072 |
Conflicts:
|
|
|
639072 |
- docs/kbase/qemu-passthrough-security.rst: Well, v8.8.0-rc1~32
|
|
|
639072 |
isn't backported, thus we can't remove a paragraph that the
|
|
|
639072 |
backported commit did. It's a documentation after all, so no
|
|
|
639072 |
harm.
|
|
|
639072 |
|
|
|
3a9410 |
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2123196
|
|
|
639072 |
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
|
|
|
639072 |
---
|
|
|
639072 |
src/qemu/qemu_process.c | 3 +++
|
|
|
639072 |
1 file changed, 3 insertions(+)
|
|
|
639072 |
|
|
|
639072 |
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
|
|
|
639072 |
index 540eee9ff0..1164340aa9 100644
|
|
|
639072 |
--- a/src/qemu/qemu_process.c
|
|
|
639072 |
+++ b/src/qemu/qemu_process.c
|
|
|
639072 |
@@ -3906,6 +3906,9 @@ qemuProcessBuildDestroyMemoryPathsImpl(virQEMUDriver *driver,
|
|
|
639072 |
return -1;
|
|
|
639072 |
}
|
|
|
639072 |
|
|
|
639072 |
+ if (qemuDomainNamespaceSetupPath(vm, path, NULL) < 0)
|
|
|
639072 |
+ return -1;
|
|
|
639072 |
+
|
|
|
639072 |
if (qemuSecurityDomainSetPathLabel(driver, vm, path, true) < 0)
|
|
|
639072 |
return -1;
|
|
|
639072 |
} else {
|
|
|
639072 |
--
|
|
|
3a9410 |
2.38.0
|
|
|
639072 |
|