Windows 가상화의 심층(제1회) ── 당신의 Windows는 어디에서 실행되고 있는가: 하이퍼바이저와 파티션

VM을 한 대도 만든 적이 없는데도 Windows 11의 시스템 정보(msinfo32)에는 「가상화 기반 보안: 실행 중」이라고 나옵니다. 이 표시는 무엇을 뜻할까요.

그 PC에서는 호스트 Windows 자체가 이미 하이퍼바이저 위에서 실행되고 있습니다. Windows 11에서는 지원되는 하드웨어에 클린 설치를 하는 등 조건을 충족하는 구성에서 VBS가 기본으로 켜지며, VM을 만들지 않아도 그 토대가 사용됩니다.¹ WSL2와 Windows Sandbox도 같은 Windows 하이퍼바이저를 이용합니다.

제1회에서는 「Hyper-V를 켰을 때 호스트 Windows는 어디에서 실행되게 되는가」를 CPU, 메모리, 디바이스 I/O의 역할 분담에서부터 설명합니다. 「Windows 위에 VM 소프트웨어를 얹는다」라는 관점을 먼저 다시 정리하는 회차입니다.

「Windows 가상화의 심층」 전 3회

같은 Windows 하이퍼바이저를 토대 → 보안 격리 → 경량 VM으로의 응용 순서로 살펴봅니다.

이 글의 전제

이 글을 읽는 방법

아래 지식 맵은 관계의 목록입니다. 처음 읽는 경우에는 1절의 전체 그림부터 본문을 따라가 주세요.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 22건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

1. 먼저 결론부터

Hyper-V라고 하면 「Windows 위에서 동작하는 VM 실행 소프트웨어」를 떠올릴지도 모릅니다. 실제 구조는 그 반대입니다.

Hyper-V를 켜고 다시 시작한 순간부터 물리 CPU와 메모리를 지배하는 것은 하이퍼바이저이며, 호스트 Windows는 「루트 파티션」이라는 이름의 특권을 가진 첫 번째 파티션으로서 그 위에서 동작한다.

하이퍼바이저는 하드웨어와 OS 사이에 끼어드는 얇은 소프트웨어 계층으로, 「파티션」이라고 불리는 격리된 실행 환경을 만들고 하드웨어 접근을 중재합니다.² 호스트 Windows가 들어가는 곳이 루트 파티션이고, VM이 들어가는 곳이 자식 파티션입니다.

루트 파티션은 특별 취급을 받지만(물리 디바이스에 대한 직접 접근과 관리 스택을 갖습니다), 물리 CPU를 직접 지배하고 있는 것은 아니라는 점에서는 자식 파티션과 같은 처지입니다.

flowchart TB
    accTitle: Hyper-V 활성화 후의 전체 구조
    accDescr: 물리 하드웨어 바로 위에 하이퍼바이저가 있고, 그 위에 호스트 Windows가 들어가는 루트 파티션과 VM이 들어가는 자식 파티션들이 나란히 놓인다
    hw["물리 하드웨어"] --> hv["하이퍼바이저"]
    hv --> root["루트 파티션(호스트 Windows)"]
    hv --> child1["자식 파티션(VM들)"]
    root -.-> stack["가상화 관리 스택과 디바이스 드라이버를 가진다"]

그림 1: Hyper-V는 「Windows 위의 VM 소프트웨어」가 아니라 Windows 아래로 들어가는 계층이며, 호스트 OS 자신이 루트 파티션 안에서 동작한다.

「켜기 전후로 체감이 달라지지 않는데 그런 대전환이 일어나고 있다고?」라고 생각할지도 모릅니다. 일어나고 있습니다. 그렇기 때문에 이 구조는 평소에 의식되지 않는 것입니다. 이 글에서는 이 한 장의 그림을 CPU, 메모리, 디바이스 I/O의 세 방향에서 분해해 나갑니다.

2. CPU에서 보기 ── 링 아래에 또 하나의 특권

CPU 이야기에서는 커널과 앱을 나누는 링과 하이퍼바이저와 게스트를 나누는 실행 모드를 구분합니다. 「게스트의 커널도 링 0에서 도는데 왜 충돌하지 않는가」가 이 절의 질문입니다.

2.1. 링 보호 복습

x64의 CPU에는 특권 수준(링)이 있으며, Windows는 커널 모드를 링 0에서, 사용자 모드를 링 3에서 실행합니다. 앱이 하드웨어를 직접 건드릴 수 없는 것은 링 3에서는 특권 명령을 실행할 수 없기 때문입니다.

그렇다면 링 0에서 도는 OS 커널을 여러 개, 같은 물리 CPU 위에서 안전하게 함께 두려면 어떻게 해야 할까요. 어느 커널이든 「내가 CPU를 지배하고 있다」는 전제로 작성되어 있습니다. 모두에게 링 0을 주면 충돌하고, 주지 않으면 동작하지 않습니다.

flowchart TB
    accTitle: 여러 OS 커널이 링 0을 요구하는 문제
    accDescr: 호스트와 게스트의 커널은 둘 다 링 0의 전권을 전제로 작성되어 있어서 기존의 링 계단만으로는 같은 물리 CPU 위에 안전하게 함께 둘 수 없다
    k1["호스트의 커널(링 0 전제)"] --> want["물리 CPU의 지배권을 요구"]
    k2["게스트의 커널(링 0 전제)"] --> want
    want --> conflict["기존 링만으로는 양립할 수 없다"]
    conflict --> need["링 0보다 위의 중재자가 필요"]

그림 2: 링의 계단은 하나의 OS를 전제로 만들어져 있어서, 여러 커널을 함께 두려면 한 단 더 위의 특권이 필요하다.

