在配置软 RAID、SPICE 与显卡直通后 virtiofsd 无法正常工作

这是我第一次使用 kvm + libvirtd + virt-manager 的组合来运行一个 Win11 虚拟机。起初我在 virt-manager 中配置了 Filesystem Passthrough( virtiofs )并在虚拟机中安装好 virtio 驱动以及 WinFRP 之后便能成功地在虚拟机中看到宿主机的文件夹。

看起来一切都没有问题,由于我物理机上装的是双系统,似乎没有必要需要一份新的虚拟机数据,于是我参考 这篇文章 将原 Windows 分区组了软 RAID ,装好 virtio 相关驱动后便可以正常进入系统,也可以正常访问共享文件夹,物理机重启至 Windows 再重启至 Linux 后启动 Windows 虚拟机经过多次实验也没有问题。

我还配置了 spice tools,用以在虚拟机与宿主机间共享剪贴板,这个功能目前看来也能正常工作(除了在 Windows 上的 SPICE 服务经常无法自行启动,因此我在 Windows 服务设置中将其配置为 自动(延迟启动)

由于我的笔记本有 Intel 核显与 NVIDIA 独显,而后者通常在 Linux 环境下用不到,于是接下来又继续按照 SUSE wiki 配置了 NVIDIA 显卡直通,此时事情开始发生了变化——我不再能成功启动 Windows 虚拟机,提示 virtiofsd died unexpectedly

我首先尝试在 virt-manager 中修改 filesystem passthrough 的 driver 为 virtio-9p ,此时虚拟机可以正常启动(但无法看到共享文件夹),在系统中也可以看到并正常使用直通进去的 NVIDIA 显卡,但当我切回 virtiofs 时虚拟机再次无法启动,提示 virtiofsd died unexpectedly ——即便我尝试将 NVIDIA 显卡从虚拟机中卸载了,所以看起来这并不是显卡直通导致的问题?

首先查看 virt-manager 给出的报错信息,除了能看得出相关组建应该是使用 python 编写的以外,我并没有获得任何有用信息:

Error starting domain: internal error: virtiofsd died unexpectedly

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 71, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 107, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
    ret = fn(self, *args, **kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1425, in startup
    self._backend.create()
  File "/usr/lib64/python3.11/site-packages/libvirt.py", line 1379, in create
    raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: internal error: virtiofsd died unexpectedly

接下来查看 /var/log/libvirt/qemu/ 下的日志文件,以 VM 名称命名的文件中只有一句相关联的报错信息:

libvirt:  error : libvirtd quit during handshake: Input/output error

接下来查看一个名为 虚拟机名称-fs0-virtiofsd.log 的日志文件,其中似乎指示了文件系统无法启动的原因:

[2024-02-24T10:02:15Z WARN  virtiofsd] Use of deprecated option format '-o': Please specify options without it (e.g., '--cache auto' instead of '-o cache=auto')
[2024-02-24T10:02:15Z INFO  virtiofsd] Waiting for vhost-user socket connection...
[2024-02-24T10:02:15Z INFO  virtiofsd] Client connected, servicing requests
Warning: Cannot announce submounts, client does not support it
[2024-02-24T10:03:36Z INFO  virtiofsd] Client disconnected, shutting down
[2024-02-24T10:04:05Z WARN  virtiofsd] Use of deprecated option format '-o': Please specify options without it (e.g., '--cache auto' instead of '-o cache=auto')
[2024-02-24T10:04:05Z INFO  virtiofsd] Waiting for vhost-user socket connection...
[2024-02-24T10:04:06Z INFO  virtiofsd] Client connected, servicing requests
Warning: Cannot announce submounts, client does not support it
[2024-02-24T10:05:30Z INFO  virtiofsd] Client disconnected, shutting down
[2024-02-24T10:07:21Z WARN  virtiofsd] Use of deprecated option format '-o': Please specify options without it (e.g., '--cache auto' instead of '-o cache=auto')
[2024-02-24T10:07:21Z INFO  virtiofsd] Waiting for vhost-user socket connection...
[2024-02-24T10:07:21Z INFO  virtiofsd] Client connected, servicing requests
Warning: Cannot announce submounts, client does not support it
[2024-02-24T10:10:39Z INFO  virtiofsd] Client disconnected, shutting down
[2024-02-24T10:38:12Z WARN  virtiofsd] Use of deprecated option format '-o': Please specify options without it (e.g., '--cache auto' instead of '-o cache=auto')
[2024-02-24T10:38:12Z INFO  virtiofsd] Waiting for vhost-user socket connection...
[2024-02-24T10:38:12Z INFO  virtiofsd] Client connected, servicing requests
Warning: Cannot announce submounts, client does not support it
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied
libvirt:  error : cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied

但当我尝试检查 /usr/libexec/virtiofsd/virtiofsd 的可执行权限时,我发现对于任何用户而言其都有着可执行权限:

$ ls -la /usr/libexec/virtiofsd/virtiofsd
-rwxr-xr-x 1 root root 2788952 Feb 24 03:33 /usr/libexec/virtiofsd/virtiofsd

因此这个 cannot execute binary /usr/libexec/virtiofsd/virtiofsd: Permission denied 的问题似乎并非是文件可执行权限引起的,事情在此陷入了死胡同 :(

我的共享文件夹的 xml 配置如下,但我并不太认为是这个配置引起的问题,因为在一开始时共享文件夹是可以正常工作的:

<filesystem type="mount" accessmode="passthrough">
  <driver type="virtiofs"/>
  <source dir="/home/user/Desktop"/>
  <target dir="opensuse"/>
  <address type="pci" domain="0x0000" bus="0x06" slot="0x00" function="0x0"/>
</filesystem>

似乎也并不是 AppArmor 的问题,因为当我停止 AppArmor 服务运行后虚拟机依然没法启动,同时在 AppArmor 配置文件中 virtfsd 是可以被启动的:

$ sudo cat /etc/apparmor.d/usr.sbin.libvirtd | grep -i "virtiofsd"
  /usr/{lib,lib64,lib/qemu,libexec}/virtiofsd PUx,

目前看来应该是 AppArmor 的问题,当我在 /etc/apparmor.d/usr.sbin.libvirtd 中添加了一行 /usr/{lib,lib64,lib/qemu,libexec}/virtiofsd/* PUx, 后,再重启 AppArmor ,共享文件夹便能正常工作

但这似乎并不能解释为什么在之前并不需要添加这一额外配置:thinking:

本主题在最后一个回复创建后60分钟后自动锁定。不再允许添加新回复。