Freigeben über

Informationen zur Auswahl der Hypervisor-Scheduler-Typen in Hyper-V

In diesem Dokument werden wichtige Änderungen an der standardmäßigen und empfohlenen Verwendung von Hypervisor-Scheduler-Typen in Hyper-V beschrieben. Diese Änderungen wirken sich sowohl auf die Systemsicherheit als auch auf die Virtualisierungsleistung aus. Administratoren von Virtualisierungshosts sollten die in diesem Dokument beschriebenen Änderungen und Auswirkungen lesen und verstehen und die Auswirkungen, empfohlenen Bereitstellungsanleitungen und Risikofaktoren sorgfältig bewerten, um besser zu verstehen, wie Hyper-V-Hosts angesichts der sich schnell verändernden Sicherheitslandschaft bereitgestellt und verwaltet werden.

Wichtig

Derzeit bekannte Seitenkanal-Sicherheitslücken, die in Architekturen mit mehreren Prozessoren gesichtet werden, könnten von einer schädlichen Gast-VM durch das Planungsverhalten des klassischen Planertyps des Legacy-Hypervisors ausgenutzt werden, wenn er auf Hosts mit aktiviertem gleichzeitigen Multithreading (SMT) ausgeführt wird. Bei erfolgreicher Ausnutzung kann eine schädliche Workload Daten außerhalb der Partitionsgrenze beobachten. Diese Art von Angriffen kann abgeschwächt werden, indem der Hyper-V-Hypervisor so konfiguriert wird, dass er den Hypervisor-Kernplanertyp verwendet und Gast-VMs neu konfiguriert. Mit dem Kernplaner schränkt der Hypervisor die Ausführung der VPs einer Gast-VM auf demselben physischen Prozessorkern ein, wodurch die Fähigkeit der VM, auf Daten zuzugreifen, stark auf die Grenzen des physischen Kerns beschränkt wird, auf dem er ausgeführt wird. Dies ist eine hochwirksame Schutzmaßnahme gegen diese Seitenkanalangriffe, die verhindert, dass die VM Artefakte von anderen Partitionen beobachtet, sei es die Stamm- oder eine andere Gastpartition. Daher ändert Microsoft die standardmäßigen und empfohlenen Konfigurationseinstellungen für Virtualisierungshosts und Gast-VMs.

Hintergrund

Ab Windows Server 2016 unterstützt Hyper-V verschiedene Methoden zum Planen und Verwalten virtueller Prozessoren, die als Hypervisor-Scheduler-Typen bezeichnet werden. Eine detaillierte Beschreibung aller Hypervisor-Scheduler-Typen finden Sie unter Grundlegendes und Verwenden von Hypervisor-Scheduler-Typen in Hyper-V.

Hinweis

Neue Hypervisor-Scheduler-Typen wurden erstmals mit Windows Server 2016 eingeführt und sind in früheren Releases nicht verfügbar. Alle Hyper-V-Versionen vor Windows Server 2016 unterstützen nur den klassischen Planer. Die Unterstützung für den Kernplaner wurde erst kürzlich veröffentlicht.

Informationen über Hypervisor-Scheduler-Typen

Dieser Artikel setzt den Schwerpunkt insbesondere auf die Verwendung des neuen Hypervisor-Kernplanertyps im Vergleich zum alten „klassischen“ Planer und wie sich diese Planertypen mit der Verwendung von symmetrischem Multithreading, oder SMT, überschneiden. Es ist wichtig, die Unterschiede zwischen den Kernplanern und klassischen Planern zu verstehen und wie jeder die Arbeit von Gast-VMs auf die zugrunde liegenden Systemprozessoren platziert.

Der klassische Planer

