2. Xen 기본 구조/Hypercall

Xen 기본 구조를 설명하기에 앞서 Hypervisor의 기본 형태중 Type 1에 대해서 간단히 설명을 한다.

Type1은 가상머신을 관리하는 Hypervisor가 OS처럼 직접 하드웨어를 통제하고 VM(Guest OS)들은 Hypervisor 위에서 동작하는 형태이다.

스케줄러, MMU, Page table처럼 OS의 기본적인 기능들을 Hypervisor가 갖고 있고 위 기능들을 잘 이용해서 여러 개의 Guest OS들을 관리한다(작은 OS인 느낌이다). 기본적인 개념은 Type1 Hypervisor들이 모두 같으나 Guest OS를 관리하는 메커니즘은 Hypervisor마다 차이가 있다.

Xen은 Guest OS들을 도메인이라 부르고 Domain이 생성된 순서에 따라 Domain + 생성순서로 이름을 붙인다. Domain중 Xen에서 가장 기본적으로 생성되는 Domain0는 Control Domain이라 한다. Control Domain의 역할은 말그대로 Control이다. Xen 부팅 될 때 생성되어 다른 Domain들을 부팅/종료 하고 Domain의 하드웨어 접근 작업을 관할 한다.

Domain들의 하드웨어 접근 작업을 관할한다는 것이 쉽게 와닿지 않을 것이다. 아마 Type1 구조를 본사람들은 가상화 환경에 대해 다음과 같은 형태를 상상 했을 것 같다

Control Domain 같은거 없이 모든 Guest OS들은 서로 동등하고 각각 자신이 필요할 때마다 Hypervisor를 통해서 Hardware에 접근하는 것이다. 내가 처음에 가상화를 공부할 때 이런 형태로 Type1을 이해했다.

하지만 위와 같은 형태로 만들어 질 때 결과를 예측해보자. 모든 Guest OS들은 각자 출력하고 싶은 것들을 모니터에 출력하려고 할 것이다. 하지만 모니터 장치는 하나이다. 그렇다면 각각의 GuestOS들이 출력한 결과물들을 모두 출력할 것인가? 그건 애초에 예상했던 결과물이 아니다. 가상화 소프트웨어는 여러개의 GuestOS를 동시에 부팅하고, 사용자가 번갈아가면서 모니터를 사용 할 수 있는 환경을 제공하려고 한다.

Xen은 위와 같은 경우의 관리를 Control Domain에게 맡겼다. Guest OS들의 드라이버 접근들을 직접 관할해 어떤 Domain이 하드웨어에 Access 하려고 하며 접근 명령을 받아 직접 Hardware에 Access 하는 작업을 Control Domain인 Dom0가 관리한다.

(Xen에게 관리를 맡길 수도 있겠지만 Xen을 lightweight하게 만들기 위해 Domain0를 둔 것으로 보인다)

위와 같은 구조에서 DomainU는 하드웨어에 접근하기 위해 반드시 Xen을 통해 Domain0에 신호를 보내야 하는 것으로 보인다. 하지만 이런 형태는 일반적인 OS시간에 배운 내용이랑 다르다. OS는 드라이버에서 하드웨어에 접근하기 위해 System Call을 사용하는데, 그러면 OS의 형태인 DomainU는 어떻게 명령어를 전달하는가?

Xen은 Domain들이 하드웨어에 접근 할 때 사용하는 명령어로 Hypercall을 두었다. Hypercall은 Systemcall과 Hypervisor에서 사용하는 systemcall이라는점만 제외하면 기능상으로는 동일하다. 단지 바로 Hardware에 접근하지 않고 Xen에게 명령을 전달한다는 점만 다를 뿐이다. Xen은 Guest OS에서 전송한 Hypercall을 받고 이를 Domain0 에게 신호를 전달한다. Domain0는 전송받은 값들을 갖고 직접 Hardware에 Access한다.

위와 같은 형태로 구현되려면 기존 OS에서 드라이버들이 Systemcall이 아닌 Hypercall들로 대체되어야 한다. 이런 이유로 Xen을 Guest OS들을 수정한 Para-virtualization 구조라 한다.