10.16. 虚拟化


安装 VirtIO-Win 捆绑包不能被取消

目前,如果您在 Windows 客户机操作系统中从 VirtIO-Win 安装程序捆绑包开始安装 virtio-win 驱动程序,点安装过程中的 Cancel 按钮无法正确停止它。安装程序向导界面显示一个 "Setup Failed" 屏幕,但驱动程序安装了,且客户机的 IP 地址被重置了。

Jira:RHEL-53962,JIRA:RHEL-53965

安全执行虚拟机无法使用文件支持的内存支持引导

如果您配置一个带有 Secure Execution 的虚拟机,以使用文件支持的内存支持,则虚拟机当前无法引导,并显示 Protected boot has failed 错误。

临时解决方案:编辑 /etc/libvirt/qemu.conf 文件,并将 memory_backing_dir 行设置为以下值:

memory_backing_dir = "/dev/shm/"
Copy to Clipboard Toggle word wrap

之后,受影响的虚拟机可以按预期引导。

Jira:RHEL-58218

没有配置 discard_granularity 时,发送丢弃 I/O 请求的虚拟机可能会暂停

主机内核使未对齐的丢弃 I/O 请求失败,QEMU 使用 werror= policy 参数响应此类故障。当 werror 被设置为 stop:werror=stop 时,失败的丢弃请求会导致虚拟机(VM)暂停。这通常不可取,因为无法纠正这种情况并再次恢复虚拟机。

临时解决方案:确保在 virtio-blkvirtio-scsi 磁盘上设置了 discard_granularity 参数,并匹配主机的 /sys/block/<blkdev>/queue/discard_granularity 值。这使得虚拟机意识到对齐约束,并确保丢弃的请求被正确地对齐,因此它们不会失败。

Jira:RHEL-87642[1]

--migrate-disks-detect-zeroes 选项可能无法用于虚拟机迁移

目前,当在 RHEL 10 上迁移虚拟机(VM)时,--migrate-disks-detect-zeroes 选项可能无法正常工作,且迁移可能会在指定磁盘上没有零块检测的情况下继续进行。这个问题是由 QEMU 中的一个 bug 引起的,其中镜像作业一直依赖于打孔,从而导致一个稀疏目标文件。

Jira:RHEL-88435

具有大量可引导数据磁盘的虚拟机可能无法启动

如果您试图启动具有大量可引导数据磁盘的虚拟机(VM),则虚拟机可能无法引导,并显示以下错误:Something has gone seriously wrong: import_mok_state() failed: Volume Full

临时解决方案:减少可引导数据磁盘的数量,并使用一个系统磁盘。要确保系统磁盘是引导顺序中的第一个,请将 boot order=1 添加到 XML 配置中系统磁盘的设备定义中。例如:

<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2'/>
  <source file='/path/to/disk.qcow2'/>
  <target dev='vda' bus='virtio'/>
  <boot order='1'/>
</disk>
Copy to Clipboard Toggle word wrap

仅为系统磁盘设置引导顺序。

Jira:RHEL-68418

virtiofs 共享目录中打开的文件太多可能会使 vrtiofsd 进程崩溃

当从虚拟机(VM)访问具有大量打开文件的 virtiofs 共享目录时,操作可能会失败,并显示以下错误: Too many open filesvirtiofsd 进程可能会崩溃。

临时解决方案:尝试以下任一步骤:

  • 以 root 用户身份运行 virtiofsd ,并使用 -inode-file-handles=mandatory 命令行选项。
  • 使用 --cache=never 命令行选项。
  • 使用 --rlimit-nofile 命令行选项增加 virtiofsd 允许使用的文件描述符数。

Jira:RHEL-87161[1]

具有大内存的虚拟机无法在具有 AMD Genoa CPU 的 SEV-SNP 主机上引导

目前,虚拟机(VM)无法在使用第 4 代 AMD EPYC 处理器(也称为 Genoa),并启用了 Secure Nested Paging (SEV-SNP)功能的 AMD 安全加密虚拟化的主机上引导。虚拟机没有启动,而是发生了内核 panic。

Jira:RHEL-32892[1]

virtio balloon 驱动程序有时在 Windows 10 和 Windows 11 虚拟机上无法工作

在某些情况下,virtio-balloon 驱动程序在使用 Windows 10 或 Windows 11 客户机操作系统的虚拟机(VM)上无法正常工作。因此,此类虚拟机可能无法有效地使用其分配的内存。

Jira:RHEL-12118

具有内存气球设备集的 Windows 11 虚拟机在重启过程中可能会意外关闭

目前,重新引导使用 Windows 11 客户机操作系统和内存 balloon 设备的虚拟机(VM)在某些情况下会失败,并显示 DRIVER POWER STAT FAILURE 蓝屏错误。

Jira:RHEL-935[1]

带有 VBS 和 IOMMU 设备的 Windows 虚拟机无法引导

当您通过 qemu-kvm 工具引导一个启用了基于虚拟化安全性(VBS)的 Windows 虚拟机和一个输入输出内存管理单元(IOMMU)设备时,引导序列只显示引导屏幕,从而导致引导过程不完整。

临时解决方案:确保虚拟机域 XML 被配置为如下:

<features>
  <ioapic driver='qemu'/>
</features>
<devices>
<iommu model='intel'>
   <driver intremap='on' eim='off' aw_bits='48'/>
   <alias name='iommu0'/>
</iommu>
<memballoon model='virtio'>
   <alias name='balloon0'/>
   <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
   <driver iommu='on' ats='on'/>
</memballoon>
</devices>
Copy to Clipboard Toggle word wrap

否则,Windows 虚拟机无法引导。

Jira:RHEL-45585[1]

在 hypervisor 启动类型设为 auto 的 Sapphire Rapids CPU 上运行的 Windows 虚拟机在重启后无法引导

如果您在运行在 Sapphire Rapids CPU 上的 Windows 虚拟机(VM)中将 hypervisor 启动类型设置为 auto,则虚拟机在重启后可能无法引导。例如,您可以使用 bcdedit /set hypervisorlaunchtype Auto 命令将 hypervisor 启动类型设置为 auto

临时解决方案:不要在 Windows 虚拟机中将 hypervisor 启动类型设置为 auto

Jira:RHEL-67699

对具有 VBS 的 Windows 客户机热插拔 vCPU 和内存无法正常工作

目前,Windows Virtualization-based Security(VBS)与热插 CPU 和内存资源不兼容。因此,尝试将内存或 vCPU 附加到启用了 VBS 的运行的 Windows 虚拟机(VM)中,仅在客户机系统重启后将资源添加到虚拟机。 

Jira:RHEL-66229, Jira:RHELDOCS-19066

在 IBM Z 上迁移虚拟机有时会删除网络配置

目前,在 IBM Z 主机间迁移虚拟机(VM)后,虚拟机的网络配置在某些情况下是重置,这会导致网络在虚拟机上不可用。要临时解决这个问题,请在启动虚拟机迁移前禁用 vhost-net 服务。

Jira:RHEL-42486[1]

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat