• 1. 이 글에 관하여
• 2. 기본 아키텍쳐
• 3. 리소스 가상화
  • 3.1. CPU
  • 3.2. 메모리
  • 3.3. 디바이스
• 4. 소스 구조와 관리
  • 4.1 하이퍼바이저
  • 4.2 솔라리스와 인텔 플랫폼
• 5. 부팅
• 6. 관찰 / 디버그 기능
  • 6.1 xm
  • 6.2 크래쉬 덤프
  • 6.3 DTrace

1. 이 글에 관하여

이 글은 Xen 아키텍쳐, Xen 설정 혹은 도메인 관리 같은 복잡한 내용을 설명하도록 의도되지 않았습니다. 이 글은 Xen 세계를 구성하는 기본적인 컴포넌트들에 대한 간단한 소개와 함께 Xen 의 등장으로 인한 변화를 개발자들이 이해할 수 있도록 하는 목적을 가지고 쓰여 졌습니다.

Xen 에 대한 좀 더 자세한 정보는 아래의 링크를 참고하시기 바랍니다:

• 오픈솔라리스 커뮤니티: http://www.opensolaris.org/os/community/xen/

• 오픈소스 Xen 프로젝트의 홈: http://www.cl.cam.ac.uk/research/srg/ne ··· dex.html

• 커뮤니티 배포판 문서: http://www.opensolaris.org/os/community/xen/

2. 기본 아키텍쳐

Xen 은 오픈소스 하이퍼바이저(hypervisor) 로써 x86/x64 플랫폼상에서 개발되었고 IA64 와 PPC 로 포팅 되었습니다. 운용중인 시스템에서 Xen 은 하드웨어와 운영체제의 중간 단계에 들어 갑니다.

Xen 은 동시에 여러개의 운영체제를 지원합니다. 각 인스턴스들은 '도메인' 으로 불립니다: 두개의 서로 다른 도메인이 존재합니다: 컨트롤 도메인(일반적으로 "dom0" 으로 불림) 그리고 사용자 도메인("domU" 로 불림). 솔라리스 존과는 다르게 각 도메인은 운영체제의 완벽한 인스턴스 입니다.

Xen 하이퍼바이저는 시스템 하드웨어를 가상화 합니다. 즉 시스템 리스소(CPU, 메모리, NIC 등등) 를 각 유저 도메인 사이에 투명하게 공유하고 나눕니다.

하이퍼바이저는 운영체제를 위한 가상화 플랫폼을 제공하는데 필요로 하는 아주 저수준의 작업을 수행하지만 이외의 작업은 완전히 컨트롤 도메인에 의존 합니다. 컨트롤 도메인은 어떠한 domU 가 생성되었는지, 어떠한 리소스들에 접근할 수 있는지, 얼마만큼의 메모리를 사용할 수 있는지 등을 관리 합니다. 또한 Xen 은 어떠한 디바이스 드라이버도 포함하고 있지 않으므로 dom0 이 모든 디바이스 접근 작업을 수행합니다.

두가지 방식의 가상화가 존재합니다: full virtualization, paravirtualization. full virtualization 에서 운영체제는 그 자신이 가상화 횐경에서 실행되고 있는지 전혀 알지 못합니다. paravirtualization 에서 운영체제는 가상화 레이어에 대해 인식하고 있고 하이퍼바이저와 함께 작업함으로써 고성능을 낼 수 있습니다. Xen 은 두가지 모델 모두를 지원합니다. Xen 은 하이퍼바이저 레이어와 긴밀히 작업해야 하기 때문에 dom0 은 항상 paravirtualization 으로 동작합니다. domU 는 두가지 방식 모두를 사용할 수 있고 시스템은 두가지 방식 모두를 동시에 수행할 수 있어야 합니다.