2.2. 가상화 지원 기능 ── 하이퍼바이저 전용 모드

이 문제를 푸는 것이 CPU의 가상화 지원 기능(Intel VT-x/AMD-V)입니다. Hyper-V는 이 기능을 가진 프로세서를 필수 요건으로 삼습니다.² 가상화 지원 기능은 기존 링과는 다른 축에서 「하이퍼바이저용 실행 모드」와 「게스트용 실행 모드」를 추가합니다. 흔히 「링 -1」이라고 불리기도 하는, 링 0보다 한층 더 강한 특권입니다.

• 게스트의 커널은 지금까지처럼 링 0에서 동작합니다. 고쳐 쓸 필요는 없습니다.
• 다만 그 링 0은 「게스트용 모드 안의 링 0」이며, 물리 CPU 전체를 지배하고 있는 것은 아닙니다.
• 게스트가 하이퍼바이저의 개입이 필요한 특정 조작(개입 대상으로 설정된 명령이나 예외, 위반)에 부딪히면 CPU가 자동으로 하이퍼바이저에게 제어를 넘깁니다(VM Exit). 하이퍼바이저가 처리를 마치면 게스트로 되돌립니다(VM Entry). 일반적인 메모리 접근은 SLAT의 변환이 통하는 한 VM Exit 없이 그대로 지나갑니다.

인터럽트도 마찬가지입니다. 파티션은 물리 프로세서를 직접 건드리지 않으며, 인터럽트는 하이퍼바이저가 받아서 각 파티션으로 돌립니다.²

flowchart TB
    accTitle: 게스트 실행과 VM Exit의 흐름
    accDescr: 게스트의 커널과 앱은 게스트용 모드의 링 0과 링 3에서 동작하고 일반적인 메모리 접근은 SLAT 변환으로 그대로 지나가는 한편, 개입 대상으로 설정된 조작이나 예외에 부딪히면 VM Exit으로 하이퍼바이저에게 제어가 넘어가고 처리 후 VM Entry로 게스트에 돌아온다
    guest["게스트용 모드에서 실행 중(링 0의 커널도 포함)"] --> op{"개입이 필요한 조작인가? (설정된 개입, 예외)"}
    op -->|아니오| cont["그대로 실행을 계속"]
    op -->|예| exitEv["VM Exit(CPU가 제어를 넘긴다)"]
    exitEv --> hvp["하이퍼바이저가 처리"]
    hvp --> entry["VM Entry로 게스트에 복귀"]
    entry --> guest

그림 3: 게스트 OS는 고쳐 쓰지 않고 링 0 그대로 동작하며, 필요할 때만 CPU가 하이퍼바이저를 호출한다.

이 왕복은 메모리 연재에서 따라간 「페이지 폴트로 커널에 들어가 같은 명령으로 돌아온다」는 흐름과 매우 닮았습니다. CPU가 예외와 전이의 구조로 제어를 가로채 상위 관리자에게 판단하게 한 뒤 원래대로 되돌린다. Windows의 심층에서는 이 형태가 반복해서 등장합니다.

2.3. Type 1과 Type 2 ── 어디에 얹혀 있는가의 차이

하이퍼바이저는 하드웨어 바로 위에서 동작하는 Type 1(베어메탈형)과 호스트 OS 위에서 동작하는 Type 2(호스트형)로 크게 나뉩니다. Hyper-V는 Type 1입니다.³ VirtualBox나 단독으로 실행하는 경우의 VMware Workstation은 Type 2로 분류됩니다.

Type 1이라고 하면 「호스트 OS가 없는 서버 전용 구성」을 상상하기 쉽지만, Hyper-V의 경우는 다릅니다. 호스트 Windows는 사라지는 것이 아니라 루트 파티션 안으로 「이사」하는 것입니다. Hyper-V를 켜고 다시 시작하면 부팅 과정에서 먼저 하이퍼바이저가 시작되고, 그 위에서 호스트 Windows가 루트 파티션으로 올라옵니다.

flowchart TB
    accTitle: Type 1과 Type 2 하이퍼바이저의 차이
    accDescr: Type 2에서는 하드웨어 위에 호스트 OS가 있고 그 위에 하이퍼바이저와 VM이 얹히는 반면, Type 1인 Hyper-V에서는 하드웨어 바로 위에 하이퍼바이저가 있고 호스트 OS도 그 위의 루트 파티션에 들어간다
    subgraph t2 ["Type 2(호스트형)"]
        hw2["하드웨어"] --> hostos["호스트 OS"]
        hostos --> hv2["하이퍼바이저"]
        hv2 --> vm2["VM"]
    end
    subgraph t1 ["Type 1(Hyper-V)"]
        hw1["하드웨어"] --> hv1["하이퍼바이저"]
        hv1 --> root1["루트 파티션(호스트 OS)"]
        hv1 --> vm1["VM"]
    end
    vm2 ~~~ hw1

그림 4: Type 2에서는 호스트 OS 위에 하이퍼바이저가 얹히는 반면, Type 1인 Hyper-V에서는 순서가 역전되어 호스트 OS 자신이 한 겹 아래 계층 위에 얹힌다.

켜기 전후에 일어나는 변화를 부팅의 시간축에서 보면 다음과 같습니다.

flowchart TB
    accTitle: Hyper-V 활성화 후의 부팅 순서
    accDescr: 전원을 켠 뒤 부팅 과정에서 먼저 하이퍼바이저가 시작되고 그 위에서 호스트 Windows가 루트 파티션으로 올라오며 VM과 VBS 등은 그보다 뒤에 시작된다
    poweron["전원 투입, 부팅 시작"] --> bhv["하이퍼바이저가 먼저 시작"]
    bhv --> broot["호스트 Windows가 루트 파티션으로 시작"]
    broot --> blater["VM, VBS, WSL2 등은 그 위에서 시작"]
    broot -.-> feel["사용자의 체감은 지금까지와 같음"]

