關於 Hyper-V Hypervisor 排程器類型選項

發行項
10/05/2023

適用於：Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 版本 1709、Windows Server 版本 1803

此文件說明 Hyper-V 預設和建議使用 Hypervisor 排程器類型的重要變更。這些變更會影響安全性和虛擬化效能。虛擬化主機管理員應檢閱並了解此文件介紹的變更和影響，並謹慎評估影響、建議的部署指南以及涉及的風險因素，以便妥善掌握如何在快速變遷的安全性架構中部署和管理 Hyper-V 主機。

重要

目前在多個處理器架構中發現的已知側邊通道安全性弱點，在啟用同時多執行緒 (SMT) 的主機上執行時，惡意客體 VM 可透過舊版 Hypervisor 傳統排程器類型的排程行為利用弱點進行惡意探索。如果惡意探索得逞，惡意工作負載將可觀察其分割區邊界以外的資料。若要降低此類攻擊的風險，您可以將 Hyper-V Hypervisor 設為使用 Hypervisor 核心排程器類型，並重新設定客體 VM。透過採用核心排程器，Hypervisor 會將客體 VM 的 VP 限制在同一實體執行器核心上執行，因此可有效將 VM 的資料存取隔離在其執行所在實體核心的邊界內。這個方法可大幅降低這些側邊通道攻擊，避免 VM 觀察其他分割區的任何成品，無論是根或是客體分割區。因此，Microsoft 正在變更虛擬化主機和客體 VM 的預設和建議組態設定。

背景

從 Windows Server 2016 開始，Hyper-V 會支援虛擬處理器的多種排程和管理方法，也稱為 Hypervisor 排程器類型。所有 Hypervisor 排程器類型的詳細說明可參閱了解和使用 Hyper-V Hypervisor 排程器類型。

注意

新的 Hypervisor 排程器類型最先是與 Windows Server 2016 一同推出，且不支援更早的版本。在 Windows Server 2016 以前的所有 Hyper-V 版本都僅支援傳統排程器。核心排程器的支援最近才發佈。

關於 Hypervisor 排程器類型

本文主要介紹新的 Hypervisor 核心排程器類型與舊版「傳統」排程器的使用差異，以及這些排程器類型如何與對稱式多執行緒 (SMT) 搭配使用。請務必了解核心和傳統排程器之間的差異，以及每個環境如何透過基礎系統處理器上的客體 VM 執行作業。

傳統排程器

傳統排程器是指在整個系統的虛擬處理器 (VP) 上排程工作的公平分享、循環配置方法，包括根 VP 以及屬於客體 VM 的 VP。傳統排程器是 Hyper-V 所有版本使用的預設排程器 (直到 Windows Server 2019 為止，如此處所述)。傳統排程器的效能特性已廣為人知，且經實證可有效支援工作負載的超額訂閱 - 即以合理幅度超額訂閱主機的 VP:LP 比率（取決於虛擬化工作負載的類型、整體資源利用率等）。

在啟用 SMT 的虛擬化主機上執行時，傳統排程器會在屬於核心的每個 SMT 執行緒上分別排程來自任何 VM 的客體 VP。因此，不同的 VM 可以同時在同一個核心上運行 (一個 VM 在一個核心的一個執行緒上執行，而另一個 VM 在另一個執行緒上執行)。

核心排程器

核心排程器利用 SMT 的屬性進行客體工作負載的隔離，這會影響安全性和系統效能。核心排程器會確保將來自 VM 的 VP 排程至同層級 SMT 執行緒上。這項作業採用對稱式執行，因此如果 LP 以兩個為一組，則 VP 就會以兩個為一組排程，且 VM 之間永遠不會共用系統 CPU 核心。

透過在基礎 SMT 組上排程客體 VP，核心排程器為工作負載隔離提供了強大的安全邊界，還可用於減少延遲敏感工作負載的效能變化性。

請注意，為未啟用 SMT 的虛擬機器排程 VP 時，該 VP 在執行時將取用整個核心，且該核心的同層級 SMT 執行緒將保持空閒狀態。這是提供適當工作負載隔離的必要措施，但會影響整體系統效能，特別是當系統 LP 超額訂閱時，即總計 VP:LP 比率超過 1:1。因此，執行客體 VM 且設定不使用每個核心的多個執行緒是次佳的組態。

使用核心排程器的優點

核心排程器具有以下優點：

客體工作負載隔離的強大安全邊界 - 限制客體 VP 只能在基礎實體核心組上執行，從而減少側邊通道窺探攻擊的弱點。
減少工作負載變化 - 大幅降低客體工作負載輸送量變化性，從而提高工作負載的一致性。
在客體虛擬機器中使用 SMT - 在客體虛擬機器中執行的作業系統和應用程式可利用 SMT 行為和程式設計介面 (API) 來跨 SMT 執行緒控制和分配工作，就像非虛擬化執行時一樣。

核心排程器目前在 Azure 虛擬化主機上使用，專門運用其強大的安全邊界和工作負載的低變化性。 Microsoft 認為核心排程器類型應該且將繼續成為大多數虛擬化場景的預設 Hypervisor 排程類型。因此，為了在預設情況下確保我們客戶的安全，Microsoft 現在正在對 Windows Server 2019 執行這項變更。

核心排程器效能對客體工作負載的影響

雖然核心排程器可有效降低特定類別的漏洞風險，但也可能會降低效能。客戶可能會發現其虛擬機器的效能特性存在差異，並影響到虛擬化主機的整體工作負載容量。在核心排程器必須執行非 SMT VP 的情況下，基礎邏輯核心中只會有一個指令流執行，而另一個必須保持空閒。這會限制客體工作負載的主機總容量。

透過遵循此本文件內容的部署指南，可以將這些效能影響降至最小。主機管理員必須仔細考慮具體的虛擬化部署狀況，並在安全風險容忍度、最大工作負載密度、虛擬化主機的過度整合等需求之間取得平衡。

Windows Server 2016 和 Windows Server 2019 預設和建議組態的變更

部署具有最高安全性態勢的 Hyper-V 主機需要使用 Hypervisor 核心排程器類型。為了在預設情況下確保我們客戶的安全，Microsoft 正在變更下列預設和建議設定。

注意

雖然 Windows Server 2016、Windows Server 1709 和 Windows Server 1803 的初始版本中包含排程器類型的 Hypervisor 內部支援，但需要進行更新才能存取組態控制以選擇 Hypervisor 排程器類型。關於這些更新的詳細資訊，請參閱了解和使用 Hyper-V Hypervisor 排程器類型。

虛擬化主機變更

從 Windows Server 2019 開始，Hypervisor 將預設使用核心排程器。
Microsoft 建議您在 Windows Server 2016 上設定核心排程器。 Windows Server 2016 可支援 Hypervisor 核心排程器，但預設選項為傳統排程器。核心排程器是選用項目，且必須由 Hyper-V 主機管理員明確啟用。

虛擬機器組態變更

在 Windows Server 2019 上，使用預設 VM 版本 9.0 建立的新虛擬機器將自動繼承虛擬化主機的 SMT 屬性 (啟用或停用)。換句話說，如果實體主機上已啟用 SMT，則新建立的虛擬機器也將啟用 SMT，並預設繼承主機的 SMT 拓撲，虛擬機器的每個核心的硬體執行緒數與基礎系統相同。這將反映在 VM 的組態中，且 HwThreadCountPerCore = 0，其中 0 表示 VM 應繼承主機的 SMT 設定。
VM 版本為 8.2 或更早版本的現有虛擬機器將保留 HwThreadCountPerCore 的原始 VM 處理器設定，而 8.2 VM 版本客體的預設為 HwThreadCountPerCore = 1。當這些客體在 Windows Server 2019 主機上執行時，其處理方式如下：
1. 如果 VM 的 VP 計數小於或等於 LP 核心數，則排程器會將該 VM 視為非 SMT VM。當客體 VP 在單一 SMT 執行緒上執行時，核心的同層級 SMT 執行緒將處於空閒狀態。這不是最佳狀態，並且會導致整體效能下降。
2. 如果 VM 的 VP 數量多於 LP 內核，則核心排程器會將 VM 視為 SMT VM。但是，VM 將不會觀察到自己是 SMT VM 的其他指示。例如，作業系統或應用程式使用 CPUID 指令或 Windows API 查詢 CPU 拓撲時，不會指出 SMT 已啟用。
當透過 Update-VM 作業將現有 VM 從早期 VM 版本明確更新至版本 9.0 時，VM 將保留 HwThread CounterCore 的目前值。 VM 將不會強制啟用 SMT。
在 Windows Server 2016 上，Microsoft 建議針對客體 VM 啟用 SMT。預設情況下，在 Windows Server 2016 上建立的 VM 將停用 SMT (HwThreadCountPerCore 設定為 1)，除非明確變更。

