'IT/Virtualization'에 해당되는 글 3건

  1. 2015.02.02 Xen - I/O 가상화
  2. 2015.01.14 Xen - 메모리 가상화
  3. 2015.01.13 Xen - CPU 가상화

Xen - I/O 가상화


2.1 디바이스 에뮬레이션

- I/O를 가상화하는 가장 직관적인 방법은 디바이스의 기능을 소프트웨어적으로 똑같이 구현하는 에뮬레이션 방식. 하이퍼바이저는 게스트 도메인에 실제로 디바이스가 존재하는 것처럼 설정하고, 게스트 도메인은 실제 디바이스에서 동작하는 것과 똑같이 동작.

- 에뮬레이션 방식의 장점은 가상의 디바이스를 제공함으로써 게스트 도메인의 드라이버를 수정없이 그대로 쓸 수 있음. 잘 알려진 디바이스를 에뮬레이션하면 게스트 운영체제 대부분이 해당 디바이스의 드라이버를 사용할 수 있으므로 다양한 게스트 운영체제를 지원할 수 있음.


2.2 반가상화 인터페이스

- 게스트 운영체제를 수정할 수 있다면 , 좀 더 효율적으로 I/O 가상화를 구현할 수 있다. 게스트와 하이퍼바이저 사이에 I/O 디바잉스에 대한 새로운 상위 수준 인터페이스를 정의해 게스트가 직접 하이퍼바이저에 I/O요청할 수 있음.

- 네트워크 디바이스의 경우 디바이스 에뮬레이션은 모든 저 수준 I/O 명령어를 있는 그대로 에뮬레이션해야 함. 패킷 하나를 네트워크 카드를 통해 전송하려면 저 수준 I/O 명령어를 요구. 이는 에뮬레이션을 실행할 때의 오버헤드 뿐만 아니라 게스트와 하이퍼바이저 사이에 많은 수의 컨택스트 스위칭을 일으키며 발생하는 오버헤드도 많음. 반가상화를 통해 게스트와 하이퍼바이저 사이의 인터페이스를 정의할 때는 좀더 상위 수준의 인터페이스로 정의. 이렇게하면 사용자의 저 수준 I/O 명령을 send_packet과 같은 한 번의 요청으로 처리할 수 있음. 게스트와 하이퍼바이저의 컨텍스트 스위치는 한 번으로 충분하고, 디바이스 에뮬레이션을 실행할 필요도 없으므로 높은 성능의 I/O 가상화를 구현.


2.3 분리 드라이버 모델(Split Driver Model)

- I/O 가상화 구현 시 논의하는 것은 디바이스 드라이버에 대한 관점. 일반적으로 디바이스 드라이버는 운영체제를 이루는 핵심 요소이며 현존하는 많은 디바이스를 운영체제가 지원해야 하므로, 실제로 리눅스 커널에서도 디바이스 드라이버의 소스 코드가 커널의 대부분을 차지.디바이스 제어를 하이퍼바이저가 하도록 설계한다면, 디바이스 드라이버의 모든 코드를 하이퍼바이저가 유지해야 하므로 상당히 비효율적. 이미 운영체제가 가진 소스코드를 소유해야 하는 중복성 측면의 문제와 하이퍼바이저를 유지 보수하는 과정에서 대용량의 소스 코드를 허용하기 쉽지 않음. 또한 하이퍼바이저가 디바이스 드라이버를 유지하면, 디바이스 드라이버의 오동작 때문에 에러가 발생하면 시스템 전체에 영향

- 이러한 이유로 디바이스 드라이버를 하이퍼바이저와 별도로 관리하자는 분리 드라이버 모델이 등장. 디바이스 드라이버로 실제로 디바이스를 제어하는 별도의 특수한 도메인을 두도록 함.

- Xen 하이퍼바이저에서는 도메인0(DOM0)을 디바이스 드라이버를 전담하는 도메인으로 할당했고, 도메인0에서 리눅스를 구동시켜 리눅스 커널에 존재하는 모든 디바이스 드라이버를 사용할 수 있음.

