Hyper-V 하이퍼바이저 스케줄러 유형 선택 관련 정보

적용 대상: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server, 버전 1709, Windows Server, 버전 1803

이 문서에서는 Hyper-V의 기본 및 권장 하이퍼바이저 스케줄러 형식 사용에 대한 중요한 변경 내용을 설명합니다. 이러한 변경 내용은 시스템 보안 및 가상화 성능 모두에 영향을 줍니다. 가상화 호스트 관리자는 이 문서에 설명된 변경 내용과 의미를 검토하고 이해하고, 급변하는 보안 환경에 직면하여 Hyper-V 호스트를 배포하고 관리하는 방법을 가장 잘 이해하기 위해 관련된 영향, 제안된 배포 지침 및 위험 요소를 신중하게 평가해야 합니다.

Important

여러 프로세서 아키텍처에서 볼 수 있는 현재 알려진 사이드 채널 보안 취약성은 SMT(Simultaneous Multithreading)가 설정된 호스트에서 실행될 때 레거시 하이퍼바이저 클래식 스케줄러 유형의 예약 동작을 통해 악의적인 게스트 VM에 의해 악용될 수 있습니다. 성공적으로 악용되면 악의적인 워크로드가 파티션 경계 외부의 데이터를 관찰할 수 있습니다. 하이퍼바이저 코어 스케줄러 유형을 활용하도록 Hyper-V 하이퍼바이저를 구성하고 게스트 VM을 다시 구성하여 이 공격 클래스를 완화할 수 있습니다. 핵심 스케줄러를 사용하면 하이퍼바이저는 게스트 VM의 VP가 동일한 물리적 프로세서 코어에서 실행되도록 제한하므로 VM이 실행되는 물리적 코어의 경계에 데이터에 액세스하는 VM의 기능을 강력하게 격리합니다. 이는 루트 또는 다른 게스트 파티션에 관계없이 VM이 다른 파티션의 아티팩트를 관찰하지 못하게 하는 이러한 측면 채널 공격에 대한 매우 효과적인 완화입니다. 따라서 Microsoft는 가상화 호스트 및 게스트 VM에 대한 기본 및 권장 구성 설정을 변경합니다.

배경

Windows Server 2016부터 Hyper-V는 하이퍼바이저 스케줄러 유형이라고 하는 가상 프로세서를 예약하고 관리하는 여러 가지 방법을 지원합니다. 모든 하이퍼바이저 스케줄러 형식에 대한 자세한 설명은 Hyper-V 하이퍼바이저 스케줄러 형식 이해 및 사용에서 찾을 수 있습니다.

참고 항목

새로운 하이퍼바이저 스케줄러 유형은 Windows Server 2016에서 처음 도입되었으며 이전 릴리스에서는 사용할 수 없습니다. Windows Server 2016 이전의 모든 Hyper-V 버전은 클래식 스케줄러만 지원합니다. 핵심 스케줄러에 대한 지원은 최근에 게시되었습니다.

하이퍼바이저 스케줄러 형식 정보

이 문서에서는 특히 새 하이퍼바이저 코어 스케줄러 형식과 레거시 "클래식" 스케줄러의 사용 및 이러한 스케줄러 형식이 대칭 다중 스레딩 또는 SMT 사용과 어떻게 교차하는지에 중점을 둡니다. 코어 스케줄러와 클래식 스케줄러의 차이점과 각 위치가 기본 시스템 프로세서의 게스트 VM에서 작동하는 방식을 이해하는 것이 중요합니다.

클래식 스케줄러

클래식 스케줄러는 루트 VP 및 게스트 VM에 속한 VP를 포함하여 시스템 전체의 VP(Virtual Processors)에서 작업을 예약하는 공정 공유 라운드 로빈 방법을 나타냅니다. 클래식 스케줄러는 모든 버전의 Hyper-V에서 사용되는 기본 스케줄러 유형입니다(여기에 설명된 대로 Windows Server 2019까지). 클래식 스케줄러의 성능 특성을 잘 이해하고 있으며, 클래식 스케줄러는 워크로드의 과다 구독을 지원하는 것으로 입증되었습니다. 즉, 호스트의 VP:LP 비율을 적절한 마진으로 과도하게 구독합니다(가상화되는 워크로드 유형, 전체 리소스 사용률 등에 따라 다름).

SMT를 사용하도록 설정된 가상화 호스트에서 실행하는 경우 클래식 스케줄러는 코어에 속하는 각 SMT 스레드의 모든 VM에서 게스트 VP를 독립적으로 예약합니다. 따라서 다른 VM은 동일한 코어에서 동시에 실행될 수 있습니다(한 VM은 코어의 한 스레드에서 실행되고 다른 VM은 다른 스레드에서 실행 중임).

핵심 스케줄러

핵심 스케줄러는 SMT의 속성을 활용하여 게스트 워크로드를 격리하여 보안 및 시스템 성능 모두에 영향을 줍니다. 핵심 스케줄러는 VM의 VP가 형제 SMT 스레드에서 예약되도록 합니다. 이 작업은 LP가 2개 그룹에 있는 경우 VP가 2개 그룹으로 스케줄링되고 시스템 CPU 코어가 VM 간에 공유되지 않도록 대칭적으로 수행됩니다.

기본 SMT 쌍에서 게스트 VP를 예약하여 핵심 스케줄러는 워크로드 격리를 위한 강력한 보안 경계를 제공하며 대기 시간에 민감한 워크로드의 성능 가변성을 줄이는 데도 사용할 수 있습니다.

VP가 SMT를 사용하지 않고 가상 머신에 대해 예약되면 해당 VP는 실행될 때 전체 코어를 사용하고 코어의 형제 SMT 스레드는 유휴 상태로 유지됩니다. 이는 올바른 워크로드 격리를 제공하는 데 필요하지만, 특히 시스템 LP가 초과 구독되면 전체 시스템 성능에 영향을 줍니다. 즉, 총 VP:LP 비율이 1:1을 초과하는 경우입니다. 따라서 코어당 여러 스레드 없이 구성된 게스트 VM을 실행하는 것은 최적이하의 구성입니다.

핵심 스케줄러 사용의 이점

핵심 스케줄러는 다음과 같은 이점을 제공합니다.

  • 게스트 워크로드 격리에 대한 강력한 보안 경계 - 게스트 VP는 기본 물리적 코어 쌍에서 실행하도록 제한되어 사이드 채널 스누핑 공격에 대한 취약성을 줄입니다.

  • 워크로드 가변성 감소 - 게스트 워크로드 처리량 가변성이 크게 감소하여 워크로드 일관성이 향상됩니다.

  • 게스트 VM에서 SMT 사용 - 게스트 가상 머신에서 실행되는 OS 및 애플리케이션은 SMT 동작 및 API(프로그래밍 인터페이스)를 활용하여 가상화되지 않은 상태로 실행될 때와 마찬가지로 SMT 스레드 간에 작업을 제어하고 배포할 수 있습니다.

핵심 스케줄러는 현재 Azure 가상화 호스트에서 사용되며, 특히 강력한 보안 경계와 낮은 워크로드 가변성을 활용합니다. Microsoft는 핵심 스케줄러 유형이 대부분의 가상화 시나리오에 대한 기본 하이퍼바이저 예약 유형이어야 하며 앞으로도 계속될 것이라고 판단합니다. 따라서 고객의 보안을 기본적으로 보장하기 위해 Microsoft는 현재 Windows Server 2019를 변경하고 있습니다.

게스트 워크로드에 대한 핵심 스케줄러 성능 영향

특정 취약성 클래스를 효과적으로 완화하는 데 필요하지만 핵심 스케줄러는 잠재적으로 성능을 저하시킬 수도 있습니다. 고객은 VM과 성능 특성의 차이를 볼 수 있으며 가상화 호스트의 전체 워크로드 용량에 영향을 미칠 수 있습니다. 핵심 스케줄러가 SMT가 아닌 VP를 실행해야 하는 경우 기본 논리 코어의 명령 스트림 중 하나만 실행되고 다른 하나는 유휴 상태여야 합니다. 이렇게 하면 게스트 워크로드의 총 호스트 용량이 제한됩니다.

이러한 성능 영향은 이 문서의 배포 지침에 따라 최소화할 수 있습니다. 호스트 관리자는 특정 가상화 배포 시나리오를 신중하게 고려하고 보안 위험에 대한 허용 오차를 최대 워크로드 밀도, 가상화 호스트의 과잉 통합 등의 필요성과 균형을 유지해야 합니다.

최대 보안 태세를 사용하여 Hyper-V 호스트를 배포하려면 하이퍼바이저 코어 스케줄러 유형을 사용해야 합니다. 기본적으로 고객의 보안을 유지하기 위해 Microsoft는 다음과 같은 기본 및 권장 설정을 변경합니다.

참고 항목

