10.14. 虚拟化

Windows 虚拟机可能会因为存储错误而变得无响应

在使用 Windows 客户机操作系统的虚拟机上，在高 I/O 负载下，系统在某些情况下会变得无响应。当发生这种情况时，系统会记录一个 viostor Reset to device, \Device\RaidPort3, was issued 错误。当前没有解决此问题的方法。

Jira:RHEL-1609^[1]

在引导时，带有某些 PCI 设备的 Windows 10 虚拟机可能会变得无响应

目前，如果将具有本地磁盘后端的 virtio-win-scsi PCI 设备被附加到虚拟机，则使用 Windows 10 客户机操作系统的虚拟机(VM)会在启动过程中变得无响应。

临时解决方案：在启用了 multi_queue 选项的情况下引导虚拟机。

Jira:RHEL-1084^[1]

将 virtiofs 与 rsync 和 du 命令一起使用可能会导致 太多打开的文件 错误

virtiofsd 守护进程将文件描述符保持打开，直到客户机使其缓存无效。当跟踪大量文件时，这可能会导致主机上的 virtiofsd 超过最大打开的文件限制。

因此，当使用 virtiofs 与 guest 共享大量文件时，在共享目录中使用 rsync 和 du 命令可能会导致 太多打开的文件 错误。

要临时解决这个问题，请在客户机的 XML 配置中增加 virtiofsd 最大打开文件限制。例如：

<filesystem type='mount' accessmode='passthrough'>
...
<binary path='/usr/libexec/virtiofsd' xattr='on'>
  <openfiles max='2000000'/>
</binary>
...
</filesystem>

<filesystem type='mount' accessmode='passthrough'>
...
<binary path='/usr/libexec/virtiofsd' xattr='on'>
  <openfiles max='2000000'/>
</binary>
...
</filesystem>

Copy to Clipboard

Toggle word wrap

在本例中，&lt ;openfiles max > 属性设置为 200万文件。

如需更多信息，请参阅 rsync 和 du 命令中的 Virtiofs 'too many open files' 错误 KCS 解决方案。

Jira:RHEL-99895^[1]

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

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

Jira:RHEL-53962,JIRA:RHEL-53965

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

如果您试图启动具有大量可引导数据磁盘的虚拟机(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>

<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

具有大内存的虚拟机无法在具有 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>

<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^[1]

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

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

Jira:RHEL-66229, Jira:RHELDOCS-19066

具有 5 级页面合并和大量内存的虚拟机有时无法启动

如果将 host-phys-bits-limit 参数设置为 49 或更多，则具有以下配置的虚拟机无法引导：

虚拟机分配超过 1TB 内存
虚拟机使用 5 级页面合并功能
主机在其固件中使用系统管理模式(SMM)

相反，尝试引导虚拟机会失败并显示 ERROR: Out of aligned pages。

临时解决方案：将 host-phys-bits-limit 参数设置为 48 或更少。

Jira:RHEL-82685

在 Nutanix AHV 中使用 LVM 克隆或恢复 RHEL 9 虚拟机会导致非 root 分区消失

当在 Nutanix AHV 虚拟机监控程序上托管的虚拟机中运行 RHEL 9 客户机操作系统时，从快照中恢复虚拟机或克隆虚拟机目前会导致虚拟机中的非 root 分区在虚拟机中使用逻辑卷管理(LVM)时消失。因此，会出现以下问题：

从快照恢复虚拟机后，虚拟机无法引导，而是进入紧急模式。
通过克隆创建的虚拟机无法引导，而是进入紧急模式。

要临时解决这个问题，在虚拟机的紧急模式下执行以下操作：

删除 LVM 系统设备文件：
```
rm /etc/lvm/devices/system.devices
```
```
# rm /etc/lvm/devices/system.devices
```
Copy to Clipboard Toggle word wrap
重新创建 LVM 设备设置：
```
vgimportdevices -a
```
```
# vgimportdevices -a
```
Copy to Clipboard Toggle word wrap
重启虚拟机

这样，克隆或恢复的虚拟机可以正确引导。

另外，为了避免这个问题发生，请在克隆虚拟机或创建虚拟机快照前进行以下操作：

取消 /etc/lvm/lvm.conf 文件中 use_devicesfile = 0 行的注释。
重新生成 initramfs。要做到这一点，使用虚拟机中的以下步骤，并将 &lt ;kernelVersion > 替换为您要重建的内核的完整版本。
1. 备份当前的 initramfs 配置：
  # cp /boot/initramfs-<kernelVersion>.img /boot/initramfs-<kernelVersion>.img.bak
  Copy to Clipboard Toggle word wrap
2. 构建 initramfs ：
  # dracut -f /boot/initramfs-<kernelVersion>.img <kernelVersion>
  Copy to Clipboard Toggle word wrap
重启虚拟机以验证引导是否成功。

Jira:RHELPLAN-114103^[1]

10.14. 虚拟化

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links