注意

Windows Server 2016 不支援將 HwThreadCountPerCore 設為 0。

管理虛擬機器 SMT 組態

客體虛擬機器 SMT 組態是以每部 VM 為單位設定。主機管理員可以檢查和配置 VM 的 SMT 配置，從下列選項中進行選取：

將虛擬機器設定為啟用 SMT 執行，可選擇自動繼承主機 SMT 拓撲
將 VM 設定為非 SMT 執行

VM 的 SMT 設定會顯示在 Hyper-V 管理員主控台的 [摘要] 窗格中。若要調整 VM 的 SMT 設定，可以使用 VM 設定或是 PowerShell。

使用 PowerShell 調整 VM SMT 設定

若要為客體虛擬機器組態 SMT 設定，請開啟具有足夠權限的 PowerShell 視窗，然後輸入：

Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore <0, 1, 2>

其中：

0 = 從主機繼承 SMT 拓樸 (Windows Server 2016 上不支援將此設定設為 HwThreadCountPerCore=0)
1 = 非 SMT
值 > 1 = 每個核心所需的 SMT 執行緒數量。不可超過每個核心實體 SMT 執行緒的數量。

若要讀取客體虛擬機器的 SMT 設定，請開啟具有足夠權限的 PowerShell 視窗，然後輸入：

(Get-VMProcessor -VMName <VMName>).HwThreadCountPerCore

請注意，客體 VM 設定若為 HwThreadCountPerCore = 0 則將為客體啟用 SMT，並將向客體公開與基礎虛擬化主機上相同數量的 SMT 執行緒，通常為 2。

客體 VM 可能會在 VM 移動案例中觀察到 CPU 拓撲的變化

在 VM 生命週期事件 (例如即時移轉或儲存和復原作業) 之前和之後，VM 內作業系統和應用程式的主機和 VM 設定可能都會有所變更。在儲存和還原 VM 狀態的作業期間，VM 的 HwThreadCountPerCore 設定和實作值 (即 VM 設定和來源主機組態的運算組合) 都會移轉。 VM 會在目的地主機上繼續使用這些設定執行。當 VM 關機或重啟時，VM 所觀察到的實作值可能會變更。這應該是良性現象，因為作業系統和應用程式層軟體應該將查找 CPU 拓撲資訊作為正常啟動和初始化程式碼流程的一部分。然而，由於在即時移轉或保存/恢復作業期間會略過這些開機時間初始化序列，因此經歷這些狀態轉換的虛擬機器可能會觀察到最初計算的實作值，直到關機並重新啟動為止。

關於非最佳化 VM 組態的警告

當虛擬機器設定的 VP 數量多於主機上的實體核心數量時，將導致非最佳化的組態。 Hypervisor 排程器會將這些 VM 視為 SMT 感知。但是，VM 作業系統和應用程式軟體將接收到顯示 SMT 已停用的CPU 拓撲。偵測到這種情況時，Hyper-V 背景工作處理序會在虛擬化主機上記錄事件，警告主機管理員 VM 組態未處於最佳狀態，並建議為 VM 啟用 SMT。

如何識別非最佳化設定的 VM

若要識別非 SMT VM，您可以在事件檢視器中檢查系統記錄檔中的 Hyper-V 背景工作處理序事件 ID 3498，只要 VM 中的 VP 數量大於實體核心計數，系統就會為 VM 觸發該事件。背景工作處理序事件可以透過事件檢視器或是 PowerShell 取得。

