Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

10.18. 虚拟化

在某些情况下，通过 https 或 ssh 安装虚拟机会失败

目前，当尝试通过 https 或 ssh 连接从 ISO 源安装客户机操作系统时，virt-install 工具会失败 - 例如使用 virt-install --cdrom https://example/path/to/image.iso。上述操作意外中止，并显示 internal error: process exited while connecting to monitor 消息，而不是创建虚拟机(VM)。

同样，使用 RHEL 9 web 控制台安装客户机操作系统失败，如果使用了 https 或 ssh URL，或 Download OS 功能，则会显示 Unknown driver 'https' 错误。

临时解决方案：在主机上安装 qemu-kvm-block-curl 和 qemu-kvm-block-ssh 来启用 https 和 ssh 协议支持。或者，使用不同的连接协议或不同的安装源。

Jira:RHELPLAN-99854[1]

在虚拟机中使用 NVIDIA 驱动程序会禁用 Wayland

目前，NVIDIA 驱动程序与 Wayland 图形会话不兼容。因此，使用 NVIDIA 驱动程序的 RHEL 客户机操作系统会自动禁用 Wayland 并加载 Xorg 会话。这主要在以下情况下发生：

  • 当您通过 NVIDIA GPU 设备传递给 RHEL 虚拟机(VM)
  • 当您为 RHEL 虚拟机分配 NVIDIA vGPU mediated 设备

当前没有解决此问题的方法。

Jira:RHELPLAN-117234[1]

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

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

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

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

  1. 删除 LVM 系统设备文件： 

    # rm /etc/lvm/devices/system.devices
    Copy to Clipboard Toggle word wrap

  2. 重新创建 LVM 设备设置： 

    # vgimportdevices -a
    Copy to Clipboard Toggle word wrap
  3. 重启虚拟机

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

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

  1. 取消注释 /etc/lvm/lvm.conf 文件中的 use_devicesfile = 0 行。

  2. 重新生成 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
  3. 重启虚拟机以验证引导是否成功。

Jira:RHELPLAN-114103[1]

在 AMD Milan 系统上有时无法提供 Milan VM CPU 类型

在某些 AMD Milan 系统上，默认在 BIOS 中禁用了增强 REP MOVSB(erms)和 Fast Short REP MOVSB(fsrm)功能标记。因此，在这些系统上可能无法使用 Milan CPU 类型。另外，载具有不同功能标志设置的 Milan 主机之间的虚拟机实时迁移可能会失败。

临时解决方案：在主机的 BIOS 中手动打开 erms 和 fsrm。

Jira:RHELPLAN-119655[1]

带有故障切换设置的 hostdev 接口在热拔后无法进行热插

从正在运行的虚拟机(VM)中删除带有故障切换配置的 hostdev 网络接口后，该接口目前无法重新连接到同一正在运行的虚拟机。当前没有解决此问题的方法。

Jira:RHEL-7337

带有故障切换 VF 的虚拟机实时复制迁移失败

目前，如果虚拟机使用启用了虚拟功能(VF)故障转移功能的设备，则试图对一个正在运行的虚拟机(VM)进行 post-copy 迁移会失败。

临时解决方案： 使用标准迁移类型，而不是复制后迁移。

Jira:RHEL-7335

主机网络无法在实时迁移过程中 ping 使用 VF 的虚拟机

当使用配置的虚拟功能 (VF) 实时迁移虚拟机时，如使用虚拟 SR-IOV 软件的虚拟机，虚拟机的网络不对其它设备看到，如 ping 之类的命令无法访问虚拟机。完成迁移后，问题将不再发生。

Jira:RHEL-7336

禁用 AVX 会导致虚拟机无法引导

在使用具有高级向量扩展(AVX)支持的 CPU 的主机上，尝试引导明确禁用 AVX 的虚拟机当前会失败，并触发虚拟机中的内核 panic。当前没有解决此问题的方法。

Jira:RHELPLAN-97394[1]

迁移的 IdM 用户可能会因为不匹的域 SID 而无法登录

如果您使用 ipa migrate-ds 脚本将用户从一个 IdM 部署迁移到另一个，则这些用户可能会在使用 IdM 服务时有问题，因为它们之前存在的安全标识符(SID)没有当前 IdM 环境的域 SID。例如，这些用户可以使用 kinit 工具检索 Kerberos 票据，但不能登录。

