External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-07-11 04:15:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

kbase: Document QEMU private mount NS limitations

Browse Source 
There are two points I've taken for granted:

  1) the mount points are set before starting a guest,
  2) the / and its submounts are marked as shared, so that mount
     events propagate into child namespaces when assumption 1) is
     not held.

But what's obvious to me might not be obvious to our users.
Document these known limitations.

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>
This commit is contained in:
Michal Privoznik 2022-09-05 12:37:16 +02:00
parent f14f8dff93
commit d3397885d5
1 changed files with 22 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
docs/kbase/qemu-passthrough-security.rst
View File

@ -156,3 +156,25 @@ will affect all virtual machines. These settings are all made in
* Cgroups - set ``cgroup_device_acl`` to include the desired device node, or
``cgroup_controllers = [...]`` to exclude the ``devices`` controller.
Private monunt namespace
----------------------------
As mentioned above, libvirt launches each QEMU process in its own ``mount``
namespace. It's recommended that all mount points are set up prior starting any
guest. For cases when that can't be assured, mount points in the namespace are
marked as slave so that mount events happening in the parent namespace are
propagated into this child namespace. But this may require an additional step:
mounts in the parent namespace need to be marked as shared (if the distribution
doesn't do that by default). This can be achieved by running the following
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.