使用 PowerShell 查詢 Hyper-V 背景工作處理序 VM 事件

若要使用 PowerShell 查詢 Hyper-V 背景工作處理序事件識別碼 3498，請在 PowerShell 提示字元輸入下列命令。

Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-Worker"; ID=3498}

客體 SMT 組態對客體作業系統使用 Hypervisor 啟發的影響

Microsoft Hypervisor 提供了多種啟發或提示，客體 VM 中執行的作業系統可以查詢並使用這些啟蒙或提示來觸發最佳化，例如可能有助於提升效能，或以其他方式改善執行虛擬化時處理各種條件的最佳化。最近引進的一項啟發是關於虛擬處理器排程的處理，以及針對惡意探索 SMT 側邊通路攻擊的作業系統使用緩解措施。

注意

Microsoft 建議主機系統管理員為客體 VM 啟用 SMT，以將工作負載效能最佳化。

下面提供了此客體啟發的詳細資訊，但虛擬化主機管理員的關鍵要點是虛擬機器應將 HwThreadCountPerCore 設定為符合主機的實體 SMT 組態。這可讓 Hypervisor 回報沒有非架構核心共用。如此一來，便可啟用任何需要啟發的客體作業系統支援最佳化。在 Windows Server 2019 上，請建立新的 VM，並將預設值保留為 HwThreadCountPerCore (0)。從 Windows Server 2016 主機移轉的舊版 VM 可以更新為 Windows Server 2019 組態版本。完成後，Microsoft 建議設定 HwThreadCountPerCore = 0。在 Windows Server 2016 上，Microsoft 建議設定 HwThreadCountPerCore 以符合主機設定 (通常是 2)。

NoNonArchitecturalCoreSharing 啟發詳細資料

從 Windows Server 2016 開始，Hypervisor 定義了新的啟發來描述其排程 VP 並放置到客體作業系統的處理方式。此啟發的定義位於 Hypervisor 最上層功能規格 v5.0c。

Hypervisor 綜合 CPUID 分葉 CPUID.0x40000004.EAX:18[NoNonArchitecturalCoreSharing = 1] 表示虛擬處理器永遠不會與另一個虛擬處理器共用實體處理器，除了報告為同層級 SMT 執行緒的虛擬處理器。例如，客體 VP 永遠不會在 SMT 執行緒上與根 VP 同時在同一處理器核心上的同層級 SMT 執行緒上執行。這種情況僅在執行虛擬化時才可能出現，因此代表一種非架構 SMT 行為，也具有嚴重的安全性隱患。客體作業系統可以使用 NoNonArchitecturalCoreSharing = 1 來指示啟用最佳化為安全操作，這可能有助於避免設定 STIBP 的效能負擔。

在特定組態中，Hypervisor 不會指示 NoNonArchitecturalCoreSharing = 1。例如，如果主機啟用 SMT 並設定使用 Hypervisor 傳統排程器，則 NoNonArchitecturalCoreSharing 將為 0。這可能會導致已啟發的客體無法啟用特定最佳化。因此，Microsoft 建議使用 SMT 的主機管理員採用 Hypervisor 核心排程器，並確保將虛擬機器設定為繼承主機的 SMT 組態，以確保最佳的工作負載效能。

摘要

安全性威脅環境仍在持續發展。為了在預設情況下確保我們的客戶安全，Microsoft 正在變更從Windows Server 2019 Hyper-V 開始的 Hypervisor 和虛擬機器預設組態，並為使用 Windows Server 2016 Hyper-V 的客戶提供更新的指引和建議。虛擬化主機系統管理員應該：

閱讀並了解本文件提供的指導方針
仔細評估和調整虛擬化部署，以確保其滿足其獨特需求的安全性、效能、虛擬化密度以及工作負載回應性目標
考慮重新設定現有的 Windows Server 2016 Hyper-V 主機，以運用 Hypervisor 核心排程器提供的強大安全性優勢
更新現有的非 SMT 虛擬機器，藉此降低 VP 隔離為解決硬體安全漏洞所施加排程限制造成的效能影響