临时解决方案：请参阅以下知识库文章： Migrated IdM 用户因为不匹配的域 SID 而无法登录。

Jira:RHELPLAN-109613[1]

在网络接口重置后，Windows VM 无法获取 IP 地址

有时，Windows 虚拟机在自动网络接口重置后无法获取 IP 地址。因此，虚拟机无法连接到网络。

临时解决方案：在 Windows 设备管理器中禁用和重新启用网络适配器驱动程序。

Jira:RHEL-11366

Windows Server 2016 虚拟机有时会在热插拔 vCPU 后停止工作

目前，将 vCPU 分配给运行 Windows Server 2016 客户机操作系统的虚拟机(VM)可能会导致各种问题，如虚拟机意外终止、变得没有响应或重启。当前没有解决此问题的方法。

Jira:RHELPLAN-63771[1]

在具有 NVIDIA passthrough 设备的虚拟机上的冗余错误消息

使用带有 RHEL 9.2 及更新版本的操作系统的 Intel 主机机器时，带有直通 NVDIA GPU 设备的虚拟机(VM)会频繁地记录以下错误信息： 

Spurious APIC interrupt (vector 0xFF) on CPU#2, should never happen.
Copy to Clipboard Toggle word wrap

但是，这个错误消息不会影响虚拟机的功能，可以忽略。详情请查看 红帽知识库。

Jira:RHELPLAN-141042[1]

在主机上重启 OVS 服务可能会阻止在其上运行的虚拟机的网络连接

当 Open vSwitch (OVS)服务在主机上重启时或崩溃时，在此主机上运行的虚拟机(VM)无法恢复网络设备的状态。因此，虚拟机可能无法完全接收数据包。

此问题只会影响在 virtio 网络堆栈中使用压缩 virtqueue 格式的系统。

临时解决方案：使用 virtio 网络设备定义中的 packed=off 参数来禁用压缩的 virtqueue。当禁用压缩的 virtqueue 时，网络设备的状态在某些情况下可以从 RAM 中恢复。

Jira:RHEL-333

恢复中断的复制后虚拟机迁移可能会失败

如果虚拟机(VM)的复制后迁移中断，然后在同一传入端口上立即恢复，则迁移可能会失败，并显示以下错误 Address already in use

临时解决方案：在恢复后复制迁移或切换到另一个端口进行迁移恢复前至少等待 10 秒。

Jira:RHEL-7096

NUMA 节点映射在 AMD EPYC CPU 上无法正常工作

QEMU 无法正确处理 AMD EPYC CPU 上的 NUMA 节点映射。因此，如果使用 NUMA 节点配置，具有这些 CPU 的虚拟机(VM)的性能可能会受到负面影响。另外，虚拟机在启动过程中会显示类似如下的警告。 

sched: CPU #4's llc-sibling CPU #3 is not on the same node! [node: 1 != 0]. Ignoring dependency.
WARNING: CPU: 4 PID: 0 at arch/x86/kernel/smpboot.c:415 topology_sane.isra.0+0x6b/0x80
Copy to Clipboard Toggle word wrap

临时解决方案：不要将 AMD EPYC CPU 用于 NUMA 节点配置。

Jira:RHELPLAN-150884[1]

PCIe ATS 设备无法在 Windows 虚拟机上工作

当您在带有 Windows 客户机操作系统的虚拟机的 XML 配置中配置 PCIe 地址转换服务(ATS)设备时，在引导虚拟机后，客户机不会启用 ATS 设备。这是因为 Windows 目前不支持 virtio 设备上的 ATS。

如需更多信息，请参阅 红帽知识库。

Jira:RHELPLAN-118495[1]

virsh blkiotune --weight 命令无法设置正确的 cgroup I/O 控制器值

目前，使用 virsh blkiotune --weight 命令设置 VM 权重无法按预期工作。该命令无法在 cgroup I/O 控制器接口文件中设置正确的 io.bfq.weight 值。目前还没有临时解决方案。

Jira:RHELPLAN-83423[1]

启动带有 NVIDIA A16 GPU 的虚拟机有时会导致主机 GPU 停止工作