Windows Server 2016, Windows Server 1709 및 Windows Server 1803의 초기 릴리스에는 스케줄러 유형에 대한 하이퍼바이저의 내부 지원이 포함되어 있지만 하이퍼바이저 스케줄러 유형을 선택할 수 있는 구성 컨트롤에 액세스하려면 업데이트가 필요합니다. 이러한 업데이트에 대한 자세한 내용은 Hyper-V 하이퍼바이저 스케줄러 유형 이해 및 사용을 참조하세요.

가상화 호스트 변경 내용

  • 하이퍼바이저는 기본적으로 Windows Server 2019부터 핵심 스케줄러를 사용합니다.

  • Microsoft는 Windows Server 2016에서 핵심 스케줄러를 구성합니다. 하이퍼바이저 코어 스케줄러 유형은 Windows Server 2016에서 지원되지만 기본값은 클래식 스케줄러입니다. 핵심 스케줄러는 선택 사항이며 Hyper-V 호스트 관리자가 명시적으로 사용하도록 설정해야 합니다.

가상 머신 구성 변경 사항

  • Windows Server 2019에서 기본 VM 버전 9.0을 사용하여 만든 새 가상 머신은 가상화 호스트의 SMT 속성(사용 또는 사용 안 함)을 자동으로 상속합니다. 즉, 물리적 호스트에서 SMT를 사용하도록 설정하면 새로 만든 VM도 SMT를 사용하도록 설정되고 기본적으로 호스트의 SMT 토폴로지를 상속하며, VM은 기본 시스템과 동일한 수의 코어당 하드웨어 스레드를 갖습니다. HwThreadCountPerCore = 0을 사용하여 VM의 구성에 반영됩니다. 여기서 0은 VM이 호스트의 SMT 설정을 상속해야 임을 나타냅니다.

  • VM 버전이 8.2 이하인 기존 가상 머신은 HwThreadCountPerCore에 대한 원래 VM 프로세서 설정을 유지하며, 8.2 VM 버전 게스트의 기본값은 HwThreadCountPerCore = 1입니다. 이러한 게스트가 Windows Server 2019 호스트에서 실행되면 다음과 같이 처리됩니다.

    1. VM에 LP 코어 수보다 작거나 같은 VP 수가 있는 경우 VM은 코어 스케줄러에 의해 비 SMT VM으로 처리됩니다. 게스트 VP가 단일 SMT 스레드에서 실행되면 코어의 형제 SMT 스레드가 유휴 상태가 됩니다. 이는 최적이 아니고 전반적인 성능 손실이 발생합니다.

    2. VM에 LP 코어보다 많은 VP가 있는 경우 VM은 코어 스케줄러에 의해 SMT VM으로 처리됩니다. 그러나 VM은 SMT VM이라는 다른 표시를 관찰하지 않습니다. 예를 들어 OS 또는 애플리케이션에서 CPU 토폴로지 쿼리에 CPUID 명령 또는 Windows API를 사용하면 SMT가 사용하도록 설정되어 있음을 나타내지 않습니다.

  • 기존 VM이 업데이트-VM 작업을 통해 eariler VM 버전에서 버전 9.0으로 명시적으로 업데이트되면 VM은 HwThreadCountPerCore에 대한 현재 값을 유지합니다. VM에는 SMT 강제 사용이 없습니다.

  • Windows Server 2016에서는 게스트 VM에 SMT를 사용하도록 설정하는 것이 좋습니다. 기본적으로 Windows Server 2016에서 만든 VM은 명시적으로 변경되지 않는 한 SMT를 사용하지 않도록 설정됩니다. 즉, HwThreadCountPerCore는 1로 설정됩니다.

참고 항목

Windows Server 2016은 HwThreadCountPerCore를 0으로 설정하는 것을 지원하지 않습니다.

가상 머신 SMT 구성 관리

게스트 가상 머신 SMT 구성은 VM별로 설정됩니다. 호스트 관리자는 다음 옵션 중에서 선택하도록 VM의 SMT 구성을 검사하고 구성할 수 있습니다.

  1. 필요에 따라 호스트 SMT 토폴로지 자동 상속을 SMT 사용으로 실행하도록 VM 구성

  2. 비 SMT로 실행되도록 VM 구성

VM에 대한 SMT 구성은 Hyper-V 관리자 콘솔의 요약 창에 표시됩니다. VM 설정 또는 PowerShell을 사용하여 VM의 SMT 설정을 구성할 수 있습니다.

PowerShell을 사용하여 VM SMT 설정 구성

