☰

Hyper-V Server 2019 和 vCPU 的奇怪行为

tag-icon • tag-icon hyper-v
Hyper-V Server 2019 和 vCPU 的奇怪行为

我不确定它是什么时候开始的，但我相信情况并非总是如此。

集群中带有 Hyper-V 的 Dell R550 Server 2019 Standard，2 个节点。2 个 Intel Xeon Silver 4309Y 8C/16T，因此在 Windows 中显示为 16C/32T。开始制作新的 Server 2019 Standard 客户虚拟机，一切似乎运行正常。从 Server 2012 和 2012 R2 以及 2019 复制并导入了一些 Server 2012 R2 VM（v5.0）。一切运行良好，至少我是这么认为的。

开始注意到以下问题：Server 2019 上的任何来宾虚拟机都只能在 Hyper-V 管理器中分配给它的一半核心上运行。

从网上的一些研究来看，可能是 VM 版本的问题，所以我将它们全部升级到 v9.0。但问题仍然存在。可能是 VM 设置 HwThreadCountPerCore，但它们都设置为 0。我查看了 NUMA（出于某种原因，可能是某些容量问题）。由于 2 个套接字，有 2 个 NUMA 节点，NumaSpanningEnabled 为真，其他设置对我来说看起来很正常。

如果虚拟机分配了 4 个 vCPU，则该客户机中的任务管理器将显示 2 个核心。如果有 2 个，则将显示 1 个核心。检查该客户机中的设备管理器将显示列出的 4 个处理器，但任务管理器将显示 2 个核心。我检查了 Server 2012 VM，它们似乎在分配的所有核心上运行。我没有 Server 2012 R2，但大多数虚拟机都是 2019。我将虚拟机从 4 个 vCPU 更改为 2 个，并目睹客户机中的核心从 2 个减少到 1 个，然后在设置为 4 时又回到 2 个。

这是侧信道攻击缓解措施吗？根据我的检查，我们所做的所有设置都应该没问题。

  • 具有超线程的 Hyper-V 主机：FeatureSettingsOverride = 72、FeatureSettingsOverrideMask = 3、MinVmVersionForCpuBasedMitigations =“1.0”
  • Hyper-V 客户机：FeatureSettingsOverride = 8264，FeatureSettingsOverrideMask = 3

主机和客户机的 Get-SpeculationControlSettings 输出：

For more information about the output below, please refer to https://support.microsoft.com/help/4074629
Speculation control settings for CVE-2017-5715 [branch target injection]
  Hardware support for branch target injection mitigation is present: True
  Windows OS support for branch target injection mitigation is present: True
  Windows OS support for branch target injection mitigation is enabled: True
Speculation control settings for CVE-2017-5754 [rogue data cache load]
  Hardware is vulnerable to rogue data cache load: False
  Hardware requires kernel VA shadowing: True
  Windows OS support for kernel VA shadow is present: True
  Windows OS support for kernel VA shadow is enabled: True
  Windows OS support for PCID performance optimization is enabled: True [not required for security]
Speculation control settings for CVE-2018-3639 [speculative store bypass]
  Hardware is vulnerable to speculative store bypass: True
  Hardware support for speculative store bypass disable is present: True
  Windows OS support for speculative store bypass disable is present: True
  Windows OS support for speculative store bypass disable is enabled system-wide: True
Speculation control settings for CVE-2018-3620 [L1 terminal fault]
  Hardware is vulnerable to L1 terminal fault: False
Speculation control settings for MDS [microarchitectural data sampling]
  Windows OS support for MDS mitigation is present: True
  Hardware is vulnerable to MDS: False
Speculation control settings for SBDR [shared buffers data read]
  Windows OS support for SBDR mitigation is present: True
  Hardware is vulnerable to SBDR: True
  Windows OS support for SBDR mitigation is enabled: True
Speculation control settings for FBSDP [fill buffer stale data propagator]
  Windows OS support for FBSDP mitigation is present: True
  Hardware is vulnerable to FBSDP: True
  Windows OS support for FBSDP mitigation is enabled: True
Speculation control settings for PSDP [primary stale data propagator]
  Windows OS support for PSDP mitigation is present: True
  Hardware is vulnerable to PSDP: True
  Windows OS support for PSDP mitigation is enabled: True

BTIHardwarePresent                  : True
BTIWindowsSupportPresent            : True
BTIWindowsSupportEnabled            : True
BTIDisabledBySystemPolicy           : False
BTIDisabledByNoHardwareSupport      : False
BTIKernelRetpolineEnabled           : False
BTIKernelImportOptimizationEnabled  : True
RdclHardwareProtectedReported       : True
RdclHardwareProtected               : True
KVAShadowRequired                   : True
KVAShadowWindowsSupportPresent      : True
KVAShadowWindowsSupportEnabled      : True
KVAShadowPcidEnabled                : True
SSBDWindowsSupportPresent           : True
SSBDHardwareVulnerable              : True
SSBDHardwarePresent                 : True
SSBDWindowsSupportEnabledSystemWide : True
L1TFHardwareVulnerable              : False
L1TFWindowsSupportPresent           : True
L1TFWindowsSupportEnabled           : False
L1TFInvalidPteBit                   : 0
L1DFlushSupported                   : True
HvL1tfStatusAvailable               : False
HvL1tfProcessorNotAffected          : False
MDSWindowsSupportPresent            : True
MDSHardwareVulnerable               : False
MDSWindowsSupportEnabled            : True
FBClearWindowsSupportPresent        : True
SBDRSSDPHardwareVulnerable          : True
FBSDPHardwareVulnerable             : True
PSDPHardwareVulnerable              : True
FBClearWindowsSupportEnabled        : True

对于分配了 4 个 vCPU 且在任务管理器中显示 2 个虚拟处理器的 Server 2019 VM，NUMA 页面显示：

  • 处理器： 4
  • NUMA 节点：1
  • 插座： 1
  • 每核硬件线程数：2

每核硬件线程数设置为 0，表示继承。在客户机中，运行 wmic cpu get NumberOfCores,NumberOfLogicalProcessors /Format:List 显示：

wmic cpu get NumberOfCores,NumberOfLogicalProcessors /Format:List
NumberOfCores=2
NumberOfLogicalProcessors=2

此外，Hyper-V 目前正在运行核心调度程序模式。

我不知道这可能是什么。非常感谢您的帮助。

答案1

根据我自己的发现和测试提供这个答案。这似乎是我的环境的解决方案。

如上所述，从历史上看，我们针对虚拟机的侧信道攻击缓解措施是将值设置为超线程禁用值，因为 Hyper-V 虚拟机中没有 HT。

到目前为止，Server 2016 及以上版本引入了核心调度程序，还引入了与 Hyper-V 共享 SMT（超线程），这意味着每个 VM 现在都运行 SMT。

一旦我们将侧信道攻击缓解值更改为与超线程启用值匹配，并重新启动虚拟机，所有分配的 vCPU 都会返回。

有人见过这种情况吗？FeatureSettingsOverride 的值会影响显示和使用的核心数量吗？

相关内容