그림 5: 로그온 화면이 나오기 전에 순서의 역전은 이미 끝나 있으며, 호스트 OS는 처음부터 하이퍼바이저 위에서 올라온다.

3. 파티션 ── 격리의 단위

전체 그림에서 「상자」에 해당하는 파티션을 자세히 살펴봅니다. 여기서 나누고 싶은 것은 하이퍼바이저가 직접 맡는 CPU와 메모리의 중재, 그리고 보통은 루트 파티션이 중개하는 디바이스 I/O입니다.

3.1. 루트 파티션만이 갖는 역할

파티션은 하이퍼바이저가 제공하는 격리의 논리 단위입니다.² 다만 모든 파티션이 대등한 것은 아닙니다. 루트 파티션만이 갖는 것이 있습니다.

물리 디바이스에 대한 직접 접근

디스크, NIC, GPU 등의 디바이스 드라이버는 하이퍼바이저가 아니라 루트 파티션 안의 Windows가 갖습니다. 참고로 Windows Server의 Hyper-V에는 특정 PCIe 디바이스를 자식 파티션에 직접 할당하는 구성인 Discrete Device Assignment가 있으며, 그 경우 루트는 해당 디바이스를 내놓습니다. 클라이언트판 Windows에서는 이용할 수 없습니다.⁴

가상화 관리 스택

VM의 생성, 시작, 중지를 관장하는 VMMS 즉 가상 머신 관리 서비스와, VM 한 대마다 올라오는 워커 프로세스인 vmwp.exe는 루트 파티션의 사용자 모드에서 동작합니다.⁵ 이들은 Hyper-V의 VM 관리 기능의 일부이므로, VBS나 WSL2를 위해 하이퍼바이저만 동작하고 있는 호스트에서는 존재하지 않는 경우가 있습니다.

자식 파티션의 생성 권한

루트 파티션은 하이퍼콜 API 즉 하이퍼바이저에 대한 호출 인터페이스를 통해 자식 파티션을 만듭니다.²

이 설계에는 이유가 있습니다. 온갖 디바이스 드라이버를 하이퍼바이저 본체에 넣으면 하이퍼바이저가 거대해지고 결함이나 공격의 입구도 늘어납니다. 하이퍼바이저는 CPU와 메모리의 중재라는 최소한의 일에 전념하고, 디바이스에 관한 뒤치다꺼리는 루트 파티션의 Windows에 맡긴다. 이 역할 분담이 Hyper-V의 얇음을 떠받치고 있습니다.

flowchart TB
    accTitle: 루트 파티션과 자식 파티션의 역할 분담
    accDescr: 루트 파티션은 가상화 관리 스택과 물리 디바이스 드라이버를 갖고 하이퍼콜로 자식 파티션을 생성하며, 자식 파티션은 일반 구성에서는 가상 디바이스만 보고 Windows Server용 Discrete Device Assignment에서는 할당된 디바이스에 직접 접근한다
    subgraph rootp ["루트 파티션"]
        vmms["VMMS와 워커 프로세스"]
        drv["물리 디바이스 드라이버"]
    end
    subgraph childp ["자식 파티션"]
        gos["게스트 OS"]
        vdev["일반 구성에서는 가상 디바이스만 보인다"]
    end
    vmms -->|하이퍼콜로 생성과 관리| childp
    hv2["하이퍼바이저(CPU와 메모리의 중재에 전념)"] --- rootp
    hv2 --- childp

그림 6: 디바이스 드라이버와 관리 스택을 루트 파티션 쪽에 둠으로써 하이퍼바이저 본체는 얇게 유지된다.

3.2. 자식 파티션에서 보이는 세계

자식 파티션의 게스트 OS는 일반적인 가상 디바이스 구성에서는 물리 하드웨어를 직접 볼 수 없습니다. 앞 절에서 말한 Windows Server용 Discrete Device Assignment로 할당된 디바이스만이 예외입니다. 보이는 것은 가상 프로세서와, 자기 전용인 것처럼 보이는 메모리 공간, 그리고 가상 디바이스입니다. 가상 디바이스에 대한 요구는 VMBus 또는 하이퍼바이저를 경유해 루트 파티션으로 전달됩니다.²

한편 CPU 시간의 배분이나 SLAT에 의한 메모리 변환은 루트를 거치지 않고 하이퍼바이저가 직접 맡습니다. 루트가 중개하는 것은 디바이스 I/O이지 모든 물리 자원이 아닙니다.

flowchart TB
    accTitle: 자식 파티션에서 보이는 세계
    accDescr: 게스트 OS에 보이는 것은 가상 프로세서, 파티션 사유의 메모리 공간, 가상 디바이스이며 가상 디바이스에 대한 요구는 VMBus 등을 경유해 루트 파티션으로 전달되고 CPU 시간과 메모리 변환은 하이퍼바이저가 직접 맡으며 Windows Server용 Discrete Device Assignment 구성에서는 할당된 디바이스에만 직접 접근한다
    gos2["자식 파티션의 게스트 OS"] --> vcpu["가상 프로세서"]
    gos2 --> gpa2["사유의 메모리 공간"]
    gos2 --> vdev2["가상 디바이스"]
    vdev2 -->|"VMBus 등 경유"| rootx["루트 파티션으로 전달"]
    gos2 -.->|직접은 보이지 않는다| phys2["물리 CPU, RAM, 실제 디바이스"]
    phys2 -.-> dda2["DDA 구성(Windows Server)에서는 할당 디바이스만 직접 접근"]
    vcpu ~~~ phys2

