There are some network FSs (ceph, CIFS) that propagate XATTTs properly and thus SELinux labels too. In such case using dynamic seclabels would get in the way of migration as new seclabel is assigned to the domain on the destination and thus two processes with different labels (the source and the destination QEMU/helper process) would try to access the same file. One of them is necessarily going to be denied access. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> --- docs/drvqemu.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/drvqemu.rst b/docs/drvqemu.rst index bbd51066a1..fa23912937 100644 --- a/docs/drvqemu.rst +++ b/docs/drvqemu.rst @@ -294,6 +294,13 @@ use the 'context' option when mounting the filesystem to set the default label to ``system_u:object_r:virt_image_t``. In the case of NFS, there is an alternative option, of enabling the ``virt_use_nfs`` SELinux boolean. +There are some network filesystems, however, that propagate SELinux labels +properly, just like a local filesystem (e.g. ceph of CIFS). In such case, +dynamic labelling (described below) might prevent migration of a virtual +machine as new unique SELinux label is assigned to the virtual machine on the +migration destination side. Users are advised to use static labels (``<seclabel +type='static' .../>``). + SELinux sVirt confinement ~~~~~~~~~~~~~~~~~~~~~~~~~ -- 2.38.2
