하이퍼바이저 Xen의 architecture

하이퍼바이저 중 Xen의 아키텍처에 대해 소개해보려고 한다.

Xen은 오픈소스 프로젝트의 일종으로, 시트릭스 사의 XenServer나 오라클의 Virtual Box의 하이퍼바이저이기도 하다.

Type 1 하이퍼바이저이며 초기의 젠은 반가상화만 지원했다.

하지만 지금은 전가상화를 지원하고 있다(왜냐면 전가상화가 대세니까.)

내 짧은 소견으로는 이 그림이 가장 쉽고 자세한 것 같아 첨부해보려 한다.

먼저 눈 여겨 볼 것은 하드웨어 바로 위에 하이퍼바이저가 존재한다는 점. Type 1 하이퍼바이저라는 뜻이다.

그 다음 볼 것은 Dom0이다.

Dom0이 그 옆의 다른 게스트 OS들과 다른 점은 아주 많다.

<유일하게> 실제 물리 장치와 연결되는 장치 드라이버를 가졌고 각 도메인을 제어하는 역할을 맡는다.

그렇다고 절대로 Type 2의 호스트 OS와 헷갈려서는 안된다! 이 Dom0은 엄연히 게스트 OS이기 때문...

참고로 DomU 의 U는 unprivileged 의 U라고 한다.

차례차례 아키텍처를 뜯어보자. (코드까지 자세히 보진 않을 것)

먼저 각각의 도메인(=인스턴스=가상머신)은 커널을 갖는다. 왜냐하면 걔들도 전부 OS를 가지니까.

이 커널들 안에는 전부 장치 드라이버가 들어있다.

왜? 왜 직접 하드웨어와 연결되지 않는 DomU에도 장치 드라이버가 필요한 걸까?

장치 드라이버는 상위 수준의 컴퓨터 프로그램(application)이 장치와 상호작용할 수 있게 해주는 컴퓨터 프로그램이다. 

드라이버는 하드웨어에 따라 다르고 운영 체제에 따라 다르다. 하이퍼 바이저는 가상 머신이 사용하는 모든 하드웨어에 대해

에뮬레이트 하기 때문에 각 가상 머신도 드라이버가 필요하다.

그렇다면 에뮬레이트는 뭘까?

에뮬레이트는 각 가상머신 안에 실제 하드웨어인 것처럼 소프트웨어를 구현해 놓는 것이다.

실제 하드웨어가 작동하는 메커니즘을 따라하는 환경을 구성하는 것이다. 자원 낭비가 심하다는 단점이 있다.

실제 하드웨어와 동일한 방식으로 동작하기 때문에 모든 종류의 장치에 대해서 적용 가능하다는 장점이 있고. 

자 다시 돌아와서...... 각각의 DomU에 들어있는 장치 드라이버를 Dom0의 실제 장치 드라이버랑 연결을 해주어야

진짜처럼 하드웨어를 제어할 수 있을 것이다. 이를 가능하게 하는 정보들이 들어있는 곳이 바로 Dom0의 XenStore이다.

XenStore의 정보들을 이용해서 실제 장치 드라이버와 연결되면 Xenbus를 통해서 소통하게 된다!!!!

연결 후에는 하이퍼 콜을 통해서 하드웨어를 제어하게 된다.

하이퍼 콜은 시스템 콜과 거의 유사한 메커니즘이지만 유저스페이스->커널 이 아니라 도메인->하이퍼바이저 라는 점이 다르다.

unprivileged 도메인의 하이퍼 콜은 하이퍼바이저의 공유 메모리로 보내지고 이 내용은 다시 Dom0의 백엔드로 전달된다.

다시 이 내용은 Dom0의 장치 드라이버로 전달되어 진짜 하드웨어를 제어하게 된다.

그림에 Xend가 있길래 뭔지 찾아보았다.

Xend는 Xen daemon으로 Dom0에서 루트로 실행되는 특수 프로세스. xm 명령을 이용해서 xend와 상호작용할 수 있다. 게스트 도메인을 시작 중지 및 관리하는 명령이며 하이퍼 콜을 통해 Xend로 요청된다.

하지만 어느 버전 이후로 삭제되었다고 하니 넘어가도록 하겠다 ㅎ_ㅎ

아무튼 Xen은 이러한 architecture로 이루어져 있다.