그림 7: 일반적인 가상 디바이스 구성에서는 게스트에 보이는 것이 모두 가상의 창이고 물리로 가는 통로는 중재역을 거치며, Windows Server의 DDA로 할당한 디바이스만이 예외가 된다.

여기서 중요한 것은 호스트 Windows에서 동작하는 앱 입장에서 이 구조는 거의 투명하다는 점입니다. Win32 API 호출도 페이지 폴트 처리도 지금까지처럼 루트 파티션 안의 Windows 커널이 처리합니다. 하이퍼바이저가 개입하는 것은 설정된 개입 대상이나 예외에 부딪히는 장면으로 한정됩니다.

4. 메모리에서 보기 ── 주소 변환이 한 단 더 늘어난다

메모리에서는 게스트가 「물리」라고 여기는 주소와 실제 RAM 위의 위치를 나눕니다. GVA → GPA → SPA의 순서와 각 변환의 관리자를 기억해 두세요.

4.1. 세 종류의 주소

메모리 연재의 제1회에서는 가상 주소가 페이지 테이블을 거쳐 물리 주소로 변환되는 흐름을 따라갔습니다. 「가상 주소가 물리 RAM으로 바뀌는 순간」이 그 글입니다. 가상화 환경에서는 이 변환 아래에 한 단이 더 붙어 주소는 세 종류가 됩니다.

게스트 OS는 자신의 페이지 테이블로 GVA에서 GPA로 변환합니다. 그러나 게스트가 보고 있는 GPA는 진짜 물리 주소가 아니라 각 파티션 전용의 사적인 메모리 공간입니다.² GPA를 실제 RAM 위의 위치인 SPA에 대응시키는 것은 하이퍼바이저의 일입니다.

4.2. SLAT ── 2단 변환을 하드웨어로

이 두 번째 변환을 소프트웨어만으로 하면 게스트의 페이지 테이블 갱신을 하이퍼바이저가 일일이 추적해야 해서 성능 면에서 현실적이지 않습니다. 그래서 CPU에는 두 번째 변환 테이블을 하드웨어로 찾는 구조가 마련되어 있습니다. 이것이 SLAT(Second Level Address Translation)이며, Intel EPT 즉 확장 페이지 테이블이나 AMD RVI가 여기에 해당합니다.

현행 Hyper-V는 SLAT를 지원하는 64bit 프로세서를 필수 요건으로 삼습니다.⁴

flowchart TB
    accTitle: SLAT에 의한 2단 주소 변환
    accDescr: 게스트 가상 주소는 게스트 OS의 페이지 테이블에서 게스트 물리 주소로 변환되고 다시 하이퍼바이저가 관리하는 SLAT에서 시스템 물리 주소로 변환되어 실제 RAM에 도달한다
    gva["게스트 가상 주소(GVA)"] -->|게스트 OS의 페이지 테이블| gpa["게스트 물리 주소(GPA)"]
    gpa -->|"SLAT(EPT/RVI의 변환 테이블)"| spa["시스템 물리 주소(SPA)"]
    spa --> ram["물리 RAM"]
    gpa -.-> note["게스트가 물리라고 믿고 있을 뿐인 계층"]

그림 8: 게스트의 페이지 테이블 아래에 하이퍼바이저가 관리하는 변환 테이블이 한 단 더 들어가고, CPU는 양쪽 모두를 하드웨어로 따라간다.

SLAT는 VM의 실행 효율만을 위한 기능이 아닙니다. 제2회에서 볼 VBS는 「특권 수준마다 서로 다른 SLAT 변환 테이블을 가질 수 있다」는 성질을 보안 경계의 재료로 사용합니다. 커널에조차 보여 주지 않는 메모리를 만들 수 있는 것은 이 두 번째 변환을 하이퍼바이저가 쥐고 있기 때문입니다. 이 부분은 연재 전체의 복선이 되므로 「변환 테이블의 관리자는 하이퍼바이저」라는 한 가지만은 기억해 두세요.

5. 디바이스 I/O에서 보기 ── VMBus와 두 종류의 디바이스

디바이스 I/O는 CPU 시간이나 메모리 변환과는 경로가 다릅니다. 실재하는 하드웨어를 모방하는 방법과 가상화 전용 통로를 쓰는 방법을 비교합니다.

5.1. 에뮬레이트 디바이스의 한계

자식 파티션에 디바이스를 보여 주는 고전적인 방법은 실재하는 하드웨어를, 예를 들어 오래된 IDE 컨트롤러를 소프트웨어로 완전히 모방하는 것입니다. 게스트 OS의 표준 드라이버를 그대로 쓸 수 있어 호환성은 높지만, 게스트가 I/O 포트를 두드릴 때마다 VM Exit이 발생해 성능이 오르지 않습니다.

flowchart TB
    accTitle: 에뮬레이트 디바이스의 I/O가 느린 이유
    accDescr: 게스트가 I/O 포트를 조작할 때마다 VM Exit으로 하이퍼바이저 쪽에 제어가 넘어가고 디바이스를 소프트웨어로 모방한 뒤 게스트로 돌아오는 왕복이 반복되기 때문에 느리다
    gio["게스트가 I/O 포트를 조작"] --> vex["VM Exit이 발생"]
    vex --> emu2["디바이스를 소프트웨어로 모방"]
    emu2 --> back["VM Entry로 게스트에 복귀"]
    back -->|다음 포트 조작에서 또 반복| gio

그림 9: 한 번의 디스크 접근 뒤에서 이 왕복이 여러 번 돌며, 호환성의 대가는 성능으로 치르게 된다.

5.2. VMBus와 VSP/VSC ── 가상화를 전제로 한 고속 통로

그래서 Hyper-V는 가상화를 전제로 설계된 「합성 디바이스」의 구조를 갖습니다. 등장인물은 셋입니다.²

• VMBus: 파티션 사이의 논리적인 통신 채널. 공유 메모리를 이용한 고속의 파티션 간 통신을 제공합니다.³
• VSP(Virtualization Service Provider): 루트 파티션 쪽에 상주하며 자식으로부터의 디바이스 요구를 받아 루트 쪽의 디바이스 및 백엔드 스택으로 다리를 놓는 서비스. 요구는 물리 디바이스에 도달하기도 하고, 가상 디스크나 가상 스위치 같은 호스트 쪽 백엔드에서 처리되기도 합니다.
• VSC(Virtualization Service Consumer): 자식 파티션 쪽 게스트 OS에 들어가는 합성 디바이스 드라이버. 요구를 VMBus 경유로 VSP에 보냅니다.

예: 게스트의 WriteFile이 호스트에 도달하기까지

게스트 OS의 스토리지 요구는 다음 순서로 흘러갑니다.

1. 게스트 앱의 WriteFile이 게스트 커널의 I/O 스택을 내려갑니다.
2. 최하층에서 실재하는 하드웨어 대신 VSC에 도달합니다.
3. VSC가 요구를 VMBus에 실어 루트 파티션의 VSP에 넘깁니다.
4. VSP가 루트 쪽 I/O 스택으로 요구를 흘려보냅니다. 가상 디스크인 VHDX 구성이라면 호스트 위의 VHDX 파일에 대한 쓰기로 처리되어 최종적으로 물리 디스크에 도달합니다.

이 방식은 Enlightened I/O 즉 가상화를 자각한 I/O라고 불리며, 디바이스 에뮬레이션 계층을 우회함으로써 효율을 높이고 있습니다.²

flowchart TB
    accTitle: 합성 디바이스의 I/O 경로
    accDescr: 자식 파티션의 앱이 낸 I/O 요구는 게스트 커널을 거쳐 VSC에 도달하고 VMBus로 루트 파티션의 VSP에 넘어가며 VSP가 다리를 놓는 루트 쪽 I/O 스택에서 물리 디바이스 드라이버를 거쳐 실제 디바이스에 도달하기도 하고 가상 디스크나 가상 스위치 같은 호스트 쪽 백엔드에서 처리되기도 한다
    app["자식 파티션의 앱"] --> gk["게스트 커널의 I/O 스택"]
    gk --> vsc["VSC(합성 디바이스 드라이버)"]
    vsc -->|VMBus| vsp["VSP(루트 파티션 쪽)"]
    vsp --> rio["루트 쪽의 I/O 스택"]
    rio --> pdrv["물리 디바이스 드라이버"]
    rio --> hb["호스트 쪽 백엔드(가상 디스크, 가상 스위치 등)"]
    pdrv --> dev["물리 디바이스"]

그림 10: 합성 디바이스에서는 게스트의 I/O가 VMBus 경유로 루트 파티션에 넘어가고, 루트 쪽 스택을 거쳐 실제 디바이스나 호스트 쪽 백엔드에 도달한다.

즉 VM의 디스크 I/O나 네트워크가 빠른지 여부는 게스트 쪽만이 아니라 루트 파티션 쪽 I/O 스택과 디바이스 드라이버의 상태에도 좌우됩니다. VM의 성능 문제를 조사할 때 호스트 쪽 관측이 빠질 수 없는 것은 경로가 실제로 호스트를 지나고 있기 때문입니다.

flowchart TB
    accTitle: 에뮬레이트 디바이스와 합성 디바이스의 대비
    accDescr: 에뮬레이트 디바이스는 실재하는 하드웨어의 모방이라 게스트 표준 드라이버를 쓸 수 있지만 느리고 합성 디바이스는 VMBus를 전제로 한 전용 드라이버라 빠르다는 대비
    dev2{"자식 파티션에 보여 줄 디바이스"} --> emu["에뮬레이트 디바이스"]
    dev2 --> syn["합성 디바이스"]
    emu -.-> emuP["실재 하드웨어를 모방, 호환성 중시"]
    emuP -.-> emuC["I/O마다 개입이 필요해 느리다"]
    syn -.-> synP["VMBus를 전제로 한 설계라 고속"]
    synP -.-> synC["게스트에 대응 드라이버가 필요"]

그림 11: 두 종류의 가상 디바이스 중 OS 설치 직후의 호환성은 에뮬레이트가, 상시 사용 시의 성능은 합성 디바이스가 맡는다.

6. VM을 쓰지 않는 사람에게도 남의 일이 아닌 이유

6.1. VBS, WSL2, Sandbox도 같은 토대를 쓴다

여기까지의 구조는 「VM을 세우는 사람의 이야기」로 보일지도 모릅니다. 그러나 서두에서 말했듯이 현재의 Windows에서 하이퍼바이저는 일상의 일부입니다.

• 가상화 기반 보안(VBS). Windows 하이퍼바이저를 사용해 격리 환경을 만들고 거기에 보안 기능을 수용합니다. Windows 11에서는 지원되는 하드웨어에 클린 설치를 하는 등 조건을 충족하는 경우에 기본으로 켜집니다.¹ 자세한 내용은 제2회에서 다룹니다.
• WSL2. 경량 유틸리티 VM 안에서 진짜 Linux 커널을 돌립니다.⁶
• Windows Sandbox. 하이퍼바이저로 분리된 일회용 Windows 환경입니다.⁷ 둘 다 제3회에서 다룹니다.

flowchart TB
    accTitle: 같은 하이퍼바이저 위에 얹히는 일상의 기능
    accDescr: Hyper-V의 VM만이 아니라 클린 설치 등 조건을 충족하는 장치에서 기본으로 켜지는 VBS, WSL2, Windows Sandbox까지 같은 Windows 하이퍼바이저를 토대로 삼고 있다
    base["Windows 하이퍼바이저"] --> f1["Hyper-V의 VM"]
    base --> f2["VBS(클린 설치 등에서 기본 활성화)"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["VM을 쓰지 않는 PC에서도 동작하는 이유"]

그림 12: 토대는 하나이며, 「가상화는 VM을 쓰는 사람의 이야기」라는 전제가 이 그림으로 무너진다.

6.2. 타사 가상화 소프트웨어와의 공존

또 하나, 실무에서 자주 밟는 것이 타사 가상화 소프트웨어와의 공존입니다. CPU의 가상화 지원 기능은 하이퍼바이저가 배타적으로 사용하기 때문에, Windows 하이퍼바이저가 동작하고 있는 환경에서는 VirtualBox 등이 기존 방식으로, 즉 자체적으로 CPU의 가상화 지원을 사용하는 방식으로 동작할 수 없습니다.

이를 위해 Windows Hypervisor Platform이라는 공개 API가 마련되어 있어, 타사 가상화 스택은 Windows 하이퍼바이저 위에 얹히는 형태로 동작할 수 있습니다.⁸ 현행 VirtualBox와 VMware가 WSL2와 공존할 수 있는 것은 이 구조 덕분이지만, 방식 전환에 따른 성능 차이나 기능 차이가 「Hyper-V 또는 VBS를 켰더니 가상화 소프트웨어의 상태가 달라졌다」는 형태로 관측되는 경우가 있습니다.

flowchart TB
    accTitle: CPU 가상화 지원의 소유자와 타사 가상화 소프트웨어의 경로
    accDescr: Windows 하이퍼바이저가 동작 중이면 CPU의 가상화 지원 기능을 하이퍼바이저가 점유하고 WHP를 지원하는 타사 가상화 소프트웨어는 Windows Hypervisor Platform 경유로 그 위에 얹혀 동작하는 한편 WHP를 지원하지 않는 구현은 동작할 수 없거나 기능이 제한된다
    vt["CPU의 가상화 지원(VT-x/AMD-V)"] --> hvon{"Windows 하이퍼바이저는 동작 중인가?"}
    hvon -->|아니오| direct["타사 소프트웨어가 직접 이용할 수 있다"]
    hvon -->|예| own["하이퍼바이저가 점유"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["WHP를 지원하는 타사 소프트웨어는 그 위에서 동작"]
    third -.-> nowhp["지원하지 않는 구현은 동작 불가 또는 기능 제한"]

그림 13: 가상화 지원 기능의 소유자는 하나이며, 하이퍼바이저 동작 중에 함께 있을 수 있는 것은 공개 API인 WHP를 지원하는 타사 소프트웨어로 한정된다.

7. 내 눈으로 확인하기

내 PC에서 하이퍼바이저가 동작하고 있는지는 손에서 바로 확인할 수 있습니다.

7.1. PowerShell로 하이퍼바이저와 VBS를 확인한다

먼저 관리자 권한 없이 실행할 수 있는 확인입니다.

# 하이퍼바이저 위에서 동작하고 있는지
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# VBS의 상태 (msinfo32의 「가상화 기반 보안」과 같은 정보원)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus는 VBS의 동작 상태를 숫자로 돌려줍니다. 2가 「실행 중」입니다.⁹

한 가지 주의할 점이 있습니다. HypervisorPresent가 나타내는 것은 「하이퍼바이저 위에서 동작하고 있는가」뿐이며, 루트인지 자식인지는 구분하지 않습니다. VM 안의 Windows에서 실행해도 자식 파티션으로서 True가 돌아옵니다. 물리 PC 위의 Windows에서 True라면 그 Windows는 루트 파티션 안에 있다 ── 이렇게 실행 환경과 함께 읽습니다.

7.2. systeminfo에서 「동작 중」과 「사전 요건」을 구분해 읽는다

다음은 명령 프롬프트에서 쓰는 정석입니다.

systeminfo

출력 끝의 「Hyper-V 요구 사항」을 봅니다. 하이퍼바이저가 아직 동작하지 않는 머신에서는 SLAT 지원, 가상화 지원의 사용 여부 등 요건이 개별적으로 표시됩니다. 이미 하이퍼바이저가 동작하고 있는 머신에서는 요건 대신 「하이퍼바이저가 감지되었습니다. Hyper-V에 필요한 기능은 표시되지 않습니다.」라고 한 줄만 표시됩니다.⁴

즉 이 한 줄은 당신의 Windows가 어떤 하이퍼바이저 위에서 동작하고 있다는 표명입니다. HypervisorPresent와 마찬가지로 물리 PC라면 루트 파티션 안, VM 안이라면 자식 파티션으로서라는 식으로 구분해 읽어야 합니다.

systeminfo의 요건이 모두 「예」라도 그것은 하드웨어 쪽 준비가 갖춰졌다는 뜻입니다. Hyper-V 기능 자체는 Pro, Enterprise, Education 에디션에서 이용할 수 있고 Home에는 없습니다.¹⁰

7.3. 화면에서 볼 때도 확인하는 항목을 구분한다

GUI라면 msinfo32의 「시스템 요약」에서 「가상화 기반 보안」 행을 확인합니다. 작업 관리자의 CPU 란에 있는 「가상화: 사용」은 펌웨어에서 가상화 지원 기능이 켜져 있는지를 나타낼 뿐이며, 하이퍼바이저가 동작 중인지와는 별개의 정보라는 점에 주의해 주세요.

flowchart TB
    accTitle: 하이퍼바이저 동작 상태의 확인 절차
    accDescr: systeminfo에서 하이퍼바이저가 감지되었습니다라고 나오면 하이퍼바이저 위에서 동작 중이며 물리 PC라면 루트 파티션이고, Hyper-V 요구 사항 목록이 나오면 아직 동작하지 않으므로 SLAT과 VM 모니터 모드 확장과 DEP 등 모든 요건을 확인하지만 모든 요건이 예라도 그것은 하드웨어 쪽 준비이며 Hyper-V 기능에는 에디션 요건도 있다
    start2["systeminfo를 실행"] --> q1{"Hyper-V 요구 사항 란은?"}
    q1 -->|하이퍼바이저가 감지되었습니다| running["하이퍼바이저 동작 중(물리 PC라면 루트 안)"]
    q1 -->|요건이 목록으로 표시된다| notyet["하이퍼바이저는 미동작"]
    notyet --> q2{"요건은 모두 「예」인가?"}
    q2 -->|모두 예| can["하드웨어 쪽 준비는 갖춰져 있다"]
    can -.-> ed["Hyper-V에는 Pro/Enterprise/Education도 필요"]
    q2 -->|아니오가 있다| uefi["UEFI/BIOS 등에서 해당 항목을 확인"]

그림 14: systeminfo의 「Hyper-V 요구 사항」 란은 동작 상태 확인과 사전 요건 확인을 하나로 겸한다.

8. 실무에서 피하고 싶은 세 가지 오독

8.1. 「Hyper-V를 켜지 않았으니 우리 PC에 가상화는 상관없다」

Hyper-V 기능인 관리 도구와 VM 실행 환경을 켜지 않았더라도 VBS가 켜져 있으면 Windows 하이퍼바이저는 동작하고 있습니다. 드라이버 호환성 문제, 성능 검증, 타사 가상화 소프트웨어의 장애를 조사할 때는 기능의 활성화 상태가 아니라 HypervisorPresent와 VBS의 동작 상태를 확인해 주세요.

8.2. 「작업 관리자에 『가상화: 사용』이라고 나오니까 Hyper-V가 동작하고 있다」

그 표시는 펌웨어 설정, 즉 VT-x/AMD-V를 쓸 수 있는 상태인지에 관한 이야기입니다. 하이퍼바이저의 동작 상태는 systeminfo의 「하이퍼바이저가 감지되었습니다」로 판단합니다. 반대로 작업 관리자에서 「사용 안 함」이라면 Hyper-V도 WSL2도 켤 수 없으므로 UEFI/BIOS 설정을 먼저 확인합니다.

flowchart TB
    accTitle: 혼동하기 쉬운 세 가지 확인 항목
    accDescr: 작업 관리자의 가상화 란은 펌웨어 설정, Windows 기능 목록은 설치 상태, systeminfo와 HypervisorPresent는 동작 상태를 나타내며 각각 다른 질문에 답하고 있다
    q3{"무엇을 알고 싶은가?"} --> a3["펌웨어에서 가상화 지원이 켜져 있는가"]
    q3 --> b3["Hyper-V 기능을 넣었는가"]
    q3 --> c3["하이퍼바이저는 지금 동작하고 있는가"]
    a3 -.-> a3t["작업 관리자의 CPU 란"]
    b3 -.-> b3t["Windows 기능의 활성화 화면"]
    c3 -.-> c3t["systeminfo와 HypervisorPresent"]

그림 15: 셋은 독립된 질문이며, 어느 하나의 표시에서 나머지 둘을 추측하면 오독이 된다.

8.3. 「VM이 느린 것은 게스트 OS의 문제」

합성 디바이스의 I/O는 VMBus를 지나 루트 파티션의 VSP에 넘어가고, 루트 쪽의 디바이스 및 백엔드 스택 즉 물리 드라이버 외에 가상 스위치나 가상 디스크의 처리를 경유합니다. 게스트 안의 카운터만 바라봐서는 병목이 호스트 쪽 스토리지나 NIC에 있을 경우 찾아낼 수 없습니다. VM의 성능 문제는 게스트와 호스트 즉 루트 파티션 양쪽에서 관측하는 것이 원칙입니다.

9. 정리

• Hyper-V를 켜면 하이퍼바이저가 하드웨어 바로 위에서 동작하고 호스트 Windows는 루트 파티션으로서 동작합니다.²
• 게스트 OS의 커널은 링 0 그대로 동작하며, 개입 대상으로 설정된 조작과 예외만이 VM Exit으로 하이퍼바이저에 넘어갑니다. 일반적인 메모리 접근은 SLAT의 변환으로 그대로 지나갑니다.
• 루트 파티션만이 물리 디바이스 드라이버와 가상화 관리 스택을 가지며 하이퍼콜로 자식 파티션을 만듭니다.²
• 메모리는 GVA→GPA→SPA의 2단 변환이 되고, 두 번째 단은 SLAT 즉 EPT/RVI가 하드웨어로 맡습니다. 현행 Hyper-V는 SLAT가 필수입니다.⁴
• 디바이스 I/O는 VSC→VMBus→VSP라는 합성 디바이스의 경로가 주역이며, 성능은 호스트 쪽 I/O 스택에도 의존합니다.²
• Windows 11에서는 클린 설치 등 조건을 충족하는 장치에서 기본으로 켜지는 VBS 덕분에, VM을 쓰지 않는 PC에서도 하이퍼바이저가 동작하고 있는 일이 드물지 않습니다.¹ 동작 상태는 HypervisorPresent와 systeminfo로 확인할 수 있습니다.

제1회의 전체 그림은 이 한 장에 집약됩니다.

flowchart TB
    accTitle: 제1회의 전체 그림
    accDescr: 루트 파티션과 자식 파티션 아래에 하이퍼바이저가 있고 CPU는 가상 프로세서의 스케줄로 배분되며 VM Exit은 설정된 개입과 예외만이고 메모리는 SLAT의 2단 변환으로 중재되며 합성 디바이스의 I/O는 VMBus로 전달되어 루트 파티션의 VSP가 처리하고 에뮬레이트 디바이스와 Discrete Device Assignment는 별도 경로를 가진다
    up["루트 파티션과 자식 파티션"] --> hvS["하이퍼바이저"]
    hvS --> cpuS["CPU: 가상 프로세서를 배분"]
    hvS --> memS["메모리: SLAT로 2단 변환"]
    hvS --> devS["디바이스: 합성은 VMBus로 전달"]
    cpuS -.-> cpuN["VM Exit은 개입 시에만"]
    devS --> vspS["루트 쪽의 VSP가 처리"]
    devS -.-> devN["에뮬레이트와 DDA는 별도 경로"]

그림 16: CPU의 스케줄과 메모리 변환은 하이퍼바이저가 직접 맡고 VM Exit은 개입 시에만 일어나며, 합성 디바이스의 I/O는 VMBus 너머에서 루트 파티션의 VSP가 중개한다.

이어지는 글은 제2회 「커널에서도 보이지 않는 메모리 ── VBS, HVCI, Credential Guard」입니다.

하이퍼바이저가 SLAT의 변환 테이블을 쥐고 있다는 이 글의 복선을 회수하면서, 「관리자 권한으로도 커널로도 읽을 수 없는 메모리」를 Windows가 어떻게 만들고 있는지를 따라갑니다.

관련 글

• Windows 메모리의 심층(제1회) ── 가상 주소가 물리 RAM으로 바뀌는 순간: 페이지 폴트의 전말
• Windows의 「메모리 사용량」은 무엇을 나타내는가 ── 워킹 세트, Private Bytes, 커밋, 페이지 파일을 올바르게 읽기
• Windows Sandbox로 업무 앱 검증 환경 만들기
• Windows의 P/E 코어와 프로세서 스케줄링

관련 상담 영역

합동회사 코무라소프트에서는 Windows 애플리케이션의 검증 환경 설계, 가상화 환경에서의 성능 조사, 드라이버나 주변 기기의 호환성 문제 분석을 다룹니다.

• Windows 앱 개발
• 결함 조사와 원인 분석
• 기존 자산 활용과 이전 지원
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

Hyper-V를 켜면 호스트 Windows는 어디에서 실행되나요?

하이퍼바이저가 물리 CPU와 메모리의 배분을 직접 제어하고, 호스트 Windows는 루트 파티션이라고 불리는 특별한 파티션 안에서 실행됩니다. 물리 디바이스의 제어는 보통 루트 파티션 쪽 드라이버가 맡습니다. 루트 파티션은 디바이스 드라이버와 가상화 관리 스택을 갖지만, 물리 CPU의 지배권은 하이퍼바이저 쪽에 있습니다.

작업 관리자의 「가상화: 사용」은 Hyper-V가 동작 중이라는 뜻인가요?

아닙니다. 그 표시는 펌웨어에서 CPU의 가상화 지원 기능(Intel VT-x/AMD-V)이 켜져 있는지를 나타냅니다. 하이퍼바이저가 실제로 동작 중인지는 systeminfo의 「하이퍼바이저가 감지되었습니다」 표시나 Win32_ComputerSystem의 HypervisorPresent로 확인합니다.

VM을 한 대도 만들지 않았는데 하이퍼바이저가 동작하는 이유는 무엇인가요?

Windows 11에서는 지원되는 하드웨어에 클린 설치를 하는 등 조건을 충족하는 장치에서 가상화 기반 보안(VBS)이 기본으로 켜지며, VBS는 Windows 하이퍼바이저를 토대로 삼습니다. WSL2나 Windows Sandbox를 쓰는 경우도 마찬가지입니다. VM 사용 여부와 무관하게 하이퍼바이저가 시작되어 있는 일은 드물지 않습니다.

SLAT란 무엇인가요? 왜 Hyper-V에 필수인가요?

SLAT(Second Level Address Translation)는 게스트 물리 주소에서 실제 물리 주소로의 변환을 CPU가 수행하는 구조이며, Intel EPT와 AMD RVI가 여기에 해당합니다. 이것이 없으면 하이퍼바이저가 소프트웨어로 변환 테이블을 유지해야 해서 성능 면에서 현실적이지 않기 때문에, 현행 Hyper-V에서는 필수 요건입니다.

Hyper-V를 켜면 VirtualBox나 VMware를 쓸 수 없게 되나요?

하이퍼바이저가 CPU의 가상화 지원 기능을 배타적으로 사용하기 때문에, 타사 하이퍼바이저는 기존 방식으로는 동작할 수 없게 됩니다. 다만 현행 VirtualBox와 VMware는 Windows 하이퍼바이저 위에서 동작하는 모드(Windows Hypervisor Platform 경유)를 갖고 있어, 최신 버전끼리 조합하면 공존할 수 있습니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.