Der klassische Planer bezieht sich auf die Fair-Share-Methode „Roundrobin“ zum Planen von Arbeiten an virtuellen Prozessoren (VPs) im gesamten System – einschließlich Stamm-VPs sowie VPs, die zu Gast-VMs gehören. Der klassische Planer war der standardmäßige Planertyp, der in allen Versionen von Hyper-V verwendet wurde (bis Windows Server 2019, wie hier beschrieben). Die Leistungsmerkmale des klassischen Planers sind gut verstanden, und der klassische Planer unterstützt nachweislich ein Überabonnement von Workloads, d. h. ein Überabonnement des VP:LP-Verhältnisses des Hosts mit angemessenem Abstand (abhängig von den Arten von Workloads, die virtualisiert werden, der Gesamtressourcennutzung usw.).

Bei Ausführung auf einem Virtualisierungshost mit aktiviertem SMT plant der klassische Planer unabhängig voneinander Gast-VPs von jeder VM auf jedem SMT-Thread, der zu einem Kern gehört. Daher können verschiedene VMs gleichzeitig auf demselben Kern ausgeführt werden (eine VM wird auf einem Thread eines Kerns ausgeführt, während eine andere VM im anderen Thread ausgeführt wird).

Der Kernplaner

Der Kernplaner nutzt die Eigenschaften von SMT, um die Isolation von Gast-Workloads bereitzustellen, was sich sowohl auf die Sicherheit als auch auf die Systemleistung auswirkt. Der Kernplaner stellt sicher, dass VPs von einer VM für gleichgeordnete SMT-Threads geplant werden. Dies erfolgt symmetrisch, sodass VPs, wenn sich LPs in Zweiergruppen befinden, VPs in Zweiergruppen geplant werden, und ein System-CPU-Kern nie zwischen VMs freigegeben wird.

Durch das Planen von Gast-VPs auf zugrunde liegenden SMT-Paaren bietet der Kernplaner eine starke Sicherheitsgrenze für die Workload-Isolation und kann auch verwendet werden, um die Leistungsvariabilität für latenzempfindliche Workloads zu reduzieren.

Beachten Sie, dass, wenn der VP für einen virtuellen Computer ohne aktiviertes SMT geplant ist, dieser VP bei seiner Ausführung den gesamten Kern verbraucht und der gleichgeordnete SMT-Thread des Kerns im Leerlauf bleibt. Dies ist erforderlich, um die richtige Workload-Isolierung bereitzustellen, wirkt sich jedoch auf die Gesamtsystemleistung aus, insbesondere wenn die System-LPs übermäßig abonniert werden – d. h. wenn das Gesamt-VP:LP-Verhältnis 1:1 überschreitet. Daher ist die Ausführung von Gast-VMs, die ohne mehrere Threads pro Kern konfiguriert sind, eine suboptimale Konfiguration.

Vorteile der Verwendung des Kernplaners

Der Kernplaner bietet die folgenden Vorteile:

  • Eine starke Sicherheitsgrenze für die Isolation von Gast-Workloads – Gast-VPs sind darauf beschränkt, auf zugrunde liegenden physischen Kernpaaren ausgeführt zu werden, wodurch die Anfälligkeit für Snooping-Angriffe auf Seitenkanälen verringert wird.

  • Reduzierte Workload-Variabilität – Die Durchsatzvariabilität von Gast-Workloads wird erheblich reduziert, wodurch eine größere Workload-Konsistenz erreicht wird.

  • Verwendung von SMT in Gast-VMs – Das Betriebssystem und die Anwendungen, die auf der Gast-VM ausgeführt werden, können das SMT-Verhalten und die Programmierschnittstellen (APIs) verwenden, um die Arbeit auf SMT-Threads zu steuern und zu verteilen, genau wie bei nicht virtualisierter Ausführung.

Der Kernplaner wird derzeit auf Azure-Virtualisierungshosts verwendet, insbesondere, um von der starken Sicherheitsgrenze und der geringen Workload-Variabilität zu profitieren. Microsoft ist der Ansicht, dass der Kernplanertyp der standardmäßige Hypervisor-Planertyp für die meisten Virtualisierungsszenarien sein sollte und auch weiterhin sein wird. Um sicherzustellen, dass unsere Kunden standardmäßig sicher sind, nimmt Microsoft diese Änderung jetzt für Windows Server 2019 vor.

Auswirkungen auf die Leistung des Kernplaners auf Gast-Workloads