full virtualization 은 운영체제에서 하드웨어로 직접적으로 수행하는 작업들을 투명하게 가로채는 것이 필요 합니다. 이러한 가로채기는 하이퍼바이저가 도메인이 다른 도메인의 메모리의 메모리를 읽거나 쓰는 것을 방지하고, 디바이스 접근 방해를 막고 또한 사용하고 있는 CPU 를 셧다운 시키는 것을 방지하기 위함입니다. full virtualization 을 구현하기 위해서 Xen 은 특수한 하드웨어 지원이 필요합니다. 특히 VT 가 지원되는 인텔 CPU(인텔 코어 듀오 같은) 혹은 AMD-v 가 지원되는 AMD CPU 등을 사용해야 합니다. full virtualization 은 솔라리스, 리눅스, 윈도우를 포함한 모든 x86 운영체제가 실행될 수 있도록 합니다.

paravirtualization 은 하이퍼콜(hypercall) 인터페이스 위에서 구축 됩니다. 하이퍼콜이란 시스템 콜과 비슷하지만 운영체제가 하이퍼바이저 레이어로 호출 하는 것이 다릅니다. 이러한 하이퍼콜은 도메인이 새로운 도메인을 생성하고, 주소 매핑 생성을 요청하고, 한 도메인에서 다른 도메인으로 버퍼를 전송하고, CPU 간의 인터럽트를 전송하는 등의 작업을 하도록 도와 줍니다. 하이퍼바이저 레이어는 OS 가 명시적으로 완벽히 가상화된 환경에서 투명하게 가로채어지는 작업들을 수행하도록 합니다. 가로채기가 필요 없으므로 paravirtualization 은 어떠한 특수한 하드웨어 지원도 필요하지 않습니다. 그리고 어떠한 CPU 에서도 실행 됩니다. paravirtualizatio 은 OS 의 변경을 요구 하기 때문에 오직 몇몇 특수한 시스템 만이 paravirtualize 된 domU 로 호스팅 될 수 있습니다. 현재 솔라리스, 리눅스 FreeBSD 만이 사용 가능합니다.

3. 리소스 가상화

3.1. CPU

Xen 은 도메인에 하나 혹은 그 이상의 가상 CPU (vcpu) 를 지정합니다. 각 vcpu 는 일반적으로 물리적인 CPU 와 연관시키는 모든 상태들을 포함하고 있습니다: 레지스터, 플래그, 타임스탬프 등등. Xen 의 vcpu 는 솔라리스의 쓰레드 처럼 스케줄 될 수 있습니다. 도메인이 CPU 에서 실행될 차례가 되면 Xen 은 물리 CPU 에 vcpu 에 저장된 상태를 로딩하고 실행되도록 합니다.

솔라리스는 각 vcpu 를 물리 CPU 로 간주 합니다. Xen 이 어떤 vcpu 가 실행되도록 선택 한다면 vcpu 에 로드된 솔라리스에 의해 쓰레드로 실행됩니다.

3.2. 메모리

솔라리스는 페이지내의 메모리를 관리 합니다. 하드웨어에서 직접적으로 실행되면 솔라리스는 시스템 BIOS 혹은 펌웨어에 의해 제공되는 물리 페이지 프레임 번호를 사용 합니다. Xen 하에 실행되면 하이퍼바이저가 사용가능한 물리 페이지 목록을 제공합니다. 게스트 OS 를 하드웨어에서 고립시키고 라이브 마이그레이션 같은 기능을 활성화 하기 위해 Xen 에 의해 제공되는 페이지 번호는 하드웨어가 이해하는 물리적 페이지를 반영하지 않습니다. 대신 페이지는 시스템 메모리의 가상화된 뷰를 반영합니다. Xen 은 게스트 OS 의 "물리적" 페이지 번호를 하드웨어에 의해 인식될 수 있는 "머신 프레임 번호" (MFN) 으로 매핑합니다.

대부분의 경우 솔라리스는 Xen 에 의해 제공되는 PFN 을 실제 하드웨어에서 사용되는 PFN 을 다루는 것처럼 동일하게 다룹니다. 솔라리스 쪽에서 이해해야할 부분은 PFN 은 HAT 레이어의 아주 낮은 수준에서 가상화 되었다는 것입니다. 프로세스 페이지 테이블을 수정할 때에만 우리는 PFN 대신 MFN 을 사용합니다.

만약 HAT 레이어 밖에서 MFN 과 PFN 의 차이점을 알기를 원한다면 여러분이 무언가 잘못 생각하고 있다는 것을 의미 합니다.