目前，如果您启动了一个使用 NVIDIA A16 GPU 直通设备的虚拟机，在某些情况下，主机系统上的 NVIDIA A16 GPU 物理设备会停止工作。

要临时解决这个问题，请重新 hypervisor ,并将 GPU 设备的 reset_method 设置为 bus ： 

# echo bus > /sys/bus/pci/devices/<DEVICE-PCI-ADDRESS>/reset_method
# cat /sys/bus/pci/devices/<DEVICE-PCI-ADDRESS>/reset_method
bus
Copy to Clipboard Toggle word wrap

详情请查看 红帽知识库。

Jira:RHEL-7212[1]

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]

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

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

Jira:RHEL-935[1]

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

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

Jira:RHEL-12118

virtio 文件系统在 Windows 虚拟机中性能不佳

目前，当在使用 Windows 客户机操作系统的虚拟机(VM)上配置了 virtio 文件系统(virtiofs)时，虚拟机中的 virtiofs 性能比使用 Linux 客户机的虚拟机中的性能要差的多。当前没有解决此问题的方法。

Jira:RHEL-1212[1]

在 Windows 虚拟机上热拔存储设备可能会失败

在使用 Windows 客户机操作系统的虚拟机(VM)上，当虚拟机运行时删除存储设备（也称为设备热拔）在某些情况下会失败。因此，存储设备一直附加在虚拟机上，磁盘管理器服务可能会变得无响应。当前没有解决此问题的方法。

Jira:RHEL-869

将 CPU 热插到 Windows 虚拟机可能会导致系统失败

当将最大数量的 CPU 热插到启用了巨页的 Windows 虚拟机(VM)时，客户机操作系统可能会崩溃，并显示以下 停止错误 ： 

PROCESSOR_START_TIMEOUT
Copy to Clipboard Toggle word wrap

当前没有解决此问题的方法。

Jira:RHEL-1220

在 Windows 虚拟机上更新 virtio 驱动程序可能会失败

当在 Windows 虚拟机(VM)上更新 KVM 半虚拟化(virtio)驱动程序时，更新可能会导致鼠标停止工作，可能无法对新安装的驱动程序签名。当通过从 virtio-win-guest-tools 软件包（其是 virtio-win.iso 文件的一部分）安装来更新 virtio 驱动程序时，此问题会发生。

临时解决方案：使用 Windows 设备管理器更新 virtio 驱动程序。

Jira:RHEL-574[1]

在使用 vhost-kernel的虚拟机中无法更改 TX 队列大小

目前，您无法在使用 vhost-kernel 作为 virtio 网络驱动程序的后端的 KVM 虚拟机(VM)上设置 TX 队列大小。因此，您只能对 TX 队列使用默认值 256 ，这可能会阻止您优化虚拟机网络吞吐量。当前没有解决此问题的方法。

Jira:RHEL-1138[1]

虚拟机在 AMD EPYC 型号上错误地报告 spec_rstack_overflow 参数的 vulnerable 状态

当您引导主机时，它不会检测 spec_rstack_overflow 参数中的任何漏洞。查询日志中的参数，它显示消息： 

# cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
Mitigation: Safe RET
Copy to Clipboard Toggle word wrap

在同一主机上引导虚拟机后，虚拟机在 spec_rstack_overflow 参数中检测到一个漏洞。当查询日志中的参数时，它显示消息： 

# cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
Vulnerable: Safe RET, no microcode
Copy to Clipboard Toggle word wrap

但是，这是一个假的警告消息，您可以忽略虚拟机中 /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow 文件的状态。

Jira:RHEL-17614[1]

链接状态在虚拟机上显示 up，即使当 e1000e 或 igb 型号接口的状态为 down 时

在引导虚拟机前，为 e1000 或 igb 型号网络接口的以太网链接状态设置为 down。尽管如此，在虚拟机引导后，网络接口保持 up 状态，因为当您将以太网链接状态设置为 down ，然后停止并启动虚拟机时，它会自动设置回 up。因此，不能保持网络接口的正确状态。

临时解决方案：使用以下命令将网络接口状态设置为 down ： 

# ip link set dev eth0 down
Copy to Clipboard Toggle word wrap

