그간 intel의 VT-d에 관심이 있었어서 VT-D가 가능한 환경을 만들려고 서베이를 좀 했다.
그러던 중에
http://wiki.xensource.com/xenwiki/VTdHowTo
에서 VT-d 가 가능한 환경을 찾았는데. xensource 에서 개발환경으로 사용되는 intel 의 마더보드가

• DQ35MP
• DQ35JO

라는 사실을 알게 되었다. 물론 몇가지 더 지원하는 시스템이 있을 것이고, Q35 칩셋을 이용하는 마더보드에서는 지원할 것이라는 어렴풋한 추측이 있기는 하지만.. 괜히 무턱대고 구입했다가 BIOS에서 이를 enable시키지 못해서 ACPI table 에서 찾지 못하게 되면.. 괜히 낭패가 될 것같아서.. 안전빵으로 갔다. (그리고 개인적으로, 옛날과는 다르게, 오버라든지 다른 메인보드의 특별한 기능을 찾을만큼 정열적이진 않아서... 돌다리도 두들겨가는 심정으로.. ^.^)

그림 1. BIOS of DQ35JO

일단 DQ35JO 메인보드를 구입했고... 책상위에 올려놓고 대충 뚝딱뚝딱 있는 부품들을 모아서 조립했다. 메모리같이 없었던 것은 선배한테 빌려서.. ㅡ.ㅡ. 아무튼 그림과 같이 해당 메인보드의 BIOS 에서

• VT Technology
• Intel(R) VT for Directed I/O (VT-d)

가 존재함을 확인했다. (사실 인터넷에서 DQ35JO의 BIOS에서 정말로 VT-d에 관한 enable이 가능한지를 찾을 수 가 없어서 답답했는데... 있어서 다행이었다.)

그리고 현재는 CentOS 5.1 를 하고 있는 중이다. 하지만 설치시 그냥 설치가 되지는 않는데... 설치시에만 pci=nommconf 옵션을 주고 설치해야 한다. 지금은 일단 설치중

아래 VMM Software Architecture Options 글에 이어지는 글로 "Intel Virtualization Technology for Directed I/O"의 한 챕터입니다.

Current I/O Virtualization (IOV) Techniques

I/O 장치를 가상화할때, 하부의 가상화 소프트웨어는 해당 장치를 위해서 몇가지 종류의 오퍼레이션을 서비스해야한다. 소프트웨어와 물리 장치들간의 interaction은 다음과 같다.

• Device discovery: 소프트웨어가 플랫폼상의 장치들을 discover, query, 그리고 configure 할 수 있는 메커니즘
• Device control: 소프트웨어가 장치와 통신하고 I/O 작업을 초기화하는 메커니즘
• Data transfers: 장치가 data를 시스템 메모리 로부터/로의 전송하는 메커니즘. 대부분의 장치들은 data를 전송하기 위해서 DMA를 지원하고 있다.
• I/O interrupts: 하드웨어가 이벤트와 상태 변경을 소프트웨어에게 알릴수 있는 메커니즘

이러한 interaction들 각각은 공통된 가상화 기술의 각각에 대해서 discussion, covering implementation, 극복점, 장점, 단점을 가지고 있다. VMM은 하나의 monolithic 소프트웨어 스택 혹은 hypervisor와 특별한 guest들의 조합이 될 수 있다.

more..

참조

1. Darren Abramson, "Intel Virtualization Technology for Directed I/O," Intel Technology Journal, Volume 10, Issue 03, August 10, 2006.

가상화 레이어 (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의 수행을 요청한다.

어제 가상화에 관심있는 친구를 만나다가 IO 관련 가상화에 대해서 이야기를 조금 해보았는데... 그러면서 궁금해진 점이 virtualization technology for directed i/o 즉 VT-d 에 관련된 부분이었다.

그래서 IOV (I/O Virtualization) 에 관련된 내용을 좀 찾아보았는데... 내용은 다음과 같았다.

Intel Virtualization Technology for Directed I/O (VT-d)

VMM은 guest 소프트웨어로부터의 I/O requests에 대한 가상화를 지원하게 된다. 이를 위해서 현재 사용되고 있는 방법은 device emulation과 para-virtualization이다. 이러한 I/O device 가상화 (IOV) 모델에서, 신뢰성과 보호 수준에서 발생하는, 요구사항은 역시나

1. VMM에 의해서 장치에 할당된 자원들에 대해서만 접근이 가능하고
2. 격리(isolate) 를 제공해야 한다는 것이다.

VT-d 는 이를 제공하기 위해서 hardware를 통해서 지원하는 가상화 기능으로

• hardware assisted remapping 을 이용하여 장치 격리를 제공하고 이를 통한 reliability 와 security의 향상과,
• 장치들에 대한 직접적인 할당으로 인한 I/O 성능과 가용성의 증대

이다.

그렇다면 hardware assisted remapping 이란 무엇일까?

VT-d 는 장치들의 DMA를 미리 할당된 도메인 혹은 physical memory region들에 한정하는 기능을 제공한다. 이를 위해서는 DMA-remapping으로 알려져 있는 하드웨어 capability를 이용하게 된다. 칩셋의 VT-d DMA-remapping hardware logic은 DMA를 지원하는 peripheral I/O 장치들과 컴퓨터의 physical memory 간에 존재하게 되고, 이를 구현하기 위해서 computer system software로서 프로그램된다. (이를 가상화 환경에서는 VMM이 지원하게 되고, 가상화되어 있지 않은 환경, 즉 native 환경에서는 OS 가 이러한 기능을 구현하게 된다.) DMA-remapping은 incoming DMA request의 address를 현재 physical memory address로 변환하고, system software에서 제공하는 정보를 기반으로 해당 physical address에 접근이 가능한지를 검사하게 된다.

Intel VT-d 는 system software가 여러개의 DMA protection domain들을 만들도록 지원한다. 각각 protection domain은 host physical memory의 일부를 할당받은 isolated environment이다. 여기서 DMA protection domain은 소프트웨어 사용 모델에 따라서 VM에 할당된 메모리로 나타나거나, 혹은 VMM의 일부로써 혹은 VM에서 수행되는 guest OS driver에 할당된 DMA memory로서 나타날 수 있다. VT-d 구조는 system software로 하여금, 하나 혹은 그 이상의 I/O device들을 하나의 protection domain에 할당할 수 있게 한다. DMA isolation은 address-translation 테이블들을 이용하여 해당 physical memory에 할당되지 않은 I/O 장치들로부터 protection domain의 physical memory로의 접근은 제한하여 제공된다. 이는 각각 가상 머신들의 컴퓨터 자원들간의 separation을 보장하도록 필요한 isolation을 제공한다.

어떠한 주어진 I/O device가 임의의 memory location을 접근하려고 할때

1. DMA remapping hardware는 해당 device로부터 임의의 protection domain에 대한 접근 허용을 위해 address-translation table을 찾게 된다.
   
2. 만약 장치가 접근이 허용되는 range 밖의 주소에 접근을 시도하면, DMA remapping hardware는 그 접근을 막고, 시스템 소프트웨어에게 fault 를 report하게 된다.

다음 Figure 1은 VT-d DMA Remapping을 보여주고 있는데, 여기서 Device-1은 Domain-C 에 할당되어 있지 않기에, Device-1이 Domain-C memory location range 를 접근하려고 시도할 경우 VT-d 하드웨어에 의해서 제한되게 된다.

여기서, 성능을 향상시키기 위해서, I/O device 들과 protection domain들간의 mapping, 그리고 DMA address translation의 page-table entries와 같은 자주사용되는 remapping-structure entries는 캐슁된다. 이에 대해서 VT-d는 Peripheral Component Interconnect Special Interest Group (PCI-SIG) Address Translation Services(ATS) 스펙을 지원하는데 이는 Endpoint Device에서 장치에 제한된 DMA translations에 대한 캐슁을 허용하는 방법을 표준화하고 있다.

I/O performance through Direct Assignment

가상화는 다수의 virtual machines을 하나의 서버에서 생성하도록 지원하고 있다. 이러한 consolidation은 server hardware utilization을 높이는 것이 사실이지만, 추가적으로 server application들의 consolidation으로 인해서 높은 I/O performance를 요구하게 된다. Software기반의 IOV 방법론들은 I/O device들의 emulation을 사용하고 있는데, 이러한 emulation layer를 이용하는 VMM은 hardware device의 VM들에 대한 일관된 view를 제공하고, 이를 통해서 물리적인 장치는 다수의 VM들에 의해서 공유되도록 지원한다. 그러나 이는 high I/O performance device들의 I/O performance를 낮추게 되는데, VT-d 는 VM에 대한 직접적인 device의 할당을 통해서 가상화된 I/O device의 native capability 와 native performance에 대한 손실에 대한 해결책을 제공하게 된다.

이 모델에서는 VMM은 device들이 해당 파티션으로의 직접적인 할당을 가능하도록 하는 제어 기능에 대해서 일부 기능만을 수행하도록 한다. 즉, 파티션이 요청하는 모든 (혹은 대부분의) I/O request들을 진행하기 위해서 VMM이 호출되기 보다는, VMM은 guest software가 system functionality와 isolation에 관련된 조작을 하게 되는 protected resources (I/O configuration accesses, interrupt management 등과 같은)에 대한 접근을 진행하기 위해서만 VMM을 호출하게 된다.

I/O device들의 직접 VM에 할당되기 위해서, VMM 은 DMA request들이 isolation되도록 강제해야 한다. 또한 이렇게 I/O device들이 도메인들에 할당될 때, DMA remapping hardware는 I/O device로부터 해당 도메인이 현재 소유하고 있는 physical memory에 대한 DMA만을 사용하도록 제한하는데 사용되게 된다.

VM 혹은 guest 가 VMM 상에서 수행될 때, Guest Physical Address (GPA)로 알려져 있는, Guest OS의 physical address range로서 제공되는 address space는 실제 Host Physical Address (HPA)와는 같지 않을 수도 있다. DMA capable device들은 physical memory location들로부터/들로의 데이터 전송을 위해 HPA를 필요하게 된다. 그러나 direct assignment model에서는 guest OS device driver는 domain의 control하에 있게되고, DMA capable device이 필요로 하는 HPA 대신에 domain에 알고있는 GPA 를 제공하게 된다. 이때, VMM 은 DMA remapping hardware의 GPA to HPA 변환정보를 이용하여 필요한 변환을 수행하게 된다. 이러한 Remapping을 이용하여, data가 현재 중간에 존재하는 software emulation layer릍 통해서 전송되는 것이 아니라 guest들의 적절한 buffer로 직접적으로 전송될 수 있게 된다.

Figure 2는 software emulation based I/O 와 hardware direct assignment based I/O 를 비교해 놓은 것이다. emulation based I/O에서는 중간의 software layer가 VM 과 device 간의 모든 I/O를 제어하는 것을 볼 수 있고, data가 emulation layer 를 통해서 device 로 전송되고 device로부터 emulation layer 로 전송되는 것을 보여준다.

direct assignment model에서는 unmodified guest OS driver가 해당 guest OS 에 할당된 device를 제어하는 것을 볼 수 있다. receive path에서 DMA remapping hardware는 guest OS driver에 의해서 제공되는 GPA를 옳은 HPA로 변환하고, 이에 따라 data는 guest OS의 버퍼로 직접적으로 전송되게 된다. VT-d 의 Interrupt Remapping 지원은 interrupt control 이 직접적으로 VM으로 할당되도록 허용하며, 이를 통해서 VMM의 overhead를 줄일 수도 있게 된다.

Intel VT-d usage models

VT-d를 지원하는 OS들과 VMM들은 I/O memory management의 VT-d functionality를 사용하여 device가 system의 기능에 영향을 줄 수 있는 delinquent DMA를 수행하는 것을 방지하여 protection domain들로부터 device들을 격리시킬수 있게 된다.

VT-d는 서버, 워크스테이션 그리고 software와 hardware의 결합에 의한 새로운 형태의 클래스에 대해서 보안을 제공하고 격리된 수행 공간인 virtual appliance라 불리는 컴포넌트를 수행함에 역시 사용될 수 있다. virtual appliance는 virus scanning과 firewall appliance 혹은 하드웨어 관리 appliance와 같이 미리 정의된 application들 그리고/혹은 service들을 위해서 최적화한 수행환경을 제공하게 된다.

가상 환경에서의 VM들은 응용단에서부터 device단까지 protection domain들로 격리시킬 수 있다. 이러한 방법은 하나의 도메인에서 발생하는 하나의 I/O device에 대한 문제가 다른 도메인들에게 문제를 발생시키는 것을 격리시킬 수 있게 되고, IT 사용자로 하여금 더욱 나은 system reliability 와 uptime을 제공할수 있게 된다.

Test와 development 환경에서도 다수의 VM들을 사용한 서버와, 가상환경에서 동작하는 공존하는 다수의 OS들를 이용한 workstation들은 work partition들을 isolate시킴으로써 장점을 취하게 된다.

Server Usage Models

많은 Server application들은 I/O-intensive 한데, 특히나 networking과 storage에 대해서는 더욱 그러하다. data center 내에서 생겨나는 중요한 I/O 요구사항들은 주로 scalability 와 performance인데, 이러한 부분은 mission-critical 응용들이 가상화된 data center server들과 infrastructure로 옮겨감에 따라서 server consolidation, reliability, 그리고 availability를 제공하기 위해서 필요하다. 또한 정부와 health-care는 동적인 health care 환경에서 mission-critical needs를 만족시키기 위해서 다수의 OS들을 제공하는 다수의 partition들에 대해서 secure I/O를 지원하고 isolation을 통해서 그 장점을 얻을 수 있다. 또한 health care에서 필요로하는 기관간의 개인 정보 보호에 관련된 보안에 대한 효과를 얻을 수 있다.

Enhancing Performance

가상화는 under-utilized server에 대해서 workload의 consolidation을 가능하게 해준다. 더욱 많은 work load가 consolidate됨에 따라서, I/O 의 사용과 bandwidth 가 많이 요구되고, I/O performance가 병목이 되게 된다. 성능을 높이기 위해서 높은 I/O 성능을 요구하는 VM에 대해서 직접적으로 전용의 고성능 I/O 장치가 할당될 수 있는데, Intel VT-d 기반의 I/O 가상화는 multi-port gigabit 그리고 10 gigabit 네트워크 아답터들과 같은 고성능 I/O 장치들로 하여금 platform상에 존재하는 다른 VM들이 고성능 장치의 동작에 영향을 주지 않도록 지원하게 된다. Intel은 PCI-SIG에서 I/O 가상화 스펙에 대해서 적극적으로 참여하고 있으며, 이는 다수의 VM들에 대해서 하나의 장치가 공유될 때에도 본연의 성능이 나오도록 지향하고 있다.

Enhancing Reliability and Security - Native OS and Server Consolidation

consolidated virtualized server들의 multiple I/O 장치들의 사용은 증가하고 있는데, 하나의 가상화된 서버에서 최대 네개의 networking 장치들이 사용되는 것이 찾기 어려운 일이 아니다. Intel VT-d 는 VMM들이 protected domain들에 대해서 이러한 device들을 isolate시킴으로써 reliability와 security 를 향상시키도록 돕게 된다.

지정된 memory range에 대해서 device들의 접근을 제어함으로써 end to end (VM to device) isolation이 VMM에 의해서 제공된다. 이는 security reliability 그리고 availability를 향상시킨다.

Device isolation은 비-가상화 플랫폼에서도 잘 적용될 수 있다. Device driver 개발자는 하드웨어 혹은 원치않는 memory range를 접근하는 device driver DMA를 debugging 하기 위해서 임의의 memory range들에 대해서 device isolation을 사용할 수 있다.

Getting around "Bounce Buffer" Conditions

Intel VT-d DMA remapping 기능을 사용한 시스템 소프트웨어는 bounce buffer conditions을 피함으로써 성능을 증가시킬 수 있다. bounce buffer들이 DMA를 수행하는 32bit device와 32bit address limitation들로 인해서 접근 불가한 physical memory range간에 사용될 때, 시스템 소프트웨어는 buffer 카피들을 수행하지 않고는 data를 high memory로의 data redirect를 사용할 수 있는데 이를 위해서 Intel VT-d DMA remapping을 사용할 수 있다.

Client Usage Models

Intel VT는 3rd party 회사로부터 필수적으로 필요한 security와 deep packet inspection과 Intel vPro technology를 이용한 desktop PC에서의 policy compliance 와 같은 activities를 위한 관리 서비스들을 수행하기 위해서 virtual appliance의 배포를 가능하게 한다. 이러한 tamper-resistant virtual appliance들은 중요한 서비스들을 위해서 더욱 secure하고 안정적인 환경을 제공하고 매우 쉽게 사용할 수 있도록 하나의 패키지에 모든 필요한 소프트웨어들을 포함하게 된다. 이러한 서비스 혹은 관리성에 있어서 VT-d는 가상 머신들을 위한 memory protections와 I/O optimization을 만족시키는 client platform을 제공하도록 isolate되고 control되는 그리고 protect되는 환경을 제공하게 된다.

VT-d based Virtual Appliances

virtual appliance는 application 그리고/혹은 서비스들을 미리정의된 집합으로써 최적화된 self-contained virtual execution environment이다. Lightweight Virtual Machine Monitor (LVMM)은 Intel VT를 사용하는 VMM으로써 두개의 수행 환경으로 client platform을 나누기 위해서 사용된다. 하나는 Windows XP와 같은 운영체제를 수행하기위한 사용자의 VM으로 video 혹은 rendering 응용들과 같은 사용자의 요구사항을 만족시키기 위한 응용, 개발과 테스트를 위한 응용, 그리고 기본적인 사무 응용들을 제공할 수 있다. 또 하나는 service partition (혹은 Server VM)으로 격리된 사용 공간에서 service OS 를 운영하게 된다. 사용자 파티션은 (예를 들어) network interface controller들을 제외한 플랫폼의 모든 장치들을 소유한다. 이때 network interface controller들은 service 파티션에 의해서 소유되는데, 이는 network traffic을 필터링하고 클라이언트 플랫폼을 위해서 다른 VM들에게 network device들을 가상화하게 된다. 서비스 파티션에서 수행되는 관리 응용들은 remote contol을 제공하여, 클라이언트 시스템을 이용해서 플랫폼의 나머지부분과 사용자 환경을 관리도록 지원한다.

Figure 3에서 보여지는 구조는 서비스 파티션이 소유하고 있는 물리적인 network interface card 드라이버를 통한 network traffic 흐름을 보여준다. 브릿지 드라이버는 서비스 파티션 네트워크 스택과 사용자 파티션 네트워크 스택 사이에 패킷들을 라우팅해준다. 사용자 파티션에서는 가상 NIC 드라이버가 사용자 파티션으로 부터 모든 나가는 패킷들을 브릿지 드라이버로 보내고 브릿지 드라이버는 패킷들을 물리 NIC 으로 전달하게 된다.

이러한 네트워킹 구조는 부정적인 네트워크 트래픅으로부터 고수준의 보안을 제공하게 된다. 또한 하나의 파티션과 VT 그리고 VT-d의 사용을 통해서 할당된 자원으로부터의 부정적인 공격을 격리시키는 능력을 제공하게 된다. VT-d 는 가상 가전 기반의 새로운 종류의 응용을 만들어내는 초석을 마련하게 된다. 아는 NIC 장치 모델이 사용자 파티션에 드러난 가상화 schema 보다 잘 동작한다. 이러한 scheme에서는 모든 사용자 파티션의 NIC 장치로의 접근은 intercept되고 부정적인 코드의 확산을 보호하도록 emulate된다.

LVMM과 서비스 파티션은 사용자 파티션에 사상된 DMA 버스 마스터링 장치들로부터 보호받아야만한다. 이러한 DMA-capable 장치들은 정차시스템 메모리에 접근할 수 있고, 의도적 혹은 비의도적으로 LVMM과 서비스 파티션 코드와 데이터구조를 hosting하고 있는 메모리 페이지에 접근(읽기/쓰기)을 할 수 있다. 이러한 접근들은 IT 보안에 문제점을 야기시키고, memory corruption으로 인해서 플랫폼이 쓸모없어질 수 있는데, VT-d 는 이러한 문제점을을 방지하는데 사용될 수 있다.

앞서 언급했듯이, VT-d 는 system memory 에 대해서 두가지 view (Guest Physical Address (GPA) 와 Host Physical Address(HPA))를 허용하고 있다. LVMM은 HPA view, system physical address space 를 유지하고, 사용자 그리고 서비스 파티션들은 그들의 관련된 GPA view 를 유지하게 된다. LVMM은 CPU로부터의 접근을 위해서 GPA to HPA 로 변환하기 위해서 shadow page tables 들을 유지하게 된다. 유사하게 VT-d DMA remapping 엔진들과 관련된 변환 테이블들을 이용하여 LVMM은 모든 DMA-지원 I/O 장치들을 위해서 GPA-to-HPA 사상을 유지하게 된다. Figure 4는 이러한 사용 모델을 나타내고 있다.

DMA 사상은 다음과 같이 동작한다:

• 모든 서비스 파티션 메모리 페이지들은 하나의 도메인에 추가되고 서비스 파티션에 사상된 DMA 장치들 (NIC들)은 오직 이러한 패이지들을 통해서만 접근이 가능하다.
• 모든 나머지 페이지들 (LVMM과 BIOS reserved를 제외한)은 사용자 파티션 도메인에 추가되고, 서비스 파티션에 사상된 페이지를 장치들을 제외한 모든 장치들 (예를 들어 iGFX, PCI/PCIe add-on 카드들 등)은 이러한 페이지들에 접근할 수 있다.
• LVMM과 BIOS reserved 영역은 VT-d 변환 페이지 테이블에서 빠져있기 때문에 가상화된 환경에 의해서 DMA 접근들로부터 보호된다.

이러한 device-to-domain 사상은 다음과 같은 장점을 같는다.

• 하나의 도메인에 사상된 I/O 장치들은 다른 도메인의 메모리에 접근할 수 없다. 예를 들어, 사용자 파티션의 PCI/PCIe add-on 카드들은 LVMM 혹은 서비스 파티션에 접근할 수 없다.
• 서비스 그리고 사용자 파티션의 장치 드라이버들은 GPA-to-HPA 사상을 파악하기 위해서 어떠한 변화 없이 동작한다. 이러한 변환은 장치가 GPA를 통해서 I/O 요청을 이슈할 때 VT-d 하드웨어에 의해서 투명하게 수행된다.
• 만약 장치가 도메인에 사상되지 않은 주소에 대해서 접근하려고 시도하는 잘못된 동작을 할 경우, VT-d 하드웨어는 fault 를 생성한다. 이러한 fault 는 LVMM에 캡춰되고 서비스 파티션에 알려진다. 서비스 파티션의 추가적인 관리 응용은 fault 의 정에 따라서 에러 메세지를 표시해주거나 platform reboot으로 초기화 등의 적절한 행동에 의한 이러한 fault 를 처리할 수 있다.

Intel VT-d requirements

VT-d 는 Intel Client, Workstation 그리고 일부 Server 에서부터 지원이 시작된다.

하드웨어

• VT-d 를 지원하는 chipset을 갖는 플랫폼

소프트웨어

• 가상환경에서 VT-d 기능을 지원하는 VMM (혹은 Hypervisor). VMM상에서 운영되는 Guest 는 수정이 필요없음.
• native OS 환경 혹은 비-가상화 환경에서는 VT-d protection 특징을 OS 에서 사용할 수 있다.

BIOS requirements for the platform

• VT-d 를 사용하도록 BIOS 에서 enabling 해주어야 함. BIOS는 VT-d capabilities (예를 들어 # of DMA remap engines etc)를 ACPI table 을 이용해서 VMM에게 드러내도록 해야한다.

결론

VT-d 구조는 완전한 application-to-I/O 장치 데이터 전송 격리를 지원하는 가상화된 환경을 생성할 수 있는 하드웨어 메카니즘을 제공한다. 이는 더욱 가용성있고, 신뢰성있고, 보안에 강한 가상 환경을 생성을 가능하게 한다. VT-d를 이용해서 소프트웨어 개발자들은 높은 가용성을 지원하고, 높은 성능을 제공하며, 증가하는 I/O 요구에 확장성있는 I/O 자원들을 완전히 보호하는 공유를 개발할 수 있게 된다.

I/O 장치 가상화를 위한 Intel 플랫폼에서의 VT-d 지원은 프로세서와 메모리 자원을 가상화하는 기존의 Intel VT 기능을 보완한다. 이를 통틀어서 VT 기술의 로드맵은 Intel 플랫폼의 가상화를 위한 완전한 하드웨어 지원을 제공하는 완벽한 솔루션을 제공한다. I/O 자원들의 가상화는 data center, enterprise, 그리고 home 에서의 새로운 사용 모델의 중요한 셋을 가능하도록 하는 중요한 step 이다.

참조

http://softwarecommunity.Intel.com/articles/eng/1416.htm

이미 한두달전 xen 3.1 이 릴리즈되었지만 아직까지도 xen 3.0.3 이 많이 사용되고 있다.

이렇게 main vendor 들이 xen 3.0.3 을 이용하고, 버젼업에 따른 추가적이지만 필요한 기능은 back-porting을 하는 점은 opensource 에 대한 전략적인 접근이 아닌가 생각이 든다. 사실 opensource community들의 활발한 versioning 을 다 따라간다는 것은 기업의 입장에서 매우 불안정한 플랫폼을 공급한다는 느낌을 줄 수 있다. 또한 개발자의 경우에 대해서도 한 플랫폼에 대해서 개발한 응용들이 언젠가 플랫폼의 version up 에 따라서 재코딩해야 하는 경우도 발생할 수 있기 때문일 것이다. (kernel 에 대해서는 매우 심각할 수 있다.)

각설하고 xen 3.0.3 은 위와 같은 이유로 아직 사용이 되고 있는데 아시다시피 xen 3.0.3 의 기본 커널은 2.6.16.29를 그 기반으로 하고 있다. 이러한 xen을 사용하려는 시스템이 e1000 드라이버를 사용할 경우 network-bridge 를 사용할 때 문제점이 발생되는 것이 일부 옛버젼에서 보이고 있다는 것이다.

이러한 문제점의 현상으로는 outgoing packet 은 문제가 없고
ssh connection 과 같은 작은 bandwidth를 차지하는 응용은 문제가 없으나
scp, wget 등을 이용하여 다른 site 로 부터 incoming packet 이 발생할 때 파일은 만들어지나 실제 전송은 이뤄지지 않는
현상이 나타난다는 것이다.

이러한 문제점이 나타난 e1000 드라이버의 version 은 7.1.9 였고, 실제 이러한 시스템에서 e1000 드라이버를 7.3.15로 version up을 하니 문제점이 해결되었다.

사족:
블로그를 만든지 꽤 오랜 시간이 흘렀지만 실재 포스팅이 몇개되질 않는다. 이는 아무래도 선천적인 게으름의 한계일 수도 있겠지만 가상화에 대해서만 포스팅하려 하는 것에 대한 문제점도 있다는 생각이 들어서~(?) 좀 주제를 다각화해볼까하는 생각도 든다. 왠지 그래야 내가 더 이 블로그를 사랑하게 되지 않을까~ 하는 생각이 든다.

- 2007년 8월 8일에 쓴 글을 블로그의 이동으로 옮겼습니다.

Vanderpool 로 알려져 있는 Intel VT (혹은 IVT)는 동일한 머신에서 동시에 가수의 운영체제가 동작할 수 있도록 하기 위해서 병렬로 동작하는 다수의 프로세스들이 있는 것과 같이 프로세서가 동작하게 만들어 주는 기술이다. 현재 이는 Intel 의 IVT, AMD의 AMD-V라는 이름으로 그 instruction set 은 다르나 기본적인 functionality 가 유사하다.

사실 virtualization technology, 즉 가상화 기술이란 전혀 새로운 기술은 아니다. 사실 시장에는 가상화를 가능하게 하는 일부 소프트웨어들이 존재하며 stanford 출신의 VMware는 그 대표적인 회사이다. 이러한 기술을 이용해서 하나의 프로세서는 병렬로 동작하는 다수의 프로세서처럼 동작한다. 또한 이를 통해서 동시에 다수의 운영체제들이 동작하게끔 지원한다.

사실 가상화와 멀티태스킹 혹은 하이퍼쓰레딩과 혼동될 수 있는데, 여기서 그 차이를 간단하게 언급하겠다. 멀티태스킹이란 하나의 운영체제가 존재하고 그 운영체제 상에서 다수의 프로그램들이 병렬로 수행되는 것을 의미한다. 그에 반면 가상화란 다수의 운영체제들을 병렬로 동작시키고 각각의 운영체제들상에서 다수의 프로그램들을 수행하게 된다. 이때 각각의 운영체제들을 가상 프로세서 혹은 가상 머신 상에서 동작하게 된다. 그리고 하이퍼쓰리등은 하나의 물리적인 프로세서를 이용하여 SMP (Symmetric Multi Processing)을 이용하여 성능을 효율적으로 사용하게 된다. (이는 프로세서가 fetch 등을 수행함에 있어서 stall 되는 stage가 존재하게 되는데 Control Unit 을 복수개로 둠으로써 ALU와 같은 Unit 을 효율적으로 사용하게 된다.) 그리고 이러한 두개의 프로세서들은 독립적으로 사용하게 되지는 않는다.

물론 만약 하나의 프로세서가 하이퍼쓰레딩과 가상화 기술을 제공한다면, 각각의 가상 프로세서는 운영체제에 SMP를 위한 시스템에 두개의 프로세서들이 존재하는 것으로 나타나게 된다.

사실 잘 살펴보면 가상화기술은 80386 이래로 지원이 된 가상 8086 (V86)모드와 같은 아이디어를 사용하고 있다. V86 모드를 통해서 병렬로 다수의 DOS 기반의 프로그램들을 수행할 수 있는데, VT는 이와 마찬가지로 병렬로 다수의 완전한 운영체제들을 수행할 수 있도록 완벽한 가상 머신을 제공하게 된다.

하지만 현재 VMware 와 같은 소프트웨어를 통해서 가상화를 지원할 수 있음에도 불구하고, “왜” 가상화 기술을 인텔은 프로세서 안에 구현해야 할을까? 이는 가상화를 컨트롤할 수 있는 새로운 인스트럭션들을 제공하는 프로세서들은 (VMM 혹은 hypervisor 라 불리우는) 컨트롤링 소프트웨어로 하여금 그 구현을 단순화 시킬 수 있기 때문이다. 그로 하여금 소프트웨어만으로 제공하는 솔루션에 비해서 높은 성능을 제공할 수 있게된다.

그럼 어떻게 동작하나?

가상화 기술을 제공하는 프로세서들은 (인텔의 경우…) Virtual Machine Extensions 혹은 VMX라 불리우는 확장 인스트럭션들을 제공한다. VMX는 다음과 같은 10개의 새로운 가상화 제한적 인스트럭션들을 프로세서 상에 구현하게 된다.

VMPTRLD, VMPTRST, VMCLEAR, VMREAD, VMWRITE, VMCALL, VMLAUCH, VMRESUME, VMXOFF, VMXON

가상화를 위해서 프로세서는 두개의 모드로 동작하게 되는데, root operation 모드와 non-root operation 모드이다. Virtual Machine Monitor (VMM) 이라 불리우는 가상화 컨트롤링 소프트웨어는 root operation 모드에서만 동작하는 반면, 가상 머신상에서 동작하는 운영체제들은 non-root operation 모드에서 동작하게 된다.

가상화 모드(root opeartion mode)로 진입하기 위해서 소프트웨어는 VMXON 인스트럭션을 수행하고 그런 후 VMM 소프트웨어를 부른다. VMM 소프트웨어는 VMLAUNCH 인스트럭션을 이용해서 각각 가상 머신에 들어가고 VMRESUME 을 이용하여 나오게 된다. 만약 VMM이 shutdown 되어 가상화 모드를 나가길 원한다면 VMXOFF 인스트럭션을 수행하면 된다.

Dell PowerEdge (PE) 1950 상에서는 통합되어 있는 Broadcom NIC들의 firmware 의 IPMI management 부분의 버그가 있다는 문제점이 이야기 되고 있다. 이는 이 포스팅을 작성하는 2006년 11월 중순에 구매된 dell 의 poweredge 에서도 마찬가지로 나타나고 있는데 이로 인해서 Xen에서 network 가 불가한 문제점이 발생한다. 이를 해결하기 위한 방법은 uiuc 의 한 위키에서 발견하였다. 해당 문제점에 대한 솔루션은 broadcom NIC 의 IPMI 관리 기능 중 문제가 발생하는 부분은 disable 하는 것으로 간단히 요약하자면 다음과 같다.

• 먼저 두개의 두개의 CD 를 준비한다 (DOS 6.22 Bootable CD, Broadcom NetXtreme II MS-DOS Utilities)
• Dos 6.22 CD로 부팅
• 부팅 후 Broadcom Utilities CD 로 갈아끼움
• R: 드라이브로 가서 Userdiag 디렉토리로 이동
• 현재 NIC 들의 상태를 확인
• 다음과 유사하게 나올 경우 이를 계속 수행하고 아니면 다른 솔루션을 찾아야 함.
• Configuration 의 앞에 나오는 MF 가 중요

Brd:Rv Bus       PCI     Spd Base     IRQ     MAC               FmwVer Configuration
1:5708C:B1 04:00:00 PCIE-4 2.5  0xF800 6          001372F8CA7A 1.8.0      MF,auto

• 내장된 NIC의 management firmware 를 disable 시킴

uxdiag -c 1 -mfw 0 -t abcd

• 만약 uxdiag -ver 커맨드를 이용하여 두번째 카드가 목록에 나올 경우, 이는 BIOS 에서 disable 시키지 않은 것으로 두번째 NIC 에 대해서도 첫번째 NIC 에 대해서와 마찬가지로 적용

uxdiag -c 2 -mfw 0 -t abcd

• 이에 대해서 uxdiag -ver의 결과는 다음과 같이 보여야 한다.

Brd:Rv Bus       PCI     Spd Base     IRQ     MAC               FmwVer Configuration
1:5708C:B1 04:00:00 PCIE-4 2.5  0xF800 6          001372F8CA7A 1.8.0      auto

• Configuration 의 앞에 나오는 MF 가 사라졌으면 완료
  CD를 빼고 reboot

ref.

Dell PE1950 NIC firmware workaround

Broadcom DOS Utility Bcom_LAN_NX2_26_DOSUtilities_A00

MS-Dos Bootable CD Image

- 2006년 11월 24일에 쓴 글을 블로그의 이동으로 옮겼습니다.

xensource wiki의 XenNetworking 페이지를 보면 Xen 에서 사용되는 네트워크에 대한 overview 를 볼 수 있다.

위 페이지에서 역시나 기본이 되는 것은 먼저 Virtual Ethernet interfaces일 것이다. Xen은 기본적으로 7개의 연결된 가상 이더넷 인터페이스들을 dom0에서 갖고 있다. 이는 내부적으로 이더넷 케이블을 연결한 것과 같은 효과를 주고 있는데, 도메인 0에 존재하는 veth0 는 vif0.0에 연결이 되게 되어 있고, 마찬가지로 도메인 0의 veth7은 vif0.7과 쌍으로 동작하게 된다. 또한 도메인 1의 veth0 는 vif1.0와 연결이 된다. veth#에는 IP와 MAC address들을 설정하고 vif#.#는 이를 bridge 에 연결함으로써 도메인들로 하여금 네트워크를 사용할 수 있게 된다.

위 두 그림에서 나타나는 바와 같이 하나의 물리 호스트 내에서는 각기 도메인들이 내부적으로 도메인 0 (정확하게는 backend ethernet 드라이버를 제공하고 있는 Driver domain)과 연결이 되게 된다.

Bridging in Xen

기본적으로 사용되는 Xen configuration인 bridging 은 모든 도메인들로 하여금 네트워크 상에서 개개의 호스트들로 나타나게 만든다. 이는 VMware workstation에서도 (생각컨데 ESX Server에서도) 마찬가지로 동작한다고 생각된다. (VMware workstation은 VMkernel이라는 OS 상에서 IO에 관련된 에뮬레이션을 제공하고 있는데 여기서도 bridge 등을 볼 수 있다.)
이를 위해서 Xen에서는 network-bridge 라는 스크립트를 이용하여 bridge 를 생성하고 physical ethernet 과 domain 0에서 사용되는 virtual NIC 를 연결하는 작업을 수 행하게 되는데 이에 대한 순서는 다음과 같다.

• 하나의 새로운 bridge 를 생성 (보통 xenbr0)
  eth0 의 IP 와 MAC address들을 virtual NIC 인 veth0 에 trasfer 함
  physical ethernet 인터페이스인 eth0 를 비활성화
  eth0 의 이름을 peth0 로 변경
  veth0 의 이름을 eth0 로 변경
  peth0와 vif0.0에 대해서 arp와 multicast 를 끄고 MAC address 를 fe:ff:ff:ff:ff:ff로 설정
  eth0 의 MAC address 를 physical 노드의 address로 변경
  bridge 를 활성화
  bridge인 xenbr0에 vif0.0를 추가
  bridge인 xenbr0에 peth0를 추가
  eth0 를 활성화

또한 unpriviledged domain이 시작할 때는 vif-bridge 스크립트를 수행함으로써 시작하게 되는데 그 절차는 다음과 같다.

• vif.0를 xenbr0에 추가
  vif.0를 활성화

하지만 현재 Xen 3.0.3 상에서까지 발생하는 문제점으로 bridge 를 생성함에 있어서 bridge 가 domain 0의 iptables에 영향을 받고 있다는 점이다. 이로 인해서 외부에서 domain 0로의 접근이 불가능해지는 경우가 발생하게 된다. 또한 migration 혹은 relocation 에서 발생하는 문제점으로써 guest domain의 netfront 드라이버가 unsolicited arp 를 아무리 보낸다 한들 bridge 상에서 arptable 을 유지하고 있기 때문에 잘못된 라우팅을 하게됨으로써 일정 시간 (실험상으로는 약 20~40초가량의…) 네트워크가 끊어지는 현상을 나타낸다.
이를 해결하기 위한 기본적인 방법은 bridge (xen 에서는 흡사 virtual switch 라고 부를만한…)에 대해서 실제 bridge 와 유사하게 ip-layer filter에 대해서 적용되지 않도록 해야 한다는 것이다. 이는 간단하게 /etc/xen/script 에 존재하는 xen-network-common.sh를 수정함으로써 가능하다.
create_bridge () {
local bridge=$1

# Don’t create the bridge if it already exists.
if [ ! -e “/sys/class/net/${bridge}/bridge” ]; then
brctl show >/dev/null 2>&1
sysctl -w “net.bridge.bridge-nf-call-arptables=0″
sysctl -w “net.bridge.bridge-nf-call-ip6tables=0″
sysctl -w “net.bridge.bridge-nf-call-iptables=0″
brctl addbr ${bridge}
brctl stp ${bridge} off
brctl setfd ${bridge} 0

위의 내용은 bridge 를 생성하는 xen-network-common.sh 의 create_bridge()의 일부를 나타내며 굵은 글씨로 표기된 부분이 추가되어야만 하는 부분이다. 단순히 bridge-nf 에 대한 조작은 fedora core 5 의 패키지에도 적용되어 있으나 bridge-nf 가 초기화되지 않는 상황에서는 동작을 할 수 있기 때문에 강제적으로 bridge-nf 의 초기화를 선행하기 위해서 brctl을 수행하여야 한다.

Packet flow in bridging

하드웨어에 도착한 패킷은 domain 0의 이더넷 드라이버에 의해서 handle되고 이는 peth0 에 나타나게 된다. peth0는 bridge 에 bind 되어 있기 때문에 패킷들은 bridge 로 전달된다. 이러한 단계는 모두 ethernet 수준에서 발생하게 된다. (사실 peth0와 bridge 에는 IP 주소가 할당되어 있지 않다.)

이제 bridge 는 패킷을 (스위치가 동작하는 것과 유사하게) 전달한다. 이에 bridge 에 연결되어 있는 vifX.Y에 대해서 bridge 는 그 MAC 주소를 기반으로 패킷을 어디에 전달할지 결정한다. 그루 vif 인터페이스는 packet을 Xen에 전달하고 Xen 은 패킷들을 vif가 가리키는 도메인에게 전달하게 된다. domain 0/U에 존재하는 대상 장치는 IP 주소를 가지고 이에 대해서 iptables 등을 통해서 filtering을 진행한다.

- 2006년 11월 21일에 쓴 글을 블로그의 이동으로 옮겼습니다.

모던한 컴퓨터들은 독립적으로 동시에 동작하는 하나의 운영체제 인스턴스들을 구동하고 있는 경량의 가상머신(VM)들을 다수에 구동시킬 만큼의 충분한 성능을 제공하고 있다. 이러한 머신 파티셔닝 partitioning) 기법은 현재 많은 문제점들이 존재하고 그에 대한 극복이 필요한데첫째로 VM은 다른 환경으로부터 고립되어 있어야만 한다는 것이고, 둘째로 다양한 응용 프로그램들의 이종성을 지원할 수 있도록 다양한 운영체제를 지원해야 할 필요가 존재하며, 셋째로 가상화로 인한 성능의 오버헤드를 최소화 하여야 한다는 것이다. Xen은 이전보다 우수한 성능과 자원 고립 (Isolation)을 지원하는 다수의 Guest 운영체제를 구동할 수 있도록 지원하는 x86 전용의 Virtual Machine Monitor (VMM)으로 GNU GPL 을 따르는 Open Source Software 이다.
본 포스팅에서는 현재 VM Technology 에 대한 소개들과 Xen의 2.0과 3.0에 대해서 소개에 대해서 간략히 기술한다. 이는 주로 Novell, Inc의 Charles Coffig의 Xen and other Virtualization Techniques를 참조하여 작성되었으며, 추가적으로 xen 관련 사이트에 존재하는 자료들을 기반으로 작성되었다.

가상화
가상화의 개요
가상화란 흔히들 다음 그림과 같이 resource user와 resource간의 direct interface를 indirect interface로 바꾸는 것이라고 이야기 한다.

Virtualization 의 개념

이는 자원을 사용할 사용자의 관점에서 보았을 때 실제 물리적으로 하나의 자원을 이용하는 것이 아니라 가상화 계층(Virtualization Layer)를 통해서 접근하게 되는 것이다. 이렇게 가상화 계층을 통한다는 것은 가상화 계층 아래의 가상 자원 혹은 실제 자원을 접근하게 될 때, 그 자원이 실제로 존재하는 것인지 아닌지를 알 수 없음을 뜻한다.

사실 가상화에 관련된 연구는 아주 오래 전부터 계속되었으며, 이를 열거하면 다음과 같다.

1959: paper: “Time Sharing in Large Fast Computers”
1961: MIT’s CTSS: time sharing on IBM 7094
1963: MIT’s project Multics: time sharing, protection, multi-user
1960’s: IBM’s M44/44X project: Hardware (7044) with VMs(44x)
1967: IBM’s 360 model 67with virtual memory. Ran CP-67 to create virtual 360s. Self-hosting
1969: UNIX
1972: VM/370
1985: research begins on Mach kernel
1995: MIT Exokernel
1998: VMWare founded, virtualizing x86
2000: Linux on zSeries
2003: Xen

일반적으로 Virtualization의 사용은 네 가지로 분류될 수 있다. 첫째로는 Sharing인데, 이러한 것은 하나의 Physical Resource를 여러 개의 virtual resources로 사용함을 뜻한다. 이의 예로서 LPAR, VM, Virtual Disk, VLAN이 존재한다. 둘째로 aggregation으로 이는 여러 개의 physical resources를 하나의 virtual resource로 사용하는 것을 뜻한다. 이의 예로 virtual disk, virtual storage pool 등이 있다. 셋째로 extension인데 이는 하나의 physical resource를 하나의 virtual resource로 확장하여 사용함을 뜻한다. 이의 예로 architecture emulators, iSCSI를 들 수 있다. 마지막으로 transparent change를 들 수 있다. 이는 physical resources를 추가 혹은 수리를 위해서 대체하더라도 virtual resources는 변화 없이 사용할 수 있음을 뜻한다.
이러한 가상화 기술의 형태는 다음 표와 같이 분류할 수 있다.

Name	Virtualized Interface	Example Implementation
Virtual Memory	Processor to RAM	Every modern OS
Storage Virtualization	Server to Physical Disk	IBM SAN VC, FalconStor, DataCore, Rhapsohy, PolyServe
Backplane Virtualization	Server to I/O Channels	eGenera, Topspin
Virtual Machines	OS to Hardware	XEN, VMWare, Microsoft Virtual Server
API Virtualization	Application to OS	Mosix, Meiosys, Qlusters
Shared Data Clustering	Application/OS to file data	IBM Parallel Sysplex, PolyServer, VAXc;iusters

이렇게 분류된 가상화 기술 중에서 본 문서에서는 Virtual Machine (VM)에 대해 기술하겠다.

VM이란 OS와 하드웨어 사이에 존재하는 계층으로서 OS 인스턴스들이 “real” 머신을 제어하고 있다고 생각하게 해주고, virtualization 계층은 하드웨어 자원들에 대한 접근을 조정해 주고 다양한 OS 인스턴스들이 하나의 서버에서 공존하게 해주며, 심지어 비호환성을 갖는 OS들도 서버를 공유하도록 지원한다.

이러한 VM의 컴포넌트들은 Virtual Machine Monitor (VMM)이라 불리는 하나의 소프트웨어 계층을 이용하게 되는데 여기서 중요한 VMM 컴포넌트들을 Virtual machine scheduler, coarse grained memory management, facilitate I/O virtualization이 존재한다.

VM 기술들은 크게 어떻게 호스트 되는가 혹은 VMM이 어떠한 interface를 제공하는가에 따라서 분류할 수 있다. 첫째로 어떻게 호스트 되는가에 따라서 분류하면 물리적 하드웨어에서 직접적으로 동작하는 IBM VM/370, VMWare ESX Server가 있고, User Mode Linux와 같이 호스트 OS에서 운영되는 VMM이 존재한다. 또한 대부분이 physical 하드웨어에서 호스트 되나 host OS의 I/O를 사용하는 Xen과 같은 hybrid VMM으로 나눌 수 있다. 둘째로 VMM에서 제공하는 interface에 따라서 분류하면 그림 2와 같이 하드웨어를 full virtualization하는 형태와 하드웨어를 부분적으로 가상화 시키는 para-virtualization의 형태가 존재하게 된다. 여기서 full virtualization은 unmodified guest os 바이너리를 운영할 수 있고, 모든 privileged instruction들을 에뮬레이션할 뿐만 아니라, 모든 것들을 에뮬레이션 해야만 한다. 이에 자원이 에뮬레이션하는 데 많은 시간을 할애해야 하기 때문에 성능은 줄 수 밖에 없다. 하지만 para-virtualization은 VMM이 미리 지정한 상황을 지원하는 API들에 의해서 보강되는 테크닉으로, guest os의 하드웨어 의존적인 부분은 고쳐져야 하지만 full virtualization보다 높은 성능을 보이게 된다.

이러한 virtualization은 Server consolidation, dynamic provisioning, virtual hosting, RAS, workload management 등에 사용될 수 있다. 이러한 상황에서 virtualization은 다음과 같은 이점들을 제공하게 된다.

Role	Benefits of Virtualization
Server Consolidation	높은 resource utilization (기본적으로 데이터센터의 CPU utilization은 10-20%임) 낮은 하드웨어 비용 작은 차지 면적 (작은 파워 소모, 낮은 쿨링 비용) 낮은 관리 비용
Dynamic Provisioning	높은 사용 유연성 워크로드 QoS의 증진 클러스터들의 재설정
Virtual Hosting	낮은 관리 비용 낮은 하드웨어 가격 낮은 다운 타임 높은 보안 (chroot, BSD jails와 비교)
RAS (Reliability, Availability, Serviceability)	Physical 머신들 사이의 live migration 하드웨어 업그레이드 & 메인터넌스 Hot swap 소프트웨어 릴리즈 마이그레이션 서비스 제공과 test를 동시에 수행 OS 종류와 릴리즈를 혼합하여 운용
Workload Management	Workload isolation QoS Vertical Applications Legacy compatibility Investment protection

현존하는 다양한 가상화 솔루션

이러한 가상화 기술을 제공하는 것들은 매우 많이 존재한다. 몇 가지를 열거하자면 Bochs, QEMU, VMWare, Xen, User Mode Linux (UML), Wine, VM/370, z/VM, Virtual PC, Rosetta, PearPC, Disco, Ensim, Simics, Mach, Exokernel, Denali, Plex86, HPAR, VPAR, Solaris zones, Virtual Iron, meiosys, chroot jails, BSD jails, Linux VServer, WABI, FX!32, JVM, Parrot, … 등이 존재한다.

대표적으로 Full Virtualization을 지원하는 Bochs는 C++로 구현된 IA-32 에뮬레이터로서 unmodified 바이너리 IA-32 OS들을 지원한다. 기본적으로 user-space application으로 동작하며, processor, memory, many devices들을 에뮬레이션하고 있으나 500배 정도 느리다는 평가가 있다. 또한 Dynamic Translation을 지원하는 Qemu는 공개 소프트웨어 프로세서 에뮬레이터로서 user mode 에뮬레이션과 full system 에뮬레이션을 지원하는데, full system emulation 모드에서는 프로세서와 다양한 주변장치들을 포함한 full system을 에뮬레이션하고 있다. 그리고 user mode emulation에서는 리눅스 호스트를 기반으로 cross compile 환경 혹은 wine windows api 에뮬레이터를 실행하는데 사용된다. Qemu는 x86, ARM, SPARC, PowerPC, S390을 지원하고 10-20배 정도 느린 것으로 평가되고 있다. 이반적으로 많은 사용자 층을 갖고 있는 VMWare는 full virtualization을 지원하면서 일부는 para virtualization을 이용하는 mixed 형태를 취하고 있다. 보통 workstation 버전은 user-space application으로, server 버전은 bare metal에서 운용되도록 지원하고 있으며 2%-90%정도의 속도 저하가 있는 것으로 보고된 바 있다. 또 하나의 VM으로 User Mode Linux는 새로운 아키텍처 리눅스 위에서 구동될 수 있도록 Linux를 포팅한 것으로 일종의 cross-architecture의 모습을 띄고 있다. Kernel의 recompile을 요구하나 applications들은 recompile을 요구하지 않는다. 워크로드에 따라서 30%~80% 성능의 저하가 있는 것으로 평가되고 있다.

The Xen Virtual Machine Monitor

Xen은 para-virtualization을 지원하는 하나의 VMM으로 5%정도의 성능저하를 갖는 것으로 VM으로서는 좋은 성능을 나타내고 있으며, 현재 2.0에서는 IA-32를 지원하고 있다. (2005년 3사분기에 릴리즈 예정인 3.0은 IA-32, IA-32+PAE, IA-64, Itanium, Power, Intel VT, AMD Pacifica를 지원할 예정임.) 또한 OS로는 현재 Linux 와 BSD 계열의 OS를 지원하고 있으며, OpenSolaris와 ReactOS가 작업 중에 있고, Intel VT와 AMD의 Pacifica의 지원을 통해서 이를 지원하지 않는 다양한 OS도 지원하게 될 예정이다.

Xen 의 간략한 구조

Xen은 para-virtualization을 구현하기 위해서 x86 아키텍처와 유사하나, privileged operation들을 위해 Xen hypercall들을 사용하는 xen_x86 아키텍처를 구현하였다. 이는 binary rewriting을 피하고, Xen으로의 privilege transition들의 수를 최소화하고, guest os에서 수정될 부분은 가능한 최소화하고 간략화 시키고 있다. Guest os에서는 기본적으로 kernel이 virtualized environment를 이해해야 하는 데, 이때 필요로 하는 것이 wall-clock time에 대응하는 virtual processor time과 real resource들을 guest os들에게 직접적으로 표출 시켜서 이용하게 된다.

x86 virtualization을 위해서, 기본적으로 Xen은 ring 0에서 구동되고, ring 1은 kernel에서 사용되며, ring 3는 user-space를 위해서 사용된다. 그리고 linear address space 중 상위 64MB를 Xen이 사용하게 되고 hypercall을 통해서 ring 0의 Xen으로 jump하게 되어 있다. MMU virtualization을 위해서는 direct-mode를 사용하고 있다. 또한 IO를 위해서 Xen IO-Spaces는 guest OS들의 특정한 h/w 장치들에 대한 접근을 Virtual PCI configuration space와 Virtual interrupts를 통해서 접근하도록 하고 있다. 그리고 장치들은 가상화되어 다른 VM들에게 Device Channel들로 나타나게 되는데, 이는 backend (BE) 드라이버들이 frontend (FE) 드라이버들로 나타나게 되고, network관련 드라이버는 일반적인 브릿징, 라우팅, iptables을 이용한다. (이를 위해서 Xen은 다른 도메인을 관리하기 위해서 권한이 부여된 Domain 0에서 호스트 되며 그 위에 unprivileged domain이 운영된다. 이를 위해서 Xen은 domain 0 에서 Xen daemon을 운영하는데, 주로 VM 설정을 기억하고 FE-BE 드라이버 매핑을 관리하게 된다.)

Xen 3.0 소개

2005년 3사분기에 Xen 3.0이 발표되었다. 기본적인 IO 에 관련된 내용은 위에 언급한 바와 같으며, 특징 역시 앞에서 언급한 바와 같다. 이중 구현적인 부분에 대해서 간략하게 소개를 하자면, x86_64 아키텍처를 지원하기 위해서 더 이상 guest os들로부터 Xen을 보호하는데 segmentation을 쓸 수 없다는 점이다. 이는 x86_64에서 더 이상 segment의 제한이 없어졌기 때문이다. 그렇기 때문에 kernel과 user 사이의 page table들의 switch를 사용하게 된다. 또한 Large Virtual Address Space를 적용하게 되었다. 현재 x86_64 아키텍처를 이용하여 최대 8TB까지의 메모리를 지원하고 있다. 그리고 SMP Guest OS를 지원하게 되는데 이를 통해 paravirtualization이 많은 이점을 낳게 된다. 특히 bad preemption 을 피할 수 있게 되며, CPU들의 auto hot plug/unplug를 지원하게 된다. 개발 당시 Xen 개발팀은 Unisys 32way에서 Xen 3.0 unstable 버전이 구동되고 있는 것을 발표했다. 또한 프로세서 수준에서의 가상화 기술인 VT-x와 Pacifica를 통해서 modification없이 windows xp/2003을 guest os 로써 운영할 수 있게 해 준다. (이는 2005년 8월에 열린 IDF에서 Xen 3.0과 Intel의 VT Technology를 이용하여 Windows XP SP2를 구동시킨 것을 시연한 것을 시초로 하고 있다.) CPU는 특정 privileged instruction들에 대한 trap들을 제공하고 MMU virtualization을 위한 shadow page table들을 제공하며, Xen이 BIOS, Ethernet, IDE and SCSI 에뮬레이션을 위한 간단한 플랫폼 에뮬레이션을 제공함으로써 일반적인 운영체제를 수정 없이 guest os로 운영이 가능하게 된다.

Relocation

현재 Xen의 큰 특징 중 하나는 relocation의 지원이다. 이는 Xen의 VM Migration을 통해서 지원되게 되는데, 이는 클러스터 레벨에서 VM이 다양하게 사용될 수 있음을 뜻한다. 실제 Migration은 하나의 물리 머신에서 다른 머신으로 VM state의 인터럽트 없이 움직이는 것을 말하는데 IP 주소가 VM을 따라 이동하기 때문에 네트워킹도 계속 가능하다. 특히 다운 타임을 최소화시키기 위해서 진행할 수 있는 live migration은 VM의 페이지를 스트리밍으로 네트워크를 통해서 VM이 동작할 때 보내기 때문에 서비스의 적용에 크게 의미 있다. 이는 다음 그림과 같은 동작흐름을 갖게 된다.

이는 Xen 노드간의 guest os의 migration을 통한 relocation을 의미하는 것으로써 실제 테스트해본 결과 클러스터 노드 간의 인지하기 어려운 down-time 안에 migration이 됨을 확인할 수 있었다. 이는 우선적으로 page들을 모두 대상 노드로 전송한 후, 대상 노드에 전송하는 동안 dirty bit 에 mark 된 page들을 다시 전송하게 된다. 이를 몇 차례 진행함을 통해서 원 노드의 guest os를 suspend 시키고 대상 노드로 옮겨간 os를 resume 시키게 된다. 이때 dirtying rate가 VM의 down-time을 결정하게 된다.

위의 그림은 Xen 노드 간에 guest os에서 quake3 server를 운영하면서 이를 relocation시킨 자료이다. 이는 quake 3와 같은 계속적으로 메시지가 발생하는 application server에서도 down-time이 100ms 이하로서 의미 있는 성능을 보여주는 것을 뜻하고 있다.

결론

OSDL 의 리눅스 커널의 관리자를 맡고 있는 Andrew Morton은 현재 server consolidation 그리고 workload management를 포함하여 가상화 기술로 인해 얻을 수 있는 기능들에 대한 수요가 크다고 말하고 있다. 또한 인텔과 AMD 역시 가상화 기술을 프로세서 수준에서 지원함을 발표하였고, 2005년 8월 말에 샌프란시스코 Intel Developer Forum (IDF) 2005에서도 xen과 인텔의 가상화 기술을 이용하여 리눅스 상에서 Xen을 이용하여 windows xp sp2를 구동하는 것을 시연하였다. (인텔의 가상화 기술을 적용한 프로세서가 올해 말 혹은 내년 초에 시장에 나올 예정이며, AMD의 Pacifica 기술이 적용된 프로세서는 2006년 전반기에 발표될 예정이다.) 그리고 많은 Linux 배포판 업체들이 Xen을 포함시킬 것을 이야기하고 있는데, RHEL과 SLES의 다음 버전에서 Xen 지원을 위한 수정이 가해질 것을 발표했다.

위에서 언급한 바와 같이 Xen은 고립된 (isolated) 환경을 지원하며, 다양한 운영체제를 지원하고, 오버헤드를 최소화한 Open Source Software이다. 가상화 기술이 적용된 다양한 응용 혹은 서비스들은 현재 우리가 가지고 있는 많은 문제점을 해결하는 데 도움을 줄 것이고 이는 결과적으로 기업환경에서 시스템 TCO를 줄이는 데 도움을 줄 것으로 예상된다.

- 2006년 11월 20일에 쓴 글을 블로그의 이동으로 옮겼습니다.