게스트 가상 머신에 대한 SMT 설정을 구성하려면 충분한 권한이 있는 PowerShell 창을 열고 다음을 입력합니다.

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

여기서

  • 0 = 호스트에서 SMT 토폴로지 상속(이 HwThreadCountPerCore=0 설정은 Windows Server 2016에서 지원되지 않음)

  • 1 = 비 SMT

  • 값 > 1 = 코어당 원하는 SMT 스레드 수입니다. 코어당 실제 SMT 스레드 수를 초과할 수 없습니다.

게스트 가상 머신에 대한 SMT 설정을 확인하려면 충분한 권한이 있는 PowerShell 창을 열고 다음을 입력합니다.

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

HwThreadCountPerCore = 0으로 구성된 게스트 VM은 게스트에 대해 SMT를 사용하도록 설정되며, 기본 가상화 호스트에 있는 것과 동일한 수의 SMT 스레드를 게스트에 노출합니다(일반적으로 2).

게스트 VM은 VM 모바일 시나리오에서 CPU 토폴로지의 변경 내용을 관찰할 수 있습니다.

VM의 OS 및 애플리케이션은 실시간 마이그레이션 또는 저장 및 복원 작업과 같은 VM 수명 주기 이벤트 전후에 호스트 및 VM 설정이 모두 변경된 것을 볼 수 있습니다. VM 상태를 저장하고 복원하는 작업 중에는 VM의 HwThreadCountPerCore 설정과 실현된 값(즉, VM 설정과 원본 호스트 구성의 계산 조합)이 모두 마이그레이션됩니다. VM은 대상 호스트에서 이러한 설정을 사용하여 계속 실행됩니다. VM이 종료되고 다시 시작되는 시점에서 VM에서 관찰된 실현된 값이 변경될 수 있습니다. OS 및 애플리케이션 계층 소프트웨어가 정상적인 시작 및 초기화 코드 흐름의 일부로 CPU 토폴로지 정보를 찾아야 하므로 이는 무해해야 합니다. 그러나 이러한 부팅 시간 초기화 시퀀스는 실시간 마이그레이션 또는 저장/복원 작업 중에 건너뛰므로 이러한 상태 전환을 수행하는 VM은 종료되고 다시 시작될 때까지 원래 계산된 실현 값을 관찰할 수 있습니다.

최적이 아닌 VM 구성에 대한 경고

호스트에 실제 코어가 있는 것보다 많은 VP로 구성된 가상 머신은 최적화되지 않은 구성을 생성합니다. 하이퍼바이저 스케줄러는 이러한 VM을 SMT를 인식하는 것처럼 처리합니다. 그러나 VM의 OS 및 애플리케이션 소프트웨어에는 SMT가 비활성화되었음을 보여 주는 CPU 토폴로지가 표시됩니다. 이 조건이 감지되면 Hyper-V 작업자 프로세스는 가상화 호스트에서 VM의 구성이 최적이 아닌지 호스트 관리자에게 경고하고 VM에 대해 SMT를 사용하도록 권장하는 이벤트를 기록합니다.

최적으로 구성하지 않은 VM을 식별하는 방법

VM의 VP 수가 실제 코어 수보다 클 때마다 VM에 대해 트리거되는 Hyper-V 작업자 프로세스 이벤트 ID 3498에 대한 시스템 로그 이벤트 뷰어 검사하여 비 SMT VM을 식별할 수 있습니다. 작업자 프로세스 이벤트는 이벤트 뷰어 또는 PowerShell을 통해 가져올 수 있습니다.

PowerShell을 사용하여 Hyper-V 작업자 프로세스 VM 이벤트 쿼리

PowerShell을 사용하여 하이퍼바이저 작업자 프로세스 이벤트 ID 2를 쿼리하려면 PowerShell 프롬프트에서 다음 명령을 입력합니다.

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

게스트 운영 체제에 대한 하이퍼바이저 인식 사용에 대한 게스트 SMT 구성의 영향

Microsoft 하이퍼바이저는 게스트 VM에서 실행되는 OS가 성능에 도움이 되거나 가상화된 실행 시 다양한 조건의 처리를 개선할 수 있는 최적화를 쿼리하고 트리거하는 데 사용할 수 있는 여러 인식 또는 힌트를 제공합니다. 최근에 소개된 인식은 가상 프로세서 예약 처리 및 SMT를 악용하는 사이드 채널 공격에 대한 OS 완화 사용에 관한 것입니다.

참고 항목

호스트 관리자는 게스트 VM에 대해 SMT를 사용하도록 설정하여 워크로드 성능을 최적화하는 것이 좋습니다.

이 게스트 인식에 대한 세부 정보는 아래에 제공되지만 가상화 호스트 관리자의 핵심 사항은 가상 머신에 호스트의 물리적 SMT 구성과 일치하도록 HwThreadCountPerCore가 구성되어 있어야 한다는 것입니다. 이렇게 하면 하이퍼바이저가 아키텍처가 아닌 코어 공유가 없다고 보고할 수 있습니다. 따라서 인식이 필요한 최적화를 지원하는 모든 게스트 OS를 사용하도록 설정할 수 있습니다. Windows Server 2019에서 새 VM을 만들고 HwThreadCountPerCore(0)의 기본값을 그대로 둡니다. Windows Server 2016 호스트에서 마이그레이션된 이전 VM은 Windows Server 2019 구성 버전으로 업데이트할 수 있습니다. 이렇게 하면 HwThreadCountPerCore = 0을 설정하는 것이 좋습니다. Windows Server 2016에서는 호스트 구성과 일치하도록 HwThreadCountPerCore를 설정하는 것이 좋습니다(일반적으로 2).

NoNonArchitecturalCoreSharing 인식 세부 정보

Windows Server 2016부터 하이퍼바이저는 게스트 OS에 대한 VP 예약 및 배치 처리를 설명하는 새로운 인식 기능을 정의합니다. 이러한 인식은 하이퍼바이저 최상위 기능 사양 v5.0c에 정의되어 있습니다.

하이퍼바이저 가상 CPUID 리프 CPUID.0x40000004.EAX:18[NoNonArchitecturalCoreSharing = 1]은 가상 프로세서가 형제 SMT 스레드로 보고된 가상 프로세서를 제외하고 다른 가상 프로세서와 물리적 코어를 공유하지 않음을 나타냅니다. 예를 들어 게스트 VP는 동일한 프로세서 코어의 형제 SMT 스레드에서 동시에 실행되는 루트 VP와 함께 SMT 스레드에서 실행되지 않습니다. 이 조건은 가상화된 실행 시에만 가능하므로 심각한 보안 영향을 주는 비 아키텍처 SMT 동작을 나타냅니다. 게스트 OS는 최적화를 사용하도록 설정하는 것이 안전하다는 표시로 NoNonArchitecturalCoreSharing = 1을 사용할 수 있으며 이는 STIBP 설정의 성능 오버헤드를 방지하는 데 도움이 될 수 있습니다.

특정 구성에서 하이퍼바이저는 NoNonArchitecturalCoreSharing = 1임을 나타내지 않습니다. 예를 들어 호스트가 SMT를 사용하도록 설정하고 하이퍼바이저 클래식 스케줄러를 사용하도록 구성된 경우 NoNonArchitecturalCoreSharing은 0이 됩니다. 이로 인해 인식된 게스트가 특정 최적화를 사용하도록 설정하지 못할 수 있습니다. 따라서 SMT를 사용하는 호스트 관리자는 하이퍼바이저 코어 스케줄러를 사용하고 가상 머신이 최적의 워크로드 성능을 보장하기 위해 호스트에서 SMT 구성을 상속하도록 구성되도록 하는 것이 좋습니다.

요약

보안 위협 환경은 계속 진화하고 있습니다. 고객의 보안을 기본적으로 보장하기 위해 Microsoft는 Windows Server 2019 Hyper-V부터 하이퍼바이저 및 가상 머신에 대한 기본 구성을 변경하고 Windows Server 2016 Hyper-V를 실행하는 고객에게 업데이트된 지침과 권장 사항을 제공합니다. 가상화 호스트 관리자는 다음을 수행해야 합니다.

  • 이 문서에 제공된 지침 읽기 및 이해

  • 고유한 요구 사항에 대한 보안, 성능, 가상화 밀도 및 워크로드 응답성 목표를 충족하도록 가상화 배포를 신중하게 평가하고 조정합니다.

  • 하이퍼바이저 코어 스케줄러에서 제공하는 강력한 보안 이점을 활용하도록 기존 Windows Server 2016 Hyper-V 호스트를 다시 구성하는 것이 좋습니다

  • 하드웨어 보안 취약성을 해결하는 VP 격리에 의해 부과된 예약 제약 조건으로 인한 성능 영향을 줄이기 위해 기존 비 SMT VM을 업데이트합니다.