Der Kernplaner ist zwar erforderlich, um bestimmte Klassen von Sicherheitsrisiken effektiv zu mindern, kann aber auch die Leistung beeinträchtigen. Kunden können einen Unterschied in den Leistungsmerkmalen ihrer VMs und Auswirkungen auf die Gesamtarbeitslastkapazität ihrer Virtualisierungshosts feststellen. In Fällen, in denen der Kernplaner einen Nicht-SMT-VP ausführen muss, wird nur einer der Befehlsströme im zugrunde liegenden logischen Kern ausgeführt, während der andere im Leerlauf bleiben muss. Dadurch wird die Gesamtkapazität des Hosts für Gast-Workloads begrenzt.

Diese Leistungseinbußen können minimiert werden, indem Sie die Bereitstellungsanleitung in diesem Dokument befolgen. Host-Administratoren müssen ihre spezifischen Virtualisierungsbereitstellungsszenarien sorgfältig prüfen und ihre Toleranz gegenüber Sicherheitsrisiken gegen die Notwendigkeit einer maximalen Workload-Dichte, einer Überkonsolidierung von Virtualisierungshosts usw. abwägen.

Die Bereitstellung von Hyper-V-Hosts mit dem maximalen Sicherheitsstatus erfordert die Verwendung des Hypervisor-Kernplanertyps. Um sicherzustellen, dass unsere Kunden standardmäßig sicher sind, ändert Microsoft die folgenden standardmäßigen und empfohlenen Einstellungen.

Hinweis

Während die interne Unterstützung des Hypervisors für die Planertypen in der ersten Version von Windows Server 2016, Windows Server 1709 und Windows Server 1803 enthalten war, sind Updates erforderlich, um auf die Konfigurationssteuerung zuzugreifen, die die Auswahl des Hypervisor-Scheduler-Typs ermöglicht. Weitere Informationen zu diesen Updates finden Sie unter Grundlegendes und Verwenden von Hypervisor-Scheduler-Typen in Hyper-V.

Änderungen des Virtualisierungshosts

  • Der Hypervisor verwendet standardmäßig den Kernplaner ab Windows Server 2019.

  • Microsoft empfiehlt die Konfiguration des Kernplaners auf Windows Server 2016. Der Hypervisor-Kernplanertyp wird in Windows Server 2016 unterstützt, der Standardwert ist jedoch der klassische Planer. Der Kernplaner ist optional und muss vom Hyper-V-Hostadministrator explizit aktiviert werden.

Änderungen an der Konfiguration virtueller Computer

  • Auf Windows Server 2019 erben neue virtuelle Computer, die mit der Standard-VM-Version 9.0 erstellt wurden, automatisch die SMT-Eigenschaften (aktiviert oder deaktiviert) des Virtualisierungshosts. Das heißt, wenn SMT auf dem physischen Host aktiviert ist, wird SMT auch für neu erstellte VMs aktiviert und erbt standardmäßig die SMT-Topologie des Hosts, wobei die VM dieselbe Anzahl von Hardware-Threads pro Kern wie das zugrunde liegende System hat. Dies spiegelt sich in der Konfiguration der VM mit HwThreadCountPerCore = 0 wider, wobei 0 angibt, dass die VM die SMT-Einstellungen des Hosts erben soll.

  • Vorhandene virtuelle Computer mit einer VM-Version von 8.2 oder früher behalten ihre ursprüngliche VM-Prozessoreinstellung für HwThreadCountPerCore bei, und die Standardeinstellung für Gäste der VM-Version 8.2 lautet HwThreadCountPerCore = 1. Wenn diese Gäste auf einem Windows Server 2019-Host laufen, werden sie wie folgt behandelt:

    1. Wenn die VM eine VP-Anzahl hat, die kleiner oder gleich der Anzahl der LP-Kerne ist, wird die VM vom Kernplaner als Nicht-SMT-VM behandelt. Wenn der Gast-VP in einem einzelnen SMT-Thread ausgeführt wird, wird der gleichgeordnete SMT-Thread des Kerns im Leerlauf ausgeführt. Dies ist nicht optimal und führt zu einem Gesamtleistungsverlust.

    2. Wenn die VM über mehr VPs als LP-Kerne verfügt, wird die VM vom Kernplaner als SMT-VM behandelt. Andere Hinweise darauf, dass es sich um eine SMT-VM handelt, werden von der VM jedoch nicht beachtet. Die Verwendung der CPUID-Anweisung oder der Windows-APIs zum Abfragen der CPU-Topologie durch das Betriebssystem oder die Anwendungen gibt beispielsweise nicht an, dass SMT aktiviert ist.

  • Wenn eine vorhandene VM explizit von früheren VM-Versionen auf Version 9.0 durch den Update-VM-Vorgang aktualisiert wird, behält die VM ihren aktuellen Wert für HwThreadCountPerCore bei. Für die VM ist SMT nicht erzwingend aktiviert.

  • Auf Windows Server 2016 empfiehlt Microsoft, SMT für Gast-VMs zu aktivieren. Standardmäßig wäre SMT für auf Windows Server 2016 erstellte VMs deaktiviert, d. h. HwThreadCountPerCore ist auf 1 festgelegt, sofern nicht ausdrücklich geändert.