3.3. 디바이스

dom0 솔라리스 드라이버는 일반적인 솔라리스 드라이버와 동일 합니다. 이러한 드라이버들은 표준 DDI 인터페이스를 통해서 작성되었기 때문에 dom0 에서 동일하게 동작할 것입니다.

DDI 를 이용해서 동작하지 않는 드라이버들은 dom0 에서 실행될때 문제를 일으킬 수 있습니다. DMA 가 그런 취약점중의 하나가 되겠습니다. 만약 드라이버가 ddi_dma_*_bind_handle() 인터페이스 대신에 PFN 에 직접 접근한다면, 반드시 필요한 PFN-> MFN 변환 작업이 빠지게 되고, 드라이버는 디바이스에서 엉뚱한 곳에서 I/O 를 수행하도록 지시할 것입니다. 오류는 대부분 dom0 의 크래쉬를 유발하지만 조용한 데이타 유실을 발생시킬 수도 있습니다.

domU 에서 디바이스 드라이버가 동작할 수 있는 방법은 두가지가 있습니다.

full virtualize 된 domU 에서 Xen 은 I/O 공간의 쓰기 작업 혹은 어떠한 DMA 작업에 대해서도 trap 을 발생시키고 투명하게 이러한 요청들을 dom0 의 적절한 디바이스로 전달합니다. 이러한 trap 과 전달 작업은 매우 비싼 작업이므로 이러한 종류의 디바이스 접근(특히 네트워크 디바이스의 경우) 아주 낮은 퍼포먼스 를 보여 주게 될 것입니다.

paravirualize 된 domU 에서 각 드라이버는 domU 에 "front end" 를 가지고 dom0 에 "back end" 를 가집니다. 이러한 것들은 PV 드라이버라고 불립니다. front end 드라이버는 표준 요청을 솔라리스로 부터 받고 이것들을 back end 드라이버로 전달 합니다. back end 드라이버는 물리 하드웨어에서 요청들을 실행하고 결과를 다시 front end 드라이버로 전달합니다. 이때 솔라리스는 작업이 완료 됐음을 통지 받습니다. 드라이버는 명시적으로 하이퍼바이저에 인식됨으로써 하이퍼바이저 및 back end 드라이버와 함께 작업하는 것이 가능해짐에 따라 full virtualize 환경에 비해 훨씬 빠른 퍼포먼스를 보여 줍니다.

ON 에는 두가지의 메인 paravirualize 드라이버가 존재 합니다: 가상 블럭 디바이스, 가상 네트워크 디바이스. 이 두 드라이버는 domU 에 공유 디스크 및 네트워크 디바이스와 함께 존재 합니다.

드라이버를 지원하는 복합 모델 또한 존재 합니다: PV 드라이버를 full virtualize 환경에서 구현하는 것이 바로 그것입니다. 이러한 경우 운영체제는 여전히 환경이 가상인것을 알지 못하지만 도메인 내의 PV 드라이버는 하이퍼바이저의존재를 알고 있습니다. 이러한 방법은 전체 OS 가 하이퍼바이저로 포팅 되는 것이 필요 없이 좀 더 낳은 I/O 퍼포먼스를 얻을 수 있도록 해 줍니다.

4. 소스 구조와 관리

4.1 하이퍼바이저

Xen 하이퍼바이저는 오픈 소스 프로젝트에 기반하고 있고 Xen 커뮤니티는 리눅스 유저들에 의해 광범위하게 퍼지고 있습니다. 솔라리스가 dom0 으로 동작하기 위해서는 하이퍼바이저에 몇가지 수정이 필요했습니다. 이러한 변경사항들은 메인 Xen 소스 트리로 편입되었고 나머지는 우리자신들이 유지해야 했습니다. 그러므로 Xen 오픈 소스 사이트에서 단순히 소스를 다운로드 받아서 솔라리스가 dom0 으로 동작하도록 기대하면 안됩니다.

솔라리스호환의 Xen 커뮤니티 배포판은 설치가능한 DVD ISO 로 사용 가능합니다.

4.2 솔라리스와 인텔 플랫폼

Xen 의 등장으로 이제 인텔 아키텍쳐에는 두개의 서로 다른 플랫폼이 존재합니다: i68pc, i86xpv 가 바로 그것들입니다. i86pc 는 일반적인 머신에서 돌아가는 솔라리스를 의미 합니다.i86xpv 는 Xen 하이퍼바이저 위에서 실행되는 솔라리스를 의미 합니다.

i86xpv 과 i86pc 플랫폼은 달라보이지만 서로 비슷 합니다. i86xpv 플랫폼에 특수한 코드들은 usr/src/uts/i86xpv 에서 보실 수 있습니다. 그러나 i86xpv 플랫폼을 구현하기 위해 사용된 대부분의 코드들은 i86pc 서브-트리 usr/src/uts/i86pc 에서 가져 왔습니다).

i86xpv 플랫폼 코드를 빌드하기 위해서는 몇몇 헤더 파일들이 Xen 소스 트리에서 필요 합니다. 이러한 헤더들은 common/xen/public 에서 찾으실 수 있습니다. 헤더파일이 ON 소스 트리에 올바르게 임포트 되었는지 확인하는 것인 수작업이 필요 합니다. 하나의 소스 트리의 헤더 파일을 수정했다면 반드시 동일한 수정사항을 다른 곳에서 적용해야 합니다.

오직 i86xpv 플랫폼에만 적용되어야 하는 코드들은 #ifdef __xpv 로 보호 됩니다.

대부분의 경우 사용자와 사용자 어플리케이션들은 그들 아래의 플랫폼에 대해서는 알 필요가 없습니다. 유저 레벨단에서 i86pc 와 i86xpv 는 완벽하게 바이너리 호환 됩니다. 만약 어떠한 플랫폼을 사용하고 있는지 알 필요가 있다면 uname -i 를 실행합니다.

5. 부팅

솔라리스를 virtualized dom0 으로 혹은 단독 운영체제로 실행시킬지는 부트 타임에서 결정해야할 문제입니다.

솔라리스를 단독 운영체제로 실행시키려면 현재 사용하고 있는 GRUB 메뉴를 계속해소 동일하게 사용하면 됩니다. 예를 들어:

        title Solaris Nevada snv_64 X86
        kernel$ /platform/i86pc/kernel/$ISADIR/unix
        module$ /platform/i86pc/$ISADIR/boot_archive
        

솔라리스를 dom0 으로 실행하라면 GRUB 은 Xen 하이퍼바이저를 부팅 시켜야 합니다. /boot/grub/menu.lst 의 기본 부트 아이템은 Xen 라인을 가르켜야 합니다. Xen 은 이제 솔라리스 인스턴스를 로드하고 부팅 시킵니다.

• 솔라리스를 Xen 에서 부팅시킬때 kernel$ 라인은 반드시 Xen 하이퍼바이저를 참고하야 합니다. 그리고 두개의 module$ 라인이 있어야 합니다. 첫번째 module$ 라인은 반드시 UNIX 경로를 두번 가르켜야 하고 라인의 제일 마지막에 어떠한 매개변수라도 지정해야 합니다 (예제에서 [*] 이 가르키는 것 처럼) 두번째 module$ 라인은 부트 어카이브의 위치를 지정해야 합니다:

  #---------- ADDED BY BOOTADM - DO NOT EDIT ----------
  title Solaris on Xen
  kernel$ /boot/$ISADIR/xen.gz
  module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix [*]
  module$ /platform/i86pc/$ISADIR/boot_archive
  #---------------------END BOOTADM--------------------
      

• 64-비트 시스템에서 Xen 의 솔라리스를 32-비트 모드로 부팅시킬때에는 $ISADIR 인스턴스를 제거 합니다:

  #---------- ADDED BY BOOTADM - DO NOT EDIT ----------
  title 32-bit Solaris on Xen
  kernel /boot/xen.gz
  module /platform/i86xpv/kernel/unix /platform/i86xpv/kernel/unix [*]
  module /platform/i86pc/boot_archive
  #---------------------END BOOTADM--------------------
  

6. 관찰 / 디버그 기능