- 디바이스 드라이버는 하이퍼바이저가 아닌 특정 도메인에 존재하고 하이퍼바이저가 소유한 드라이버를 사용해 직접 하드웨어 디바이스에 접근. 게스트가 반가상화 인터페이스를 사용했다면 드라이버 도메인의 반가상화 인터페이스가 게스트로부터 I/O 요청을 받아서 디바이스 드라이버로 전달. 반가상화 인터페이스를 사용하지 않았다면, 드라이버 도메인에서 디바이스를 에뮬레이션해 I/O요청을 실제 디바이스 드라이버에게 보냄.

4. 직접 접근 I/O (Direct Access I/O)

- 가상화 환경은 디바이스 하나를 여러 게스트 도메인이 공유하므로 하이퍼바이저의 적절한 중재가 필요.그러므로 게스트가 직접 디바이스에 접근하는 것은 허용할 수 없음.

- 그러나 특정 디바이스를 게스트 도메인 하나만 사용하도록 허용한다면 게스트는 하이퍼바이저의 중재 없이 직접 디바이스와 통신할 수 있을 것. 이렇게 게스트 운영체제가 직접 디바이스에 접근해 I/O를 요청하는 것을 직접 접근 I/O라고 부르며, 하이퍼바이저를 통해 직접 디바이스에 접근한다고 하여 Paththrough I/O라고도 부름.

- 직접 접근 I/O는 성능이 우수하며 실제로 가상화되지 않은 환경과 동일한 성능을 보장하기도 함. 일단 디바이스를 게스트 도메인에 할당하면 하이퍼바이저의 중재 없이도 바로 I/O를 실행하기 때문.

- 직접 접근 I/O의 단점

1) 메모리 보호: 디바이스 I/O를 직접 실행한다는 것은 직접 DMA(Direct Memory Access)연산을 실행한다는 것을 의미. 디바이스는 DMA연산으로 직접 시스템 메모리의 데이터를 읽고 쓸 수 있음. 이때 어떤 게스트에 디바이스를 할당했는데, DMA를 통해 악의적인 게스트가 임의로 다른 게스트의 메모리 영역에 쓰기 연산을 실행하면 해당 게스트는 오작동일 일어날 것.

2) 전가상화 지원: DMA 명령을 내리려면 게스트 운영체제가 머신 주솔르 알아야 함다. DMA는 직접 시스템 메모리에 접근할 때 머신 주소를 입력으로 받아 DMA를 실행하기 때문. 그러나 전가상화 게스트 운영체제는 머신 주소를 알지 못하므로 올바른  DMA요청을 실행할 수 없음.

3) 디바이스 공유: 



'IT > Virtualization' 카테고리의 다른 글

Xen - 메모리 가상화  (0) 2015.01.14
Xen - CPU 가상화  (0) 2015.01.13
Posted by jk.jeong
,

Xen 메모리 가상화


1. 메모리 가상화

-Virtual Memory


2.1 가상 메모리

- 가상 메모리를 사용하는 이유는 독립 주소 공간, 요구 페이징 등

- 가상 메모리를 구현한다는 것은 결국 메모리 주소를 속이는 것...

- CPU가 내보내는 메모리 주소, 즉 운영체제나 어플리케이션이 사용하는 주소는 실제 메모리의 물리주소가 아닌 자상 주소이다. 가상 메모리를 구현하려는 CPU 제조 업체는 저마다 하드웨어 관점에서 가상 주소를 물리 주소로 변환하는 MMU(Memory Management Unit)_라는 것을 제공.

- 가상 주소와 물리 주소와의 매핑을 결정하는 것은 페이이 테이블(Page Table). 운영체제는 가상 주소와 물리 주소 사이의 매핑 정보를 페이지 테이블에 기록. 그런 다음 CPU의 페이지 테이블 베이스 레지스터가 페이지 테이블에 기록하 메모리 주소를 등록하면, MMU는 페이지 테이블을 검색해 CPU가 내보내는 가상 주소의 실제 물리 주소를 찾아내 변화하고, 변환된 주소를 통해 메모리에 접근. 

- 페이지 테이블 구조

- x86 아키텍처 32비트 모드의 기본적인 테이블 구조이고 CPU는 32비트 주소를 사용하고, 페이지 디렉터리의 시작 주소는 CR3레이지터에 저장. 32비트 메모리 주소 중 31~22비트 까지의 10비트는 페이지 디렉터리의 인덱스로 사용, 해당 인덱스가 가리키는 페이지 디렉터리의 엔트리는 페이지 테이블의 시작 주소를 나타 냄.

- 21~12비트까지는 페이지 테이블의 인덱스로 사용하고, 해당 인덱스가 가리키는 페이지 테이블의 엔트리는 실제 물리 메모리 한 페이지의 시작 주소가 된다. 10비트의 인덱스로 2^10인 1,024개의 엔트리를 나타낼 수 있고, 32비트 머신에서 엔트리 하나는 4바이트를 차지하므로 페이지 디렉터리나 페이지 테이블 하나는 각 4KB의 페이지 크기 만큼 메모리 공간을 차지하게 됨다. 마지막으로 남은 11~0비트까지의 12비트는 4KB 페이지 안의 오프셋을 나타내고, 찾고자하는 최종 물리 주소가 된다. 12비트로 나타낼 수 있는 주소 버무이는 2^12인 4KB가 되므로 4KB로 페이지 안의 모든 주소를 가리킬 수 있음.

- 복잡한 다단계 구조로 페이지 테이블을 구성한 까닭은 MMU 구현의 효율성과 페이지 테이블의 크기와 관련. 페이지 테이블을 하나로 구성한다면 1개의 페이지 크기가 4KB인 페이지 테이블은 2^32/2^12인 1,048,576개의 엔트리가 필요. 엔트리 하나의 크기는 4바이트이므로 총 4MB의 공간이 필요. 페이지 테이블은 프로세스마다 독립적으로 하나씩 존재하므로 모든 프로세스에 이렇게 4MB의 배열을 메모리에 할당하는 일은 매우 비효율적인 방식. 모든 프로세스는 4GB의 주소 공간 중 극히 일부분만ㅇ르 사용하므로 주소 공간이 필요한 부분만 페이지 테이블을 만들어 할당 하 수 잇는 다단계 방식을 취함.


2.2 가상화 환경의 메모리 주소 체계

- 비 가상화 환경에서 물리 주소와 가상 주소라는 두 단계 주소 체계를 가진다면, 가상화 환경에서는 가상주소, 물리주소,머신 주소라는 세 단계를 가짐.

- 가상 머신에서 동작하는 게스트 운영체제는 가상화 환경에서 동작한다는 사실을 모름. 가상 머신은 가상화 되지 않은 환경에서 동작할 때와 마찬가지로 가상 주소와 물리 주소를 그대로 사용. But 가상 머신이 아는 물리 주소는 실제 물리 주소가 아니며, 하이퍼바이저의 중재 아래 실제 물리 주소로 변환해서 사용해야 함.

-  ex) 가상 머신이 사용하는 물리 주소를 그대로 사용한다면 기본적으로 운영체제는 할당된 메모리가 0번지 부터 시작한다고 생각하고 동작. 그러면 모든 가상 머신은 너도나도 0번지부터 시작하는 메모리를 사용할 것이고, 모두 같은 영역의 메모리를 사용하므로 충돌이 일어나서 정상적으로 작동할 수 없음. 하이퍼바이저가 적절히 중재를 해야함.     512MB의 메모리를 가진 가상 머신 두 개를 동작시킨다고 하면 첫 번째 가상 머신에는 실제 메모리의 0~512MB영역을 할당하고, 두 번째 가상 머신에는 513~1,024MB 영역을 할당.


2.3 섀도 페이지 테이블

- 가상화 환경의 메모리 주소 체계에서는 게스트 운영체제가 생각하는 물리 주소를 실제 머신 주소로 변환해서 사용해야 하는데, 이때 일반적으로 하이퍼바이저에서는  Shadow Page Table이라는 가상의 페이지 테이블을 사용. 운영체제가 사용하는 페이지 테이블이 가상 주소에서 물리 주소로 변환하는 정보를 저장한다면, 섀도 페이지 테이블은 가상 주소에서 머신 주소로 변환하는 정보를 저장하는 테이블 페이지. 하이퍼바이저는 머신 주소 정보를 가지므로, 섀도 테이블을 구축하고 페이지 테이블 베이스 레지스터에 섀도 페이지 테이블의 시작 주소를 등록. 그러면 MMU가 참조하는 페이지 테이블은 섀도 페이지 테이블이 되고, CPU가 생성하는 가상 주소를 머신 주소로 변경해 사용.


2.4 직접 페이지 테이블 접근

- 섀도 페이지 테이블은 메모리 가상화에 아주 적합해 보이는 방법이지만 어쩔 수 없이 오버헤드를 가짐. 게스트 운영체제 모든 프로세스의 페이지 테이블을 중복해서 가지며, 항상 게스트 운영체제의 페이지 테이블과 동기화해야 하는 등 성능 저하를 발생시키는 요인이 있음.

- 반 가상화 기법을 사용하면 게스트 운영체제의 소스 코드를 수정할 수 있으므로 섀도 페이지 테이블을 사용하지 않고도 메모리 가상화를 할 수 있음. Xen에서는 게스트 운영체제를 수정해 게스트 운영체제가 직접 페이지 테이블을 올바르게 수정하도록 변경할 수 있음.

- 가상 주소와 머신 주소사이의 주소 변환은? 게스트 운영체제는 물리주소와 머신주소 사이의 매핑 정보를 가짐. 직접 페이지 테이블에 주소를 저장할 때, 물리 주소가 아닌 머신 주소를 저장. Xen의 경우에는 하이퍼 콜을 통해서 하이퍼바이저에 테이블 수정을 요청. 하이퍼바이저는 유효한 요청인지 검사한 후 요청을 수락.

- 게스트 운영체제의 페이지 테이블은 가상 주소와 물리 주소 사이의 변환 테이블이 아니라 가상 주소와 머신 주소 사이의 변환 테이블을 가짐. MMU가 직접 게스트 운영체제의 페이지 테이블을 참조해도 정상적으로 동작하는 것. 이는 직접 소스코드를 수정해야 하는 번거로움이 있지만 섀도 페이지 테이블과 같이 중복해서 페이지 테이블을 유지할 필요가 없기 때문에 성능상의 이점.


2.5 중첩 페이지 테이즐

- 중첨 페이지 페이블은 AMD가 관련 기능을 먼저 지원. AMD-Nested Page Table/인텔-Extended Page Table.

- 기존의 가상 메모리가 가상 주소에서 물리주소로 변환하는 기능을 하드웨어적으로 구현한 것이라면, 중첩 테이블은 물리 주소에서 머신 주소로 변환하는 기능을 하드웨어적으로 구현한 것.

- CPU가 내보내는 가상 조소는 게스틍 운영체제가 구축한 페이지 테이블을 통해서 물리 주소로 변경하고, 변경한 물리 주소는 다시 하이퍼바이저가 구축한 중첩 페이지 테이블을 통해서 머신 주소로 변경해 메모리에 접근. 게스트 운영체제는 페이지 테이블을 구축할 때 섀도 페이지 테이블이나 직접 접근 방식에서 발생하던 페이지 폴트 같은 부가적인 오버헤드 없이 페이지 테이블을 구축할 수 있음. 하이퍼바이저가 게스트 운영체제를 생성할 때 할당해준 메모리의 머신 주소 정보만 중첩 페이지 테이블에 적어주면 쉽게 메모리 가상화를 할 수 있음.


'IT > Virtualization' 카테고리의 다른 글

Xen - I/O 가상화  (0) 2015.02.02
Xen - CPU 가상화  (0) 2015.01.13
Posted by jk.jeong
,

Xen CPU 가상화


1. 가상 머신 모니터? (Virtual Machine Monitor) 

- 가상 머신을 모니터링하는 소프트웨어 계층. 단순 모니터링 뿐만 아니라 하드웨어 자원 관리, 가상 머신 스케쥴링 등 가상 머신을 동작시키는 데 필요한 모든 작업을 담당.

1.1 왜 가상화인가?

-  Server Consolidation? 최초 물리 서버 머신 하나가 다수의 CPU와 대량의 메모리를 갖출 수 있게 되면서 많은 자원이 유휴 상태로 남는 경우가 많아, 이런 유휴한 상태의 서버를 머신 하나로 통합 관리하자는 요구가 생김. 가상화 기술을 이용하면 물리 서버 하나를 가상 머신 하나로 대체하고 이 가상 머신 여러 대를 강력한 성능을 가진 물리 머신 하나에서 동작시켜 시스템 자원의 효율성을 극대화.

- Isolation? 가상 머신의 격리? 웹 서버, DB서버, DNS서버 등 여러 서버를 하나의 머신 위에 동작시켜도 되지만 이를 나누어 독립된 가상 머신에서 수행시켜 줌.

- 클라우드 서비스

1.2 하이퍼바이저 종류

  1.베어메탈                                                                       2. 호스트 기반

 1) 베어메탈 방식은 하드웨어 전원이 들어오면 가장 먼저 하이퍼바이저가 부팅을 시작하게 되고, 부팅을 완료하면 관리자가 가상 머신을 생성해서 여러 개의 가상 머신이 동작. Xen/VMWare/Hyper-V

 2) 호스트 기반 방식은 호스트 운영체제가 존재하고, 그 위에서 하이퍼바이저가 동작하며 다시 그 위에 게스트 운영체제가 동작. VirtualBox/KVM 


2. CPU 가상화

2.1 에뮬레이션과 직접 실행?

- ex) 안드로이트 플랫폼의 x86 아키텍쳐인 PC에서의 실행. 에뮬레이터는 안드로이드 ARM 바이너리 이미지를 스캔해 역어셈블 과정으로 ARM 명령어를 추출. 그런 다음 추출해 낸 ARM 명령어를 x86에서 동작할 수 있도록 번역하여 소프트웨어로 만들어진 가상 머신 위에서 동작하게 함. 에뮬레이션로의 실행은 머신이나 디바이스에서 실행하는 것 보다 성능이 저하. 

- 직접 실행(Direct Execution)은 에뮬레이션의 단점을 극복하고자 바이너리 프로그램을 번역과정 없이 직접 CPU에서 실행하는, 즉 가상화 환경이 아닌 것처럼 바이너리 프로그램을 CPU가 직접 실행하게 하는 것.

2.2 특권 모드& 비특권 모드

- Privileged mode: 일반적으로 응용 프로그램은 비특권 모드에서 실행되고, 운영체제 커널은 특권모드에서 실행.

- 운영 체제는 시스템 전체를 관장하며, 하드웨어를 보호하고 관리. 어플리케이션이 하드웨어에 직접 접근할 수 없게하고, 원하는 서비스를 시스템 콜을 통해 요청하도록 규정. ex) 어플리케이션이 파일에서 데이터를 읽으려면 프로그래머는 read()라는 시스템 콜을 호출하며, 운영체제는 디스크에서 직접 데이터를 읽어 어플리케이션에 전달.

- 특권 모드와 비 특권모드를 명확히 구분하지 않으면 악의적인 프로그램이나 프로그래밍 실수로 시스템 전체의 안정성을 위협할 수 있음.

2.3 특권 명령 및 트랩

- 특권 명령은 특권 모드에서만 실행 가능한 명령어를 의미. Trap는 0으로 나누기나 디버거를 위한 중단점 등과 같이 특정 이벤트를 만나면 프로그램의 제어권이 트랩 핸들러로 넘어가는 것을 의미.

2.4 전통적인 하이퍼바이저 구현 방법

- 트랩과 에뮬레이트 방식을 통해 구현. 하이퍼바이저는 하드웨어 하나에 여러 개의 운영체제를 동작하게 하는 것이 주된 의무이므로 운영체제보다 더 높은 특권이 필요. 운영체제와 하이퍼바이저가 모두 특권 모드에서 동작한다면 여러 개의 운영체제가 동시에 특권 명령으로 하드웨어 자원에 접근할 수 있어 시스템 오류를 가져올 수 있음. 하이퍼바이저는 특권 모드에서, 운영체제는 비특권 모드에서 실행 됨. 비 특권 모드에서 동작하는 운영체제가 특권 명령을 실행할 때마다 트랩이 발생해 하이퍼바이저로 제어권이 넘어가며, 하이퍼바이저는 적절히 관련 루틴을 에뮬레이트하고 다시 제어권을 운영체제로 넘겨 줌.

2.5 바이너리 변화과 하이퍼 콜

- 바이너리 변환(VMware)은 운영체제의 코드 이미지를 하이퍼바이저가 스캔해 특권 명령과 비특권 명령의 경계가 모호한 명령어들 때문에 발생하는 오류 명령어를 찾아내고 검출. 그리고 해당 명령어를 적적히 수정하여 잘 동작할 수 있는 코드를 만들어 실행. CPU에서 직접 실행하는 방식이지만 중간에 하이퍼바이저가 번역하는 과정이 추가 됨.

- 하이퍼 콜은 반가상화 기술의 일종이며 Xen에서 사용하는 방식으로 번거롭지만 직접 운영체제의 소스를 수정하여 문제의 소지가 있는 명령어를 제거. 하이퍼바이저로 호출할 수 있는 하이퍼 콜로 바꾸어서 문제의 소지가 있는 명령어가 실행될 시점에 하이퍼바이저로 제어권이 넘어가게 됨. 하이퍼바이저는 게스트 운영체제의 요청을 받아서 적절히 처리한 다음 다시 게스트 운영체제로 제어권을 넘김.

2.6 하드웨어 지원

- 가상화 기능을 CPU에 추가 시킴. 인털의 VT-x, AMD의 SVM(Secure Virtual Machine) 벤더마다 약간의 아키텍쳐적인 차이점은 있겠으나 전반적임 개념은 비슷. 게스트 운영체제의 소스 코드를 수정하거나 바이너리 변환 방법 없이도 트랩과 에뮬레이트 방식으로 하이퍼바이저를 구현할 수 있도록 하드웨어적인 기능을 추가.

    인텔 VT-x : 하이퍼바이저를 위한 root모드와 게스트 운영체제를 위한 non-root모드. 게스트 운영체제는 non-root모드의 특권 모드에서 동작, 어플리케이션은 non-root 모드의 비특권 모드에서 동작. 문제가 될 수있는 명령어가 non-root 모드에서 실행되면 트랩이 발생하고 root모드로 변경되어 하이퍼바이저로 제어권이 넘어가도록 구현.

3. Paravirt Operation & 하이퍼 콜

3.1 반가상화(Para Virtualization)

- 운영체제의 소스 코드를 수정해서 가상화 구현. 이를 통해 운영체제와 하이퍼바이저 사이의 협력을 극대화한 가상화 시스템의 고성능화를 구현.

- Xen: 하이퍼 콜 인터페이스, VMware: VMI인터페이스, 

3.2 Paravirt Operation

- 가상 솔루션 벤더마다 반가상화 인터페이스를 따로 만들어 리눅스 커널을 수정 -> 소스코드의 복잡성과 관리 문제

- 해결을위해 리눅스에서 공통 API를 제공하고 각 하이퍼바이저 벤더는 여기에 맞춰 인터페이스를 제작할 수 있도록 구현한 것이 Paravirt Operation(Pv-ops)

 

- 리눅스 커널의 가상화는 필요한 루틴에 공통 API를 만들어 여기에 하이퍼 콜 혹은 VMI인터페이스를 연결하는 방식으로 구현. 최초 Xen은 리눅스 2.6.18 커널을 대폭 사정하여 Xen Linux를 만들었고 이를 Pv-ops에 맞도록 포팅. 


1. 코드 Paravirt Operation 자료 구조.txt

* 첨부 참조 *

- paravirt_patch_template라는 구조체는 기능별로 세부 ops 구조체를 가지며 pv_cpu_ops 구조체는 CPU와 직접적인 관련이 있는 명령의 모임. read/write cr0, cr4 같은 명령어는 paravirt operation으로 대체할 수 있음, CR0와 CR4레지스터는 x86아키텍쳐에서 주요한 시스템 플래그를 모아놓은 Control Register이고, 페이징 활성화, 캐시활성화, 세그멘테이션 활성화 등 주요 설정을 할 수 있는 레지스터.

...

중 략 (추후)

...


3.3 하이퍼 콜

- Xen의 Hypercall 인터페이스는 일반 운영 체제의 시스템 콜과 방법이 비슷함.

1) x86아키텍쳐에서 리눅스가 시스템 콜을 호출하는 방법

- 프로그래머가 시스템 콜을 사용할 때는 보통 glibc와 같은 라이브러리를 통해서 호출. 이때 사용자가 호출하는 것은 실제 시스템콜이라기 보다는 라이브러리에서 제공하는 시스템 콜 래퍼(wrapper)함수이며 라이브러리 루틴에서 실제로 시스템 콜을 요청하는 명령어를 사용. 

- Xen에서는 SYSCALL/SYSRET 명령이라도 사용자 프로세스가 호출한 시스템 콜인지 케스트 운영체제가 호출한 하이퍼 콜인지를 구분해서 처리

...

코드

...


4. 하드웨어 지원

- x86아키텍쳐는 포펙과 골드버그의 가상화 요구를 만족하지 않으므로 가상화 프로그램 구현이 복잡. Xen의 경우 특권 명령을 하이퍼 콜로 요청하는 수정한 커널을 사용하는 반가상화를 기반으로함. 윈도우와 같이 커널을 수정할 수 없는 운영체제는 전가상화(Full Virtualization)을 통해서 지원.

- Xen에서의 전가상화는 HVM(Hardware Virtual Machine)을 통해서만 가능.HVM은 CPU에서 가상화 기능을 제공하는 하드웨어적 가상화 기술을 의미.인텔:VT-x / AMD: SVM

- 성능상의 이점과 하이퍼바이저 구현이 쉬워진다는 이유로 HVM을 활용. 

4.1 인텔 VT-x 개요

- VT-x는 가상화를 지원하는 새로운 개념인 VMX Operation이존재- 하이퍼바이저와 가상 머신이 동작하는 환경 구분

- VMX root Operation: CPU나 하드웨어의 모든 제어권을 가진 오퍼레이션.

- VMX non-root Operation: 특정 명령어 실행과 하드웨어 제어권한이 일부 제한된 오퍼레이션 (Virtual Machine)

- VMX root Operation과 non-root Operation이 서로 전환하는 것을 VMX 전환이라고 함.

- VM Entry: VM root오퍼레이션에서 VM non-root오퍼레이션으로 진입하는 VMX 전환

- VM Exit: VM non-root 오퍼레이션에서 VM root 오퍼레이션으로 빠져나가는 VMX전환

- 가상 머신은 VMX non-root 오퍼레이션에서 동작중이더라도 기존 네이티브 시스템과 같다고 인식. 특권 명령을 실행하면 VM Exit가 발생해 VMX root 오퍼레이션으로 전환. 그런 다음 VMX rot 오퍼레이션에서 하이퍼바이저가 특권 명령을 처리한 뒤에는 VM Entry로 다시 가상 머신에 진입.

-  VMX non-root 오퍼레이션의 프로세서 동작은 가상화가 쉽도록 제한. VMX non-root 오퍼레이션에서 가상 머신이 VMCALL과 같은VMX명령어를 실행하거나 특정 이벤트가 발생하면 VM Exit가 발생해 하이퍼바이저로 제어권이 넘가감. 특정 명령어를 실행했을 때 VM Exit가 발생하므로 VMX non-root 오퍼레이션의 동작은 제한적. CPU리소스는 VMX root 오퍼레이션에서 하이퍼바이저가 보두 관리.


4.2 VMX 오퍼레이션 라이프 사이클

1) 하이퍼바이저에서 VMXON명령어를 실행하여 VMX오퍼레이션으로 진입.                                                         2) VMLAUNCH와 VMRESUME명령어를 사용하면 VM Enrty가 발생해 하이퍼바이저는 가상 머신이 동작하는 VMX non-root 오퍼레이션으로 진입.                                                                                                                 3) 가상 머신이 실행 중에 제한되어 있거나 특정 명령어를 실행하거나 이벤트가 발생할 때는 VM Exit가 발생해 하이퍼바이저에 설정된 특정 한 엔트리 지점에 진입. 그러면 하이퍼바이저는 VM Exit가 발생한 원인에 따라 적절히 특권 명령을 처리한 뒤에 다시 가상 머신으로 VM Entry를 발생시 킴.                                                                             4) VMXOFF명령어를 실행해 VMX오퍼레이션을 빠졈 나옴.


4.3 VMCS (가상 머신 제어 구조)

- VMX non-root 오퍼레이션과 VMX전환을 제어하는 용도로 VMCS(Virtual-Machine Control Structure)라는 별도의 자료 구조가 존재. 인텔 VT-x를 사용하는PCPU마다 하나씩 존재하는 VMCS포인터(VMPRT)로 접근. VMPTRST명령어를 사용해 현재 VMSC포인터를 메모리에 저장하고, VMPRTLD명령어를 사용해 VMCS포인터를 설정할 수 있음.

...

VMX 활성화 ( )

...


5. 가상 머신 스케줄링

- 가상화 환경에서는 물리 머신 하나에 여러 개의 가상 머신이 동작. 실제 물리 머신에는 여러 개의 물리 CPU가 존재하고 가상 머신이나 가상의 CPU를 가지게 되는데 이것을 VCPU(Virtual CPU)라고 한다. 

- 가상 머신 스케줄링이란 물리 CPU에서 실행할 VCPU를 어떤 스케줄링 정책을 통해 선택하는 것. 일반 운영체제에서 스케줄러가 CPU에서 동작할 프로세스를 선택하는 과정처럼 가상화 환경에서는 스케줄링 대상이 VCPU가 됨.

- 가상화 환경에서는 다수의 가상 머신을 통합해서 운용하므로 실제 CPU보다 더 많은 VCPU가 존재. 따라서 스케줄럭가 어느 순간에 어떤 VCPU를 얼마만큼 실행시킬지를 결정하는 일이 시스템 전체에 큰 영향을 끼침.


5.1 Xen 스케줄러

...

...


* BOOST 우선 순위

- 운영체제는 I/O 이벤트 방식으로 동작. 하드디스크를 읽으려고 읽기 요청을 하면 하드디스크가 해당 블록의 내용을 전송할 때까지 기다리는 것이 아니고, 다른 작업을 실행하거나 혹은 잠들어 있다가 하드디스크로부터 전송 완료 이벤트(인터럽트)가 발생하면 요청을 실행.웹 서버의 경우 블록 상태 였다가 외부 요청이 오면 이벤트를 받고 깨어나기도 함.

- Xen은 I/O처리를 드라이버 도메인이라는 특정 도메인이 처리. 외부 인터럽트가 발생하면 드라이버 도메인이 깨어나서 해당 인터럽트를 처리. 블록 상태였던 VCPU가 빨리 깨어나서 작업을 실행하면서 시스템 전반적으로 반응 속도가 높아지며, 이렇게 깨어난 VCPU에 한해서 일시적으로 우선순위를 BOOST로 만들면 빨리 스케줄링 되어 실행할 수 있게 만들어 줌.

* 블록 처리

- 게스트 운영체제에서 더 처리할 작업이 없어서 유휴 상태가 되면 하이퍼바이저에 VCPU를 더는 실행하지 말라고 알려 주어야 함. 게스트 운영체제가 반 가상화 상태면 직접 하이퍼 콜을 통해서 하리퍼바이저에 블록 처리를 명령할 수 있고 게스트 운영체제가 전가상화라면 직접 하이퍼바이저에 명령할 수 없으므로 하이퍼바이저 스스로 게스트 운영체제의 halt 명령어를 감지해 블록 상태를 만듦. 운영체제 대부분은 유휴상태가 될 때 x86의 halt 명령어를 실행해 VM Exit를 발생시켜서 하이퍼바이저에 유휴 상태임을 알림. 하이퍼바이저는 VCPU를 블록 상태로 만들고, 스케줄링 이벤트를 발생. 곧 cshed_schedule() 함수 호출 - 블록 상태인 VCPU는 runq에 삽입되지 않으며 깨진 전까지 실행 안 됨.

...

5.6 cpupool

- Xen 4.1 ~ 관리자는 여러 개의 스케줄러를 하나의 머신 위에서 구동. CPU별로 그룹 짓고 특정 스케줄러로 해당 그룹이 동작하게 끔 설정.

- cpupool이 다르면 PCPU가 휴면 상태가 되더라도 다른 cpupool에 할당된 가상 머신 VCPU를 자져와서 실행하지 못함.

- cpupool 자료 구조: 모든 PCPU에는 percpu변수를 통해 해당 cpupool 구조체를 가리키는 포인터가 있음. percpu 변수는 각각 자신이 속한 cpupool을 가리키며 cpupool 구조체는 자신이 가지는 CPU를 스케줄링할 Scheduler 구조체를 가리킴. cpupool_list라는 전역 리스트는 모든 cpupool을 리스트로 엮는다.


출처: Xen으로 배우는 가상화 기술의 이해 'CPU 가상화' 편

'IT > Virtualization' 카테고리의 다른 글

Xen - I/O 가상화  (0) 2015.02.02
Xen - 메모리 가상화  (0) 2015.01.14
Posted by jk.jeong
,