Hinweis

Windows Server 2016 unterstützt das Festlegen von HwThreadCountPerCore auf 0 nicht.

Verwalten der SMT-Konfiguration virtueller Computer

Die SMT-Konfiguration der Gast-VM wird auf VM-Basis festgelegt. Der Hostadministrator kann die SMT-Konfiguration einer VM überprüfen und konfigurieren, um aus den folgenden Optionen auszuwählen:

  1. Konfigurieren von VMs für die Ausführung als SMT-fähig, optional automatisches Erben der Host-SMT-Topologie

  2. Konfigurieren von VMs für die Ausführung als Nicht-SMT

Die SMT-Konfiguration für eine VM wird in den Zusammenfassungsbereichen in der Hyper-V-Manager-Konsole angezeigt. Das Konfigurieren der SMT-Einstellungen einer VM kann mithilfe der VM-Einstellungen oder mit PowerShell erfolgen.

Konfigurieren von VM-SMT-Einstellungen mithilfe von PowerShell

Um die SMT-Einstellungen für eine Gast-VM zu konfigurieren, öffnen Sie ein PowerShell-Fenster mit ausreichenden Berechtigungen und geben Sie Folgendes ein:

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

Hierbei gilt:

  • 0 = Erben der SMT-Topologie vom Host (diese Einstellung von HwThreadCountPerCore=0 wird auf Windows Server 2016 nicht unterstützt)

  • 1 = Nicht-SMT

  • Werte > 1 = die gewünschte Anzahl von SMT-Threads pro Kern. Darf die Anzahl der physischen SMT-Threads pro Kern nicht überschreiten.

Um die SMT-Einstellungen für eine Gast-VM zu lesen, öffnen Sie ein PowerShell-Fenster mit ausreichenden Berechtigungen und geben Sie Folgendes ein:

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

Beachten Sie, dass Gast-VMs, die mit HwThreadCountPerCore = 0 konfiguriert sind, angeben, dass SMT für den Gast aktiviert wird, und dem Gast die gleiche Anzahl von SMT-Threads wie auf dem zugrunde liegenden Virtualisierungshost verfügbar machen, in der Regel 2.

Gast-VMs können Änderungen an der CPU-Topologie in VM-Mobilitätsszenarien beobachten

Das Betriebssystem und die Anwendungen in einer VM können vor und nach VM-Lebenszyklusereignissen wie Livemigration oder Speicher- und Wiederherstellungsvorgängen Änderungen an den Host- und VM-Einstellungen sehen. Während eines Vorgangs, bei dem der VM-Status gespeichert und wiederhergestellt wird, werden sowohl die Einstellung HwThreadCountPerCore der VM als auch der realisierte Wert (d. h. die berechnete Kombination aus der Einstellung der VM und der Konfiguration des Quellhosts) migriert. Die VM wird mit diesen Einstellungen auf dem Zielhost weiterhin ausgeführt. An dem Punkt, an dem die VM heruntergefahren und neu gestartet wird, ändert sich möglicherweise der realisierte Wert, der von der VM beobachtet wird. Dies sollte unbedenklich sein, da Software auf Betriebssystem- und Anwendungsebene im Rahmen ihrer normalen Start- und Initialisierungscodeflüsse nach CPU-Topologieinformationen suchen sollte. Da diese Startzeitinitialisierungssequenzen jedoch während der Livemigration oder bei Speicher-/Wiederherstellungsvorgängen übersprungen werden, können VMs, die diese Zustandsübergänge durchlaufen, den ursprünglich berechneten realisierten Wert beobachten, bis sie heruntergefahren und neu gestartet werden.

Warnungen zu nicht optimalen VM-Konfigurationen

Virtuelle Computer, die mit mehr VPs konfiguriert sind, als physische Kerne auf dem Host vorhanden sind, führen zu einer nicht optimalen Konfiguration. Der Hypervisor-Scheduler behandelt diese VMs so, als wären sie SMT-fähig. Dem Betriebssystem und der Anwendungssoftware in der VM wird jedoch eine CPU-Topologie präsentiert, die zeigt, dass SMT deaktiviert ist. Wenn diese Bedingung erkannt wird, protokolliert der Hyper-V-Workerprozess ein Ereignis auf dem Virtualisierungshost und warnt den Hostadministrator, dass die VM-Konfiguration nicht optimal ist, und empfiehlt, SMT für die VM zu aktivieren.

Identifizieren nicht optimal konfigurierter VMs

Sie können Nicht-SMT-VMs identifizieren, indem Sie das Systemprotokoll in der Ereignisanzeige für die Ereignis-ID 3498 des Hyper-V-Workerprozesses untersuchen, die für eine VM immer dann ausgelöst wird, wenn die Anzahl der VPs in der VM größer als die Anzahl der physischen Kerne ist. Workerprozess-Ereignisse können über die Ereignisanzeige oder über PowerShell abgerufen werden.

Abfragen des VM-Ereignisses des Hyper-V-Workerprozesses mithilfe von PowerShell

Um die Ereignis-ID des 3498 Hyper-V-Workerprozesses mithilfe von PowerShell abzufragen, geben Sie die folgenden Befehle an einer PowerShell-Eingabeaufforderung ein.

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

Auswirkungen der Gast-SMT-Konfiguration auf die Verwendung von Hypervisor-Aufklärungen für Gastbetriebssysteme

Der Microsoft-Hypervisor bietet mehrere Aufklärungen oder Hinweise, die das Betriebssystem, das in einer Gast-VM ausgeführt wird, abfragen und verwenden kann, um Optimierungen auszulösen, z. B. solche, die der Leistung zugute kommen oder anderweitig die Handhabung verschiedener Bedingungen bei der virtuellen Ausführung verbessern können. Eine kürzlich eingeführte Aufklärung betrifft den Umgang mit der Planung virtueller Prozessoren und die Verwendung von Betriebssystemminderungen für Seitenkanalangriffe, die SMT missbrauchen.

Hinweis

Microsoft empfiehlt, dass Hostadministratoren SMT für Gast-VMs aktivieren, um die Workload-Leistung zu optimieren.

Die Details dieser Gastaufklärung finden Sie weiter unten. Die wichtigste Erkenntnis für Administratoren von Virtualisierungshosts ist jedoch, dass HwThreadCountPerCore auf virtuellen Computern so konfiguriert sein sollte, dass es mit der physischen SMT-Konfiguration des Hosts übereinstimmt. Dadurch kann der Hypervisor melden, dass keine Nicht-Architekturkernfreigabe vorhanden ist. Daher kann jedes Gastbetriebssystem aktiviert werden, das Optimierungen unterstützt, die die Aufklärung erfordern. Erstellen Sie auf Windows Server 2019 neue VMs und behalten Sie den Standardwert von HwThreadCountPerCore (0) bei. Ältere VMs, die von Windows Server 2016-Hosts migriert wurden, können auf die Konfigurationsversion von Windows Server 2019 aktualisiert werden. Danach empfiehlt Microsoft, HwThreadCountPerCore = 0 festzulegen. Auf Windows Server 2016 empfiehlt Microsoft, HwThreadCountPerCore so festzulegen, dass er der Hostkonfiguration entspricht (in der Regel 2).

Aufklärungsdetails zu NoNonArchitecturalCoreSharing

Ab Windows Server 2016 definiert der Hypervisor eine neue Aufklärung, um den Umgang mit der VP-Planung und Platzierung für das Gastbetriebssystem zu beschreiben. Diese Aufklärung ist in der Hypervisor-Funktionsspezifikation der obersten Ebene v5.0c definiert.

Das synthetische CPUID-Blatt des Hypervisors CPUID.0x40000004.EAX:18[NoNonArchitecturalCoreSharing = 1] gibt an, dass ein virtueller Prozessor niemals einen physischen Kern mit einem anderen virtuellen Prozessor teilt, mit Ausnahme von virtuellen Prozessoren, die als gleichgeordnete SMT-Threads gemeldet werden. Beispielsweise wird ein Gast-VP nie in einem SMT-Thread zusammen mit einem Stamm-VP ausgeführt, der gleichzeitig in einem gleichgeordneten SMT-Thread auf demselben Prozessorkern ausgeführt wird. Diese Bedingung ist nur möglich, wenn sie virtualisiert ausgeführt wird, und stellt somit ein nicht architektonisches SMT-Verhalten dar, das auch schwerwiegende Auswirkungen auf die Sicherheit hat. Das Gastbetriebssystem kann NoNonArchitecturalCoreSharing = 1 als Hinweis verwenden, dass Optimierungen sicher aktiviert werden können, wodurch der Leistungsaufwand beim Festlegen von STIBP vermieden werden kann.

In bestimmten Konfigurationen gibt der Hypervisor nicht an, dass NoNonArchitecturalCoreSharing = 1 ist. Beispiel: Wenn auf einem Host SMT aktiviert ist und für die Verwendung des klassischen Hypervisor-Schedulers konfiguriert ist, ist NoNonArchitecturalCoreSharing 0. Dies kann aufgeklärte Gäste daran hindern, bestimmte Optimierungen zu aktivieren. Daher empfiehlt Microsoft, dass sich Hostadministratoren, die SMT verwenden, auf den Hypervisor-Kernplaner verlassen und sicherstellen, dass virtuelle Computer so konfiguriert sind, dass sie ihre SMT-Konfiguration vom Host erben, um eine optimale Workload-Leistung sicherzustellen.

Zusammenfassung

Die Sicherheitsbedrohungen entwickeln sich weiter. Um sicherzustellen, dass unsere Kunden standardmäßig sicher sind, ändert Microsoft die Standardkonfiguration für den Hypervisor und die virtuellen Computer ab Windows Server 2019 Hyper-V und stellt aktualisierte Anleitungen und Empfehlungen für Kunden bereit, die Windows Server 2016 Hyper-V ausführen. Administratoren von Virtualisierungshosts sollten Folgendes tun:

  • Lesen und Verstehen der Anleitungen in diesem Dokument

  • Sorgfältiges Auswerten und Anpassen der Virtualisierungsbereitstellungen, um sicherzustellen, dass sie die Ziele für Sicherheit, Leistung, Virtualisierungsdichte und Workload-Reaktionsfähigkeit für ihre individuellen Anforderungen erfüllen

  • Erwägen der Neukonfiguration vorhandener Windows Server 2016 Hyper-V-Hosts, um die starken Sicherheitsvorteile zu nutzen, die der Hypervisor-Kernplaner bietet

  • Aktualisieren vorhandener Nicht-SMT-VMs, um die Auswirkungen auf die Leistung zu verringern, die durch die VP-Isolation zur Lösung von Hardwaresicherheitsrisiken verursacht werden