6.1 xm

비록 하이퍼바이저와 dom0 이 밀접하게 동작하여 실행중인 시스템을 관리하더라도 dom0 운영체제에서는 하이퍼바이저를 직접적으로 들여다볼 수 있는 것이 제한 되어 있습니다. 하이퍼바이저의 전체 주소 공간은 dom0 에서 접근이 불가능 합니다. 그러므로 오직 정보는 유저 공간의 툴이면서 하이퍼콜을 통해 하이퍼바이저와 통신할 수 있는 xm 을 이용해서만 얻을 수 있습니다.

몇몇 유용한 xm 커맨드는 다음과 같습니다:

• xm info  - 머신에 대한 정적인 정보, 즉 CPU 의 갯수, 전체 메모리 용량 및 Xen 버전 정보를 보고.
• xm list  - 모든 도메인 목록과 고레벨의 정보를 출력.
• xm top   - Linux 의 "top" 커맨드와 유사하지만 프로세스 정보 대신 도메인 정보를 보고.
• xm log   - xend log 의 내용을 출력.
• xm help  - 모든 사용가능한 커맨드를 출력.
• xentrace - Xen 에서 트레이스 버퍼 데이타를 캡춰.
• xentop    - Xen 시스템 및 도메인 에 대한 정보를 주기적으로 출력.

6.2 크래쉬 덤프

실행중인 시스템에서 하이퍼바이저의 메모리는 완전히 접근이 불가능합니다. 만약 하이퍼바이저가 크래쉬되면 패닉 덤프는 Xen 과 dom0 에 대한 통합적인 뷰를 제공하는 코어 파일을 생성할 것입니다. 이러한 코어 파일에서 Xen 은 간단히 xpv 라고 불리는 솔라리스 커널 모듈로 나타나게 됩니다.

예를 들어:

                > $c
                xpv`panic+0xbf()
                xpv`do_crashdump_trigger+0x19()
                xpv`keypress_softirq+0x35()
                xpv`do_softirq+0x54()
                xpv`idle_loop+0x55()
        

명확하게 하기 위해: 만약 dom0 이 표준 솔라리스 패닉에 의해 크래쉬 되면 덤프는 오직 dom0 만을 포함할 것입니다. Xen 상태 까지 포함하는 덤프는 오직 하이퍼바이저 자신이 패닉에 걸렸을때에만 생성됩니다.

Xen 패닉을 다루는 것에 대한 좀 더 자세한 정보와 Xen 패닉을 디버깅 하는 예제는 다음의 링크를 참고하시기 바랍니다: http://blogs.sun.com/nilsn/resource/xen ··· anic.pdf.

만약 도메인이 hang 에 걸린다면 xm dump-core 를 이용해서 덤프 파일을 생성하도록 합니다. 이 파일은 /bin/mdb 를 이용해서 들여다 볼 수 있습니다. 좀 더 자세한 정보는 xm(1) 멘 페이지와 Debugging a Hung domU 을 참고하시기 바랍니다.

6.3 DTrace

하이퍼바이저와 dom0 과의 분리 때문에 현재에는 DTrace 를 직접적으로 하이퍼바이저에 적용할 수 있는 방법이 없습니다. 새로운 xpv DTrace 프로바이더가 dom0 과 하이퍼바이저간의 동작을 추적할 수 있도록 해 줍니다. 이 프로바이더는 privcmd 디바이스 드라이버에서 소개된 DT 프로브에 의해 만들어 졌습니다. 사용 가능한 프로브들은 다음의 명령을 이용 합니다: dtrace -l -i 'xpv:::'

이러한 프로브들를 자세히 이해하기 위해서는 꽤 많은 솔라리스/Xen 인터페이스에 대한 지식이 요구 됩니다. 간단히 모든 것을 활성화(dtrace -n 'xpv::: {}') 시키면 도메인을 생성하거나, 도메인을 파괴 하거나, 마이그레이션 하는 것과 관련된 단계들에 관한 고레벨의 정보를 제공합니다.


이 아티클의 영문 원본은
http://www.opensolaris.org/os/community/xen/docs/developers/
에서 볼수 있습니다.