하이퍼바이저

**하이퍼바이저**(hypervisor)는 호스트 컴퓨터에서 다수의 운영 체제(operating system)를 동시에 실행하기 위한 논리적 플랫폼(platform)을 말한다. 가상화 머신 모니터 또는 가상화 머신 매니저(virtual machine monitor 또는 virtual machine manager, 줄여서 VMM)라고도 부른다.
# 분류
하이퍼바이저는 일반적으로 2가지로 나뉜다.IBM 시스템 가상화 (영문), IBM Corporation, Version 2 Release 1 (2005), publib.boulder.ibm.com - description of basic concepts * **타입 1** (native 또는 bare-metal) 운영 체제가 프로그램을 제어하듯이 하이퍼바이저가 해당 하드웨어에서 직접 실행되며 게스트 운영 체제는 하드웨어 위에서 2번째 수준으로 실행된다. 이런 방식의 하이퍼바이저는 1960년대 IBM이 개발한 CP/CMS에서 시작되었으며 IBM의 z/VM으로 이어졌다. 최근에는 Xen, Citrix의 XenServer, VMware의 ESX Server, L4 마이크로커널, TRANGO, IBM의 POWER 하이퍼바이저(PR/SM), 마이크로소프트의 하이퍼-V, 패러럴서버, 썬의 로지컬 도메인 하이퍼바이저 등이 있다. 또 히타치의 Virtage 하이퍼바이저같이 플랫폼의 펌웨어에 하이퍼바이저를 넣기도 하며 KVM은 하이퍼바이저 안에 완전한 리눅스 커널을 넣었는데 이것도 타입 1이다. * **타입 2** (hosted) 하이퍼바이저는 일반 프로그램과 같이 호스트 운영 체제에서 실행되며 VM 내부에서 동작되는 게스트 운영 체제는 하드웨어에서 3번째 수준으로 실행된다. VM의 대표적인 종류는 VMware Server, VMware Workstation, VMware Fusion, QEMU, 마이크로소프트의 버추얼 PC와 버추얼 서버, Oracle(SUN)의 버추얼박스, SWsoft의 Parallels Workstation과 Parallels Desktop이 있다. 하이퍼바이저란 System/370의 CP-67을 재작성한 CP-370에서 유래되었으며 1972년 VM/370으로 발표하였다. 하이퍼바이저 콜(hypervisor call), 곧 하이퍼콜(hypercall)이란 게스트 운영 체제가 (보다 높은 수준의) 제어 프로그램에서 직접 서비스에 접근할 수 있는 반가상화(paravirtualization) 인터페이스로 인용된다. - (같은 수준의) 운영 체제에서 감시자 호출(supervisor call)을 요청하는 것과 비슷하다. (슈퍼바이저란 IBM 메인프레임에서 감시 프로그램 상태로 실행되는 운영 체제 커널을 말한다.)
# 메인프레임
메인프레임의 경우, 최초의 하이퍼바이저로 1967년 1월 제작된 IBM의 CP-40은 전가상화(Full virtualization) 기능을 제공하였는데 IBM CP/CMS 운영 시스템의 첫 번째 버전이 되었다. CP-40은 가상화 기능을 지원하게끔 개조된 전용 S/360-40에서 실행되었다. 그 이전부터 컴퓨터 하드웨어는 여러 개의 사용자 응용 프로그램을 실행하기에 충분한 가상화가 이루어지고 있었다. CP-40에서 하드웨어의 감시 프로그램 상태(supervisor state) 또한 여러 개의 운영 체제가 동시에 실행할 수 있을만큼 가상화가 되어 있었다. CP-40은 곧 전가상화 기능을 가진 첫 컴퓨터 시스템이었던 IBM System/360-67용의 CP-67로 다시 작성되었다. 이 머신은 1966년 첫 출하를 시작했는데 가상 메모리를 위한 페이지 변환 테이블 하드웨어를 내장하고 있었으며 입출력과 인터럽트 핸들링을 포함한 모든 커널 작업들의 전가상화하기 위한 기술들이 사용되었다. (이것들은 정식 운영 체제에 해당하는 것으로 운이 없었던 TSS/360은 전가상화를 사용하지 않았다.) CP-40과 CP-67은 둘다 1967년부터 사용되기 시작했다. CP/CMS는 1968년에서 1972년까지 IBM 고객에게 별도의 지원 없이 소스 코드 형태로 제공되어 쓰였다. CP/CMS는 메인프레임으로 강력한 시분할 시스템을 구축하기 위한 시도 가운데 하나였다. 여러 개의 운영 체제를 동시에 실행시키기 위해 하이퍼바이저는 견고성과 안정성을 증가시켰다. 하나의 운영 체제가 중단되더라도 다른 운영 체제가 중단 없이 작업을 계속 할 수 있었다. 확실히 이것은 안정된 메인프레임 시스템에서 시스템을 위험에 빠트리거나 추가 개발 시스템 없이 새로운 하드웨어나 운영 체제 개발, 디버그를 할 수 있었다. IBM System/370 시리즈는 1970년 가상화 기능이 없이 발표되었으나 1972년 추가되었으며 그 이후 모든 후계 시스템에서 찾아 볼 수 있다. (zSeries같은 오늘날의 모든 IBM 메인프레임은 1960년대의 IBM S/360 시리즈와 하위 호환성을 가지고 있다.) 1972년 발표에 S/370용 CP/CMS의 재이식에 VM/370도 포함되었다. CP/CMS과는 달리 IBM은 몇가지 릴리즈의 이전과 같은 소스 코드 형태로 배포하긴 했지만 이 버전의 지원을 제공하였다. VM은 가상 머신(Virtual Machine)을 의미하며 하드웨어 인터페이스를 가상화했다는 점이 강조되었다. VM과 CP/CMS은 모두 대학이나 기업 사용자, IBM과 같은 시분할 제조업체에게 일찍부터 채택되어 빠른 개발 작업에 사용되었다. 사용자는 개발을 진행하는 동안 능동적으로 역할을 하였는데 현재의 오픈 소스 프로젝트에서 보이는 추세를 예상시켰다. 그러나 연속된 논쟁과 호된 경쟁 속에서 IBM의 내분으로 시분할은 일괄 처리(batch processing)에 밀려났으며 VM은 MVS가 사라진 지 수십 년이 지났으나 IBM의 다른 메인프레임 운영 체제에 남아있다. 다시 인기를 얻어 최근에 zSeries의 리눅스 플랫폼과 같은 기존의 z/VM에 지원되고 있다. 위에서 말한 것과 같이 VM 제어 프로그램은 가상머신 속의 DIAG(진단) 명령어를 가로채는 하이퍼바이저 콜 핸들러를 포함하고 있으며 이것은 파일 시스템 액서스 같은 가상화되지 않은 작업을 실행하는 데 빠른 경로를 제공한다. (DIAG는 모델 의존적인 특권 명령어로 보통 프로그램에 사용되지 않으며 가상화도 되지 않는다. 그래서 호스트 운영 체제로 신호를 보내는 용도로 사용된다.) CP/CMS이 release 3.1으로 처음 재작성되었을 때 DIAG를 사용하여 System/360 SVC(supervisor call) 명령어와 유사한 운영 체제 인터페이스를 제공하였는데 SVC의 시스템 가상화 때문에 시스템을 수정하거나 확장할 필요는 없었다.
# 서버
몇 가지 요인이 유닉스나 리눅스 서버 제조업체들이 가상화 기술을 다시 사용하게 만들었다. * 하드웨어 능력의 확대로 한 컴퓨터에서 동시에 작업할 수 있는 양이 증가하였다. * 서버를 통합하여 비용이 줄고 관리를 간소화하였다. * 서버 저장소나 렌더 저장소 같은 대규모 멀티프로세서와 클러스터 장비를 제어할 필요가 있었다. * 하이퍼바이저 아키텍처로 인해 보안성, 신뢰성, 장비의 독립성이 증가하였다. * 특정한 운영 체제에 의존적인 응용 프로그램을 다른 하드웨어나 운영 체제 환경에서 실행시킬 필요가 있었다. 대형 유닉스 제조업체인 선 마이크로시스템즈, HP, IBM, SGI는 2000년 이전부터 가상화된 하드웨어를 판매하고 있었다. 이것들은 보통 크고 무거우며 비싼 가격표(하이엔드의 경우 수백만 달러)를 달고 있었고 가상화도 IBM의 System-P 서버, 선의 CoolThreads T1000, T2000, T5x00 서버, HP 9000 Superdome 시리즈 같은 몇가지 중형 시스템에서나 사용할 수 있었다. 썬의 로지컬 도메인 하이퍼바이저 같이 다수의 호스트 운영 체제는 게스트 운영 체제를 실행하기 위해 변경되었다. 2006년 후반 솔라리스, 리눅스(우분투와 젠투), FreeBSD는 하이퍼바이저 상에서 실행되도록 이식되었다. (그리고 완전 가상화로 게스트 운영 체제에서 독립되어 같은 프로세서에서 동시에 실행할 수 있었다.) Wind River의 Carrier Grade Linux 또한 선의 하이퍼바이저에서 실행하기 위한 계획에 있다. SPARC 프로세서에서 전가상화는 어렵지 않다. 그 이유는 SPARC 아키텍처가 1980년대 중반부터 가상화에 방해되는 낡은 구조를 제거하기 시작했다. (아래의 x86 프로세서에서의 가상화와 비교해 보자.) IBM의 매우 비슷한 기술로는 logical partitioning(LPAR)으로 알려진 것으로 System/390, zSeries, pSeries, iSeries 시스템에 적용되어 있다. 비슷한 경향은 x86/x64서버 플랫폼에서 Xen과 같은 오픈 소스 프로젝트에서 주도하는 가상화 노력으로 살펴볼 수 있다. 이것들은 리눅스와 솔라리스 커널에 하이퍼바이저를 구축하여 내장하고 있다. 이 기술은 대형 시스템에서 데스크탑으로 확대된 것으로 다음 섹션에서 설명하겠다.
# PC와 데스크톱 시스템
높은 수익을 내는 서버 하드웨어 시장 영역에 대한 관심은 전통적인 데스크톱 PC를 포함하여 인텔 x86 명령셋 컴퓨터의 하이퍼바이저 개발을 이끌고 있다. 초기의 PC 하이퍼바이저는 상업적인 VMware로 1998년 발표하였다. 2005년 Parallels 사에서 발표한 Parallels Workstation은 주로 PC에서 사용되었으며 2006년에는 맥 OS X에서 실행되는 Parallels Desktop for Mac을 발표하였다. x86 아키텍처를 사용하는 대부분의 PC 시스템에서는 특히 가상화가 어렵다. x86에서의 전가상화는 하이퍼바이저의 복잡함과 실행 성능에 중대한 희생을 치른다. 다른 대안으로 하이퍼바이저에 의해 가상의 머신 입출력 명령을 실행하는 것보다 하이퍼바이저에 시스템 콜을 발생시키기 위해 게스트 운영 체제를 변경하는 것을 필요로 한다. 이것을 Xen에서는 반가상화(paravirtualization), Parallels Workstation에서는 하이퍼콜(hypercall), IBM의 VM에서는 진단 코드(DIAGNOSE code)라 부른다. VMware는 가상화에서 가장 느린 곳에 게스트용 장치 드라이버를 사용하여 보완했다. 시스템 콜을 하이퍼바이저로 보내는 방법은 모두 같다. Mach와 L4 같은 마이크로커널은 게스트 운영 체제의 반가상화를 실현하기에 충분히 유연하다. CPU 제조업체는 자사의 제품에 하드웨어 가상화를 위한 원조를 추가하였다. 인텔의 VT(코드네임 Vanderpool)와 AMD의 AMD 가상화 또는 AMD-V(코드네임 Pacifica)는 x86의 가상화에 어렵거나 비 능률적인 부분을 확장하여 하이퍼바이저의 지원을 추가로 제공한다. 이것은 전가상화를 위해 좀 더 단순한 가상화 코드와 높은 성능을 가능하게 한다. Xen과 같은 또 다른 것들은 소프트웨어 만으로 가상 머신을 실현하였다. Xen은 리눅스와 같은 일반 호스트 운영 체제에서 동작되며 반가상화와 함께 게스트 운영 체제를 수정하지 않고도 인텔의 VTx 하드웨어 가상화 확장을 사용한 완전 가상화 둘 다 실행할 수 있다. Xen은 변경하지 않은 윈도우 XP의 실행을 시연하는데 성공하였다. Xen의 배포판에는 변경된 FreeBSD, Linux, NetBSD, 벨 연구소의 Plan 9이 포함되어 있다. 유저 프로그램은 변경없이 Xen에서 작동된다. 또 Xen은 선의 xVM 서버의 결과물로 오픈 솔라리스 커널로 이식을 시작하였다. 2008년 마이크로소프트는 새로운 타입 1 하이퍼바이저로 하이퍼 V(코드네임은 Viridian으로 이전에는 윈도 서버 가상화로 알려졌다.)를 윈도우 서버 2008를 발표한 지 180일 안에 출하하려고 하며 가장 낮은 수준에서 운영 체제와 통합을 특징으로 한다.Peter Galli. "Microsoft Sheds More Light on Windows Hypervisor Technology."url=http://www.eweek.com/article2/0,1895,1946420,00.asp April 5, 2006. 윈도우 비스타에서 시작된 윈도 운영 체제의 새 버전은 Viridian 하이퍼바이저에서 실행시켰을 때 성능을 끌어올리는 확장을 포함하고 있다.
# 임베디드 시스템
가상 머신은 휴대폰과 같은 임베디드 시스템에는 최근에 나타났다. 응용 프로그램을 프로그래밍하기 위해 리눅스나 마이크로소프트 윈도우와 같은 높은 수준의 운영 체제 인터페이스를 제공하기 위한 욕망과 같은 시기 전통적인 실시간 운영 체제(RTOS)의 API의 유지에서 시작되었다. 낮은 수준의 RTOS 환경은 종래의 기능을 지원하기 위하여 계속해서 유지할 필요가 있었는데 높은 수준의 운영 체제 실시간 성능은 많은 임베디드 응용 프로그램에 맞지 않았다. 임베디드에 사용되는 하이퍼바이저는 그런 이유로 반드시 실시간 성능이 충족되어야 하며 설계 기준이 다른 영역에서 사용되는 하이퍼바이저와 맞지 않는다. 리소스가 한정된 임베디드 시스템에서는 특히 배터리로 구동되는 모바일 시스템은 작은 메모리 크기와 낮은 오버헤드 같은 선결 과제가 있다. PC 분야에서 x86 아키텍처를 흔히 볼 수 있는 것에 비해 임베디드 분야에서는 폭넓은 다양한 아키텍처가 사용된다. 가상화를 지원하기 위해서는 메모리 보호가 필요하며(메모리 관리 유닛 형태 혹은 메모리 보호 유닛 형태) 유저 모드와 특권 모드가 구별되기 때문에 대부분의 마이크로프로세서는 해당되지 않는다. 이말은 미들에서 하이엔드에 걸쳐 임베디드 시스템 용도로 널리 사용되는 x86, MIPS, ARM, PowerPC 같은 아키텍처들은 계속 남게 된다는 것이다. 임베디드 시스템의 제조업체는 보통 자신들의 운영 체제 소스 코드를 가지고 있으며 전가상화의 필요성은 그다지 없었다. 이에 반해 반가상화의 높은 성능은 가상화 기술을 선택하게 만들었으며 ARM은 최근에 자사의 TrustZone 기술로 전가상화에 대한 지원을 추가하였다. 최초의 상업적 모바일 임베디드 시스템 하이퍼바이저로 판매된 것은 도시바 휴대폰에 사용된 OKL4이며 L4 마이크로커널의 상업용 버전으로 x86, ARM, MIPS 프로세서를 지원한다. 또, 다른 임베디드 시스템으로 TRANGO가 있는데 ARM, MIPS, PowerPC를 지원한다.Reconcile GPL Software and Proprietary Code on Embedded Systems with a Secure Hypervisor url=https://web.archive.org/web/20070928080710/http://www.trango-vp.com/download/TGO-TEC-0340-TRANGO_GPL.pdf, TRANGO Virtual Processors, August 2007.