或者，您可以在虚拟机运行时尝试删除并重新添加此网络接口。

Jira:RHEL-21867

SeaBIOS 无法从具有 4096 个字节扇区大小的磁盘引导

当使用 SeaBIOS 从使用 4096 字节的逻辑或物理扇区大小的磁盘引导虚拟机时，引导磁盘没有显示为可用，引导虚拟机失败。要从这样的磁盘引导虚拟机，请使用 UEFI 而不是 SeaBIOS。

Jira:RHEL-7110

如果每个 CPU 使用超过 128 个核，则 Windows Server 2019 虚拟机在引导时会崩溃

当使用 Windows Server 2019 客户机操作系统的虚拟机在被配置为单个虚拟 CPU (vCPU)使用超过 128 个核时，其目前无法引导。虚拟机会在蓝屏上显示一个停止错误，而不是引导。

临时解决方案：每个 vCPU 使用少于 128 个内核。

Jira:RHELDOCS-18863[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]

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

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

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

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

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

Jira:RHEL-82759

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

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

如果使用大量 vCPU 分配，Windows 2025 虚拟机会减慢

当分配有 32 个或更多 vCPU 时，Windows Server 2025 虚拟机(VM)在 Red Hat Enterprise Linux 主机上会减慢速度。因此，当虚拟机配置了大量 vCPU 时，Windows 虚拟机可能会在引导期间引导或卡住。

临时解决方案：您可以自行使用临时解决方案。使用少量 vCPU 引导虚拟机，以便在 Windows 服务器上禁用 plaformclock。在具有管理员特权的命令提示中，运行以下命令： 

bcdedit /set useplatformclock no
Copy to Clipboard Toggle word wrap

然后，关闭虚拟机并使用所需的大量 vCPU 重新配置它。另外，请确保在再次启动大型虚拟机前启用 hv-time 选项。

Jira:RHEL-62742[1]

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

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

Jira:RHEL-32892[1]

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

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

Jira:RHEL-53962,JIRA:RHEL-53965

在 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

NetworkManager-wait-online.service 使用加速网络在 Azure 虚拟机上启动

当您使用加速网络功能（也称为单根输入输出虚拟化(SR-IOV)）启动 Azure 平台的 Red Hat Enterprise Linux 虚拟机时，多个网络接口卡可能具有相同的 MAC 地址。因此，虚拟机可能无法从 DHCP 服务器获取 IP 地址，NetworkManager-wait-online.service 可能无法在引导时启动。

临时解决方案：不要安装 initscripts-rename-device 软件包，以便现有设备不会重命名到现有设备名称。

Jira:RHEL-79783[1]

现在，在启用了 FIPS 的系统上强制 Extended Master Secret TLS 扩展

随着 RHSA-2023:3722 公告的发布，在启用了 FIPS 的 RHEL 9 系统上，对 TLS 1.2 连接强制Extended Master Secret (EMS)扩展 (RFC 7627) 。这符合 FIPS-140-3 要求。TLS 1.3 不受影响。

不支持 EMS 或 TLS 1.3 的传统客户端现在无法连接到在 RHEL 9 和 10 上运行的 FIPS 服务器。同样，在 FIPS 模式中的 RHEL 9 和 10 客户端无法连接到只支持没有 EMS 的 TLS 1.2 的服务器。在实践中意味着这些客户端无法连接到 RHEL 6、RHEL 7 和非 RHEL 传统操作系统上的服务器。这是因为传统的 OpenSSL 1.0.x 版本不支持 EMS 或 TLS 1.3。

另外，如果 hypervisor 使用没有 EMS 的 TLS 1.2，则从启用了 FIPS 的 RHEL 客户端连接到 hypervisor （如 VMWare ESX）现在会失败，并显示 Provider routines::ems not enabled 错误。要临时解决这个问题，请更新 hypervisor 以支持带有 EMS 扩展的 TLS 1.3 或 TLS 1.2。对于 VMWare vSphere，这意味着版本 8.0 或更高版本。

如需更多信息，请参阅 Red Hat Enterprise Linux 9.2 及之后的版本强制使用 TLS 扩展"扩展 Master Secret "。

Jira:RHEL-13340[1]

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat