Informacje o Hyper-V wyboru typu harmonogramu funkcji hypervisor

Dokument ten opisuje ważne zmiany w domyślnym i zalecanym użyciu typów harmonogramów hypervisora w Hyper-V. Te zmiany wpływają zarówno na bezpieczeństwo systemu, jak i wydajność wirtualizacji. Administratorzy hostów wirtualizacji powinni przejrzeć i zrozumieć zmiany i implikacje opisane w tym dokumencie, a także dokładnie ocenić wpływ, sugerowane wskazówki dotyczące wdrażania i czynniki ryzyka, aby jak najlepiej zrozumieć, jak wdrażać hosty Hyper-V i zarządzać nimi w obliczu szybko zmieniającego się krajobrazu zabezpieczeń.

Background

Począwszy od systemu Windows Server 2016, Hyper-V obsługuje kilka metod planowania procesorów wirtualnych i zarządzania nimi, nazywanych typami harmonogramu funkcji hypervisor. Szczegółowy opis wszystkich typów harmonogramów funkcji hypervisor można znaleźć w temacie Understanding and using Hyper-V hypervisor scheduler types (Opis i używanie typów harmonogramów funkcji hypervisor).

Informacje o typach mechanizmów planowania hypervisora

Ten artykuł koncentruje się szczególnie na użyciu nowego typu głównego harmonogramu hypervisora w porównaniu ze starszym harmonogramem "klasycznym" oraz tym, jak te typy harmonogramu łączą się z użyciem symetrycznego wielowątkowania (SMT). Ważne jest, aby zrozumieć różnice między zarządcami rdzeni i klasycznymi oraz sposób, w jaki każdy z nich przydziela zadania z maszyn wirtualnych gościa na procesorach bazowych systemu.

Klasyczny harmonogram

Klasyczny harmonogram odnosi się do metody sprawiedliwego podziału, okrężnego przydzielania zadań na procesorach wirtualnych (VPs) w systemie — w tym głównych procesorów wirtualnych (VPs) oraz maszyn wirtualnych gościa. Klasyczny harmonogram był domyślnym typem harmonogramu używanym we wszystkich wersjach Hyper-V (do systemu Windows Server 2019, zgodnie z opisem w niniejszym dokumencie). Cechy wydajności tradycyjnego systemu planowania są dobrze znane, a tradycyjny system planowania został ukazany jako zdolny do obsługi nadmiernego obciążenia — czyli nadmiernego stosunku VP do LP hosta z rozsądną granicą (w zależności od typów zwirtualizowanych zadań, ogólnego wykorzystania zasobów itp.).

Po uruchomieniu na hoście wirtualizacji z włączoną funkcją SMT klasyczny harmonogram będzie planował maszyny wirtualne gościa z dowolnej maszyny wirtualnej na każdym wątku SMT należącym do rdzenia niezależnie. W związku z tym różne maszyny wirtualne mogą być uruchomione na tym samym rdzeniu w tym samym czasie (jedna maszyna wirtualna uruchomiona w jednym wątku rdzenia, podczas gdy inna maszyna wirtualna jest uruchomiona w drugim wątku).

Podstawowy harmonogram

Podstawowy harmonogram wykorzystuje właściwości protokołu SMT w celu zapewnienia izolacji obciążeń gościa, co wpływa zarówno na bezpieczeństwo, jak i wydajność systemu. Podstawowy harmonogram zapewnia, że wątki z maszyny wirtualnej są przydzielane na powiązane wątki SMT. Jest to wykonywane symetrycznie, aby jeśli partycje logiczne (LP) znajdują się w grupach dwóch, wirtualne procesy (VP) były zaplanowane w grupach dwóch, a rdzeń CPU nigdy nie był współużytkowany między maszynami wirtualnymi.

Planując wirtualne procesory gościa na bazowych parach SMT, harmonogram rdzenia oferuje silną granicę bezpieczeństwa dla izolacji obciążeń, a także może być używany do zmniejszenia zmienności wydajności w przypadku obciążeń wrażliwych na opóźnienia.

Należy pamiętać, że kiedy wirtualny procesor (VP) jest zaplanowany na maszynę wirtualną bez włączonej technologii SMT, ten VP będzie zużywać cały rdzeń podczas działania, a równoległy wątek SMT rdzenia pozostanie bezczynny. Jest to konieczne, aby zapewnić poprawną izolację obciążenia, ale wpływa na ogólną wydajność systemu, zwłaszcza gdy logiczne procesory systemu są nadmiernie obciążone — to znaczy, gdy całkowity stosunek VP:LP przekracza 1:1. W związku z tym uruchamianie maszyn wirtualnych gości skonfigurowanych bez wielu wątków na rdzeń procesora jest nieoptymalną konfiguracją.

Zalety korzystania z podstawowego harmonogramu

Podstawowy harmonogram oferuje następujące korzyści:

• Silna granica bezpieczeństwa dla izolacji obciążenia gości — maszyny wirtualne gości są ograniczone do działania na podstawowych parach rdzeni fizycznych, co zmniejsza podatność na ataki typu podsłuch kanału bocznego.

• Zmniejszona zmienność obciążenia – Zmienność wydajności obciążenia gości została znacząco zredukowana, co zapewnia większą spójność w obciążeniu.

• Korzystanie z protokołu SMT na maszynach wirtualnych gościa — system operacyjny i aplikacje działające na maszynie wirtualnej gościa mogą używać interfejsów programowania i zachowania SMT do kontrolowania i dystrybuowania pracy między wątkami SMT, tak jak w przypadku uruchamiania niezwirtualizowanego.

Podstawowy planista jest obecnie używany na hostach wirtualizacji platformy Azure, w szczególności w celu korzystania z silnej granicy zabezpieczeń i niskiej zmienności obciążenia. Firma Microsoft uważa, że typ głównego harmonogramu powinien być i nadal będzie domyślnym typem planowania funkcji hypervisor dla większości scenariuszy wirtualizacji. W związku z tym, aby zapewnić, że nasi klienci są domyślnie bezpieczni, firma Microsoft wprowadza tę zmianę dla systemu Windows Server 2019 teraz.

Wpływ wydajności harmonogramu rdzeni na obciążenia maszyn wirtualnych

Chociaż wymagane jest skuteczne ograniczenie niektórych klas luk w zabezpieczeniach, podstawowy harmonogram może również potencjalnie zmniejszyć wydajność. Klienci mogą zauważyć różnice w charakterystykach wydajnościowych swoich maszyn wirtualnych oraz związany z tym wpływ na zdolność obciążeniową ich hostów wirtualizacyjnych. W przypadkach, gdy harmonogram rdzenia musi uruchamiać VP, który nie korzysta z technologii SMT, tylko jeden strumień instrukcji w bazowym rdzeniu logicznym jest wykonywany, podczas gdy drugi musi pozostać bezczynny. Spowoduje to ograniczenie całkowitej pojemności hosta dla obciążeń gościa.

Te wpływy na wydajność można zminimalizować, postępując zgodnie ze wskazówkami dotyczącymi wdrażania w tym dokumencie. Administratorzy hostów muszą dokładnie rozważyć swoje konkretne scenariusze wdrażania wirtualizacji i zrównoważyć ich tolerancję dla ryzyka zabezpieczeń przed koniecznością uzyskania maksymalnej gęstości obciążenia, nadmiernej konsolidacji hostów wirtualizacji itp.

Zmiany domyślnych i zalecanych konfiguracji dla systemów Windows Server 2016 i Windows Server 2019

Wdrażanie hostów Hyper-V z maksymalnym stanem zabezpieczeń wymaga użycia typu harmonogramu podstawowego funkcji hypervisor. Aby zapewnić, że nasi klienci są domyślnie bezpieczni, firma Microsoft zmienia następujące ustawienia domyślne i zalecane.

Zmiany hosta wirtualizacji

• Funkcja hypervisor będzie domyślnie używać podstawowego harmonogramu począwszy od systemu Windows Server 2019.

• Firma Microsoft zaleca skonfigurowanie podstawowego harmonogramu w systemie Windows Server 2016. Typ harmonogramu podstawowego funkcji hypervisor jest obsługiwany w systemie Windows Server 2016, jednak domyślnym typem jest klasyczny harmonogram. Podstawowy harmonogram jest opcjonalny i musi być jawnie włączony przez administratora hosta Hyper-V.

Zmiany konfiguracji maszyny wirtualnej

• W systemie Windows Server 2019 nowe maszyny wirtualne utworzone przy użyciu domyślnej maszyny wirtualnej w wersji 9.0 będą automatycznie dziedziczyć właściwości SMT (włączone lub wyłączone) hosta wirtualizacji. Oznacza to, że jeśli protokół SMT jest włączony na hoście fizycznym, nowo utworzone maszyny wirtualne będą również miały włączoną funkcję SMT i odziedziczą topologię SMT hosta domyślnie, a maszyna wirtualna ma taką samą liczbę wątków sprzętowych na rdzeń, co podstawowy system. Zostanie to odzwierciedlone w konfiguracji maszyny wirtualnej z HwThreadCountPerCore = 0, gdzie 0 wskazuje, że maszyna wirtualna powinna dziedziczyć ustawienia SMT hosta.

• Istniejące maszyny wirtualne z maszyną wirtualną w wersji 8.2 lub starszej zachowają oryginalne ustawienie procesora maszyny wirtualnej dla HwThreadCountPerCore, a ustawieniem domyślnym dla gości wersji maszyny wirtualnej 8.2 jest HwThreadCountPerCore = 1. W przypadku uruchomienia tych gości na hoście z systemem Windows Server 2019, będą oni traktowani w następujący sposób:

  1. Jeśli maszyna wirtualna ma liczbę VP, która jest mniejsza lub równa liczbie rdzeni LP, zostanie potraktowana jako maszyna wirtualna bez SMT przez harmonogram rdzenia. Gdy instancja maszyny wirtualnej działa na jednym wątku SMT, równoległy wątek SMT rdzenia będzie bezczynny. Nie jest to optymalne i spowoduje ogólną utratę wydajności.

  2. Jeśli maszyna wirtualna ma więcej procesorów wirtualnych niż rdzeni LP, planista rdzenia potraktuje ją jako maszynę SMT. Jednak maszyna wirtualna nie będzie dostrzegać innych sygnałów, że jest to maszyna wirtualna SMT. Na przykład użycie instrukcji CPUID lub interfejsów API systemu Windows do wykonywania zapytań dotyczących toplogii procesora CPU przez system operacyjny lub aplikacje nie będą wskazywać, że protokół SMT jest włączony.

• Jeśli istniejąca maszyna wirtualna zostanie jawnie zaktualizowana z wersji maszyny wirtualnej eariler do wersji 9.0 za pomocą operacji Update-VM, maszyna wirtualna zachowa bieżącą wartość HwThreadCountPerCore. Maszyna wirtualna nie będzie mieć włączonej wymuszonej obsługi protokołu SMT.

• W systemie Windows Server 2016 firma Microsoft zaleca włączenie protokołu SMT dla maszyn wirtualnych gościa. Domyślnie maszyny wirtualne utworzone w systemie Windows Server 2016 miałyby wyłączoną funkcję SMT, czyli HwThreadCountPerCore jest ustawiona na 1, chyba że jawnie zmieniono.

Zarządzanie konfiguracją SMT maszyny wirtualnej

Konfiguracja protokołu SMT maszyny wirtualnej gościa jest ustawiana dla poszczególnych maszyn wirtualnych. Administrator hosta może sprawdzić i skonfigurować konfigurację smT maszyny wirtualnej, aby wybrać spośród następujących opcji:

1. Konfigurowanie maszyn wirtualnych do uruchamiania z włączonym SMT, z opcją dziedziczenia topologii SMT hosta automatycznie.

2. Konfigurowanie maszyn wirtualnych do uruchamiania jako bez protokołu SMT

Konfiguracja protokołu SMT dla maszyny wirtualnej jest wyświetlana w okienkach Podsumowanie w konsoli programu Hyper-V Manager. Konfigurowanie ustawień smT maszyny wirtualnej może odbywać się przy użyciu ustawień maszyny wirtualnej lub programu PowerShell.

Konfigurowanie ustawień protokołu SMT maszyny wirtualnej przy użyciu programu PowerShell

Aby skonfigurować ustawienia protokołu SMT dla maszyny wirtualnej gościa, otwórz okno programu PowerShell z odpowiednimi uprawnieniami i wpisz:

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

Where:

• 0 = Dziedziczenie topologii SMT z hosta (to ustawienie HwThreadCountPerCore=0 nie jest obsługiwane w systemie Windows Server 2016)

• 1 = non-SMT

• Wartości > Żądana liczba wątków SMT na rdzeń wynosi 1. Nie może przekraczać liczby fizycznych wątków SMT na rdzeń.

Aby odczytać ustawienia protokołu SMT dla maszyny wirtualnej gościa, otwórz okno programu PowerShell z odpowiednimi uprawnieniami i wpisz:

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

Należy pamiętać, że maszyny wirtualne gościa skonfigurowane z ustawieniem HwThreadCountPerCore = 0 wskazują na włączenie SMT dla gościa, co spowoduje udostępnienie tej samej liczby wątków SMT gościowi, co na hostcie wirtualizacji, zazwyczaj 2.

Maszyny wirtualne gości mogą zauważyć zmiany w topologii procesora w różnych scenariuszach przenoszenia maszyn wirtualnych.

System operacyjny i aplikacje na maszynie wirtualnej mogą widzieć zmiany ustawień hosta i maszyny wirtualnej przed i po cyklu życia maszyny wirtualnej, takie jak migracja na żywo lub operacje zapisywania i przywracania. Podczas operacji, w której stan maszyny wirtualnej jest zapisywany i przywracany, zarówno ustawienie HwThreadCountPerCore maszyny wirtualnej, jak i wartość zrealizowana (czyli obliczona kombinacja ustawienia maszyny wirtualnej i konfiguracji hosta źródłowego) są migrowane. Maszyna wirtualna będzie nadal działać z tymi ustawieniami na hoście docelowym. W momencie zamknięcia i ponownego uruchomienia maszyny wirtualnej możliwe jest, że wartość faktyczna zaobserwowana przez maszynę wirtualną może się zmienić. Powinno to być łagodne, ponieważ oprogramowanie w warstwie systemu operacyjnego i aplikacji powinno szukać informacji o topologii procesora w ramach normalnych przepływów kodu uruchamiania i inicjowania. Jednak ze względu na to, że te sekwencje inicjowania czasu rozruchu są pomijane podczas migracji na żywo lub operacji zapisywania/przywracania, maszyny wirtualne, które przechodzą te przejścia stanu, mogą obserwować pierwotnie obliczoną wartość zrealizowaną do czasu ich zamknięcia i ponownego uruchomienia.

Alerty dotyczące nie optymalnych konfiguracji maszyn wirtualnych

Maszyny wirtualne skonfigurowane z większą liczbą procesorów wirtualnych niż fizycznych rdzeni na hoście powodują nieoptymalną konfigurację. Harmonogram funkcji hypervisor będzie traktować te maszyny wirtualne tak, jakby były uwzględniane przez protokół SMT. Jednak system operacyjny i oprogramowanie aplikacyjne na maszynie wirtualnej będą miały przedstawioną topologię procesora pokazującą, że technologia SMT jest wyłączona. Po wykryciu tego warunku proces roboczy Hyper-V zarejestruje zdarzenie na hoście wirtualizacji ostrzegając administratora hosta, że konfiguracja maszyny wirtualnej nie jest optymalna i zaleca włączenie protokołu SMT dla maszyny wirtualnej.

Jak identyfikować nieokonfigurowane optymalnie maszyny wirtualne

Maszyny wirtualne inne niż SMT można zidentyfikować, sprawdzając Dziennik systemowy w Podglądzie zdarzeń dla identyfikatora zdarzenia procesu roboczego Hyper-V 3498, który zostanie wyzwolony dla maszyny wirtualnej za każdym razem, gdy liczba procesorów wirtualnych w maszynie wirtualnej jest większa niż liczba rdzeni fizycznych. Zdarzenia procesu roboczego można uzyskać z Podglądu zdarzeń lub za pośrednictwem programu PowerShell.

Wykonywanie zapytań dotyczących zdarzenia maszyny wirtualnej procesu roboczego Hyper-V przy użyciu programu PowerShell

Aby wysłać zapytanie dotyczące zdarzenia procesu roboczego Hyper-V o identyfikatorze 3498 przy użyciu programu PowerShell, wprowadź następujące polecenia w wierszu polecenia programu PowerShell.

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

Wpływ konfiguracji SMT gościa na wykorzystanie ulepszeń dla hypervisor przez systemy operacyjne uruchomione na maszynach wirtualnych

Hypervisor firmy Microsoft oferuje wiele ulepszeń lub wskazówek, które system operacyjny działający w maszynie wirtualnej gościa może zapytać i używać do wyzwalania optymalizacji, takich jak te, które mogą poprawić wydajność lub poprawić obsługę różnych warunków podczas uruchamiania środowiska zwirtualizowanego. Niedawno wprowadzono nowe ustalenia dotyczące obsługi planowania procesorów wirtualnych i stosowania środków zaradczych systemu operacyjnego na ataki przez kanały boczne wykorzystujące SMT.

Szczegóły informacji dla gościa znajdują się poniżej, jednak najważniejszym wnioskiem dla administratorów hosta wirtualizacji jest to, że maszyny wirtualne powinny mieć parametr HwThreadCountPerCore skonfigurowany tak, aby odpowiadał fizycznej konfiguracji SMT hosta. Dzięki temu funkcja hypervisor może zgłaszać, że nie ma współużytkowania rdzeni nienależących do architektury. Dlatego można włączyć każdy system operacyjny gościa obsługujący optymalizacje wymagające odpowiednich ułatwień. W systemie Windows Server 2019 utwórz nowe maszyny wirtualne i pozostaw wartość domyślną HwThreadCountPerCore (0). Starsze maszyny wirtualne zmigrowane z hostów systemu Windows Server 2016 można zaktualizować do wersji konfiguracji systemu Windows Server 2019. Po wykonaniu tej czynności firma Microsoft zaleca ustawienie HwThreadCountPerCore = 0. W systemie Windows Server 2016 firma Microsoft zaleca ustawienie HwThreadCountPerCore w celu dopasowania do konfiguracji hosta (zazwyczaj 2).

NoNonArchitecturalCoreSharing szczegóły dotyczące zrozumienia/poznania

Począwszy od systemu Windows Server 2016, monitor wirtualizacji definiuje nowe ulepszenie opisujące jego obsługę planowania i rozmieszczania VP w systemie operacyjnym gościa. To ułatwienie jest zdefiniowane w Specyfikacji Funkcji Najwyższego Poziomu Hypervisora, wersja 5.0c.

Hypervisor syntetyczny CPUID liścia CPUID.0x40000004.EAX:18[NoNonArchitecturalCoreSharing = 1] wskazuje, że procesor wirtualny nigdy nie będzie współużytkował rdzenia fizycznego z innym procesorem wirtualnym, z wyjątkiem procesorów wirtualnych zgłaszanych jako równorzędne wątki SMT. Na przykład gościnny VP nigdy nie będzie działać w wątku SMT razem z głównym VP działającym jednocześnie w sąsiednim wątku SMT na tym samym rdzeniu procesora. Ten warunek jest możliwy tylko wtedy, gdy jest uruchamiany w środowisku zwirtualizowanym, a więc reprezentuje zachowanie SMT niezwiązane z architekturą, co niesie również poważne konsekwencje dla bezpieczeństwa. System operacyjny gościa może używać wartości NoNonArchitecturalCoreSharing = 1 jako sygnału, że bezpieczne jest włączenie optymalizacji, co może pomóc w uniknięciu obciążenia związanego z wydajnością ustawienia STIBP.

W niektórych konfiguracjach hypervisor nie będzie wskazywał, że NoNonArchitecturalCoreSharing = 1. Jeśli na przykład host ma włączoną funkcję SMT i jest skonfigurowany do używania klasycznego harmonogramu hiperwizora, wartość NoNonArchitecturalCoreSharing będzie wynosić 0. Może to uniemożliwić oświeconym gościom włączenie niektórych optymalizacji. W związku z tym firma Microsoft zaleca, aby administratorzy hostów korzystający z protokołu SMT korzystali z podstawowego harmonogramu funkcji hypervisor i upewniali się, że maszyny wirtualne są skonfigurowane do dziedziczenia konfiguracji SMT z hosta w celu zapewnienia optymalnej wydajności obciążenia.

Summary

Krajobraz zagrożenia bezpieczeństwa nadal ewoluuje. Aby upewnić się, że nasi klienci są domyślnie bezpieczni, firma Microsoft zmienia domyślną konfigurację funkcji hypervisor i maszyn wirtualnych, począwszy od systemu Windows Server 2019 Hyper-V, oraz udostępnia zaktualizowane wskazówki i zalecenia dla klientów z systemem Windows Server 2016 Hyper-V. Administratorzy hostów wirtualizacji powinni:

• Przeczytaj i zapoznaj się ze wskazówkami podanymi w tym dokumencie

• Starannie oceń i dostosuj wdrożenia wirtualizacji, aby upewnić się, że spełniają one cele dotyczące zabezpieczeń, wydajności, gęstości wirtualizacji i czasu odpowiedzi obciążenia pod kątem unikatowych wymagań

• Rozważ ponowne skonfigurowanie istniejących hostów systemu Windows Server 2016 Hyper-V w celu wykorzystania silnych korzyści zabezpieczeń oferowanych przez harmonogram rdzeni funkcji hypervisor

• Zaktualizuj istniejące maszyny wirtualne inne niż SMT, aby zmniejszyć wpływ na wydajność z ograniczeń planowania narzuconych przez izolację vp, która eliminuje luki w zabezpieczeniach sprzętu