v12n for Mobile :: VMM Software Architecture Options

2008/02/28 10:56

VMM Software Architecture Options wkoh+virtualization2008/02/28 10:56

가상화 레이어 (VMM) 소프트웨어 구조는 세가지 종류로 나워지는게 일반적이다

OS-hosted VMMs
Stand-alone hypervisor VMMs
Hybrid VMMs

위에서 언급한 세가지 VMM 소프트웨어 구조 각각은 나름대로의 장점과 단점을 갖고 있고, 이는 주어진 사용 모델 혹은 시장 세그먼트에 따라서 선택되어야 한다.

OS-hosted VMMs

VMM 소프트웨어 구조로의 한 접근방법은 기존에 존재하는 OS의 인프라 위에서 구현되는 것이다. Figure 1의 VMM에서 보이는 바와 같이 이러한 OS-hosted VMM은 호스팅 OS의 커널 옆에서 수행되고 CPU와 시스템 메모리와 같은 시스템 자원의 제어를 얻어서 하나 혹은 그이상의 guest OS 들을 위한 수행 환경을 생성하는 privileged ring-0 콤포넌트로 구성된다. host-OS 와 guest-OS간의 VMM 커널의 컨텍스트 스위치는 쓰케줄링 정책에 기제되어 있는 주기적인 인터벌에 따라서 혹은 host-OS 의 지원이 필요로 하는 (예를 들어 host-OS 장치 드라이버로 프로그램된 물리 I/O 장치로부터의 하드웨어 인터럽트를 서비스한다던지...) 때 이뤄진다. guest OS 가 물리 CPU상에서 직접적으로 수행되고 VMM 커널의 제어를 받아 host physical 메모리의 특정부분을 직접적으로 수행되는 것이 허용되더라도, I/O 장치들로의 어떠한 접근이든지 기본적으로 VMM 커널에 의해서 인터셉트를 받게되고 VMM의 사용자 수준의 컴포넌트에 의해서 대행된다. (Figure 1의 ULM에서 나타나 있다.) TLM은 host OS의 일반적인 프로세스로 동작하고, guest OS 들로부터 발생하는 I/O 요청에 대해 서비스하는 가상 I/O 장치 모델을 포함하고 있다. ULM 내의 장치 모델은 guest OS들로부터릐 I/O 요청을 조작하는 파일시스템과 네트워킹, 그리고 그래픽 API를 통해서 하부의 host OS의 수행을 요청한다.

Figure 1. OS-hosted VMM

OS-hosted VMM 구조는 다수의 장점을 제공한는데,

VMM이 host OS 를 위해서 개발된 어떠한 I/O 장치 드라이버든지 사용이 가능하다는 점으로, 이는 서로 다른 physical host platform들로의 VMM 포팅이 쉽다는 것을 의미한다.
게자가 VMM은 host OS에서 제공하는 다른 기능들을 이용할 수 있다. 예를 들어 host platform의 전력관리 기능을 관리한다던지, I/O 자원의 발견을 한더던지 하는 scanning I/O bus를 위한 코드등을 사용할 수 있다.

OS-hosted VMM 의 단점은 신뢰성, 가용성, 보안 등의 이슈가 모두 host OS 에 의해서 결정된다는 점이다. 만약 host OS 가 실패하거나 (일련의 문제로) 무조건 reboot 되어야 한다면 오든 다른 guest OS 들이 서비스를 할 수 없는 상황에 처한다는 점이다. OS-hosted VMM은 또한 VMM과 그 guest OS 뿐만이 아니라 host OS에서 운영되는 다른 응용들과 같이 host OS의 CPU 스케줄링 정책에 의해서 동작한다는 점이다. 만약 주어진 사용 모델이 보안, 가용성, 혹은 실시간 QoS에 관련된다면, 이러한 단점은 허용될 수 없게되기 때문에, 다른 VMM 소프트웨어 구조를 고려해야 할 것이다.

Stand-Alone Hypervisor VMMs

또하나의 대안이 될수 있는 접근은 VMM을 독립적으로 동작하는 hypervisor 의 형태로 구현하는 것으로써 이는 hosting OS에 의존하지 않게 된다. hypervisor 스타일의 VMM은 VMM 자신이 소유하는 I/O 장치 드라이버들, 장치 모델들, 그리고 스케줄러를 포함하고 있다.

hypervisor 스타일 VMM은 guest OS들의 QoS 만족과 스케줄링을 지원하도록 physical platform 자원들의 provisioning을 완전히 제어할 수 있다. hypervisor 스타일 VMM의 추가적인 장점은 I/O 서비스를 위해서 guest OS 요청으로부터 실제 physical I/O 장치 드라이버까지의 코드 패스가 OS-hosted VMM에 비해서 짧다는 점인데, I/O 요청을 수행함에 있어서 두 I/O 스택 (첫째로 guest OS 의, 그리고 두째로 host OS 의 )만을 필요로 한다. 게다가 hypervisor 커널의 사이즈를 제어하고 제한을 둠으로써 VMM은 확장된 보안과 더욱 작은 Trusted Computing Base (TCB)를 제공할 수 있게 된다.

Figure 2. Stand-alone Hypervisor VMM

hypervisor 스타일 VMM의 단점은 제한된 이식성의 손실이라는 점에서 기인하는데, 이는 어떠한 주어진 physical platform을 위해 필요로 하는 I/O 장치 드라이버들이 hypervisor 내에서 개발되어야 한다는 점이다. ACPI 기반의 시스템 전력 관리 (host VMM에서는 host OS의 것을 이요하기만 하면 되었던)와 같은 고급 시스템 기능을 역시 hypervisor 스타일 VMM 상에서도 재구현으 되어야 한다. 현재로서는 full modern OS만큼 복잡하지는 않지만, 성숙한 hypervisor기반 VMM은 시간이 지날 수록 훨씬 큰 사이즈로 커져가고 있고, (예를 들어, TCB 의 사이즈 제한을 통한 향상된 보안 과 같은) 앞에서 언급한 장점들을 조금씩 만족시켜가고 있다.

Hybrid VMMs

hypervisor 스타일 VMM구조의 보안과 신뢰성의 장점을 유지하면서 동시에 OS-hosted VMM 에서 처럼 존재하는 OS와 그에 관련된 장치 드라이버의 장점을 적용하기 위해서 일부 VMM들은 hybrid 접근법을 선택했다.

Figure 3. Hybrid VMM

hybrid VMM 구조에서는 작은 hypervisor kernel (Figure 3에서 보이는 μ-Hypervisor)은 CPU와 메모리자원들을 제어한다. 하지만 I/O 자원들은 deprivileged 서비스 OS에서 동작하는 장치 드라이버들로 구현된다. VMM 안의 host OS의 장치 드라이버들과 유사한 방식으로 서비스 OS 는 동작하며 VMM은 기존의 존재하는 장치 드라이버들을 도입할 수 있게 된다. 이는 서비스 OS 가 μ-Hypervisor에 의해서 deprivileged되어 있다. 또한 VMM을 지원하면서 단독으로 동작하기 때문에 시스템 전체적으로 보안과 신뢰성 향상을 가능하게 한다.

hybrid VMM 구조는 hosted 와 hypervisor 스타일의 VMM의 좋은 성격만을 유지하여 제공하는 반면 새로운 문제점을 가지게 된다. μ-Hypervisor를 통해서 guest OS 와 service OS간에 잦은 privilege 수준의 transition으로 인한 새로운 성능 오버해드 등이 문제점으로 나타난다. 게다가 service OS 의 권한을 뺏은 (deprivilege)것에 대한 장점은 μ-Hypervisor를 통해서 장치 DMA 를 제어하는 하드웨어 지원을 통해서만 가능해진다는 점이다. 이러한 지원을 위해서 VT-d 와 같은 기술들이 사용된다.

참조