“Windows 8에서 Hyper-V 구현”
이 게시물에서는 Windows '클라이언트' OS에서 가상화를 지원하는 방법에 대해 알아보겠습니다. 이 기술은 원래 Windows Server용으로 출시되어 성공적으로 큰 인기를 누렸으며 Windows를 전문적으로 사용하는 사람에게도 핵심적인 시나리오에서 가상화의 이점을 누릴 수 있는 기회를 드리고 싶었습니다. 중점적으로 고려한 대상은 여러 플랫폼과 클라이언트, 서버 전반에 걸쳐 작업하는 소프트웨어 개발자, 그리고 가상화된 클라이언트와 서버를 완벽하게 관리하고자 하는 시스템 관리자입니다. 본 게시물은 Hyper-V 팀에서 프로그램 관리자로 근무하는 Mathew John이 작성했습니다. 모든 기능과 마찬가지로 이 글에서도 엔지니어링 측면을 다루고 있으며 최종 패키징에 대한 것은 다루지 않고, 이러한 결정의 대부분은 프로젝트 후반부에 이루어진다는 점을 말씀드립니다. – Steven
참고: 많은 게시물을 연속해서 올릴 계획은 없으며 적당한 속도로 꾸준히 글을 올리려고 합니다. 많은 기대를 하신 분들께는 사과의 말씀을 전해 드립니다. 저희는 현재 BUILD 준비에 여념이 없습니다!
소프트웨어 개발자, 시스템 관리자뿐 아니라 단순히 열정적인 사용자라도 일반적으로 여러 시스템에서 다수의 OS를 운영해야 할 경우가 많이 있습니다. 많은 사람들에게 이러한 시스템을 모두 구축하는 일은 큰 부담이 따르기 때문에 가상화는 필요한 공간과 시간을 줄이는 해법이 될 수 있습니다.
Windows 8을 빌드하면서 Hyper-V를 구현하기 위해 노력했는데, 이 기술은 최근 Windows Server 출시에 두 차례 포함되었으며 클라이언트 OS에서도 작동하는 시스템 가상화 기술입니다. 간단히 말해서, Hyper-V를 사용하면 동일한 컴퓨터에서 둘 이상의 32비트 또는 64비트 운영 체제를 동시에 실행할 수 있습니다. 이러한 운영 체제는 컴퓨터 하드웨어에서 직접 작동하는 것이 아니라 가상 머신(VM) 내에서 실행됩니다.
Hyper-V를 통해 개발자는 다수의 테스트 환경을 쉽게 관리하면서 하드웨어에 대한 추가 비용을 들이지 않고도 여러 환경을 신속하게 전환할 수 있습니다. 웹 개발자를 지원하기 위해 이전 버전의 Internet Explorer를 포함하여 출시한 사전 구성된 가상 머신도 이러한 맥락에서 이해할 수 있습니다. 시스템 관리자도 가상 머신의 추가적 이점을 동일하게 누릴 수 있으며 Windows Server와 Windows 클라이언트에서 Hyper-V를 통한 공통된 관리 방식을 경험할 수 있습니다. 또한 많은 분들이 주로 사용하는 PC를 변경하는 불편을 감수하지 않고 새로운 환경을 시도해 보는 목적으로도 가상화가 이용되고 있습니다.
Hyper-V 소개
Hyper-V를 사용하려면 SLAT(Second Level Address Translation) 기능이 있는 64비트 시스템이 필요합니다. SLAT는 Intel과 AMD가 제공하는 최신 64비트 프로세서에 사용되는 기능입니다. 이와 함께 64비트 버전의 Windows 8과 4GB 이상의 RAM이 필요합니다. Hyper-V를 통해 VM에서 32비트 OS와 64비트 OS를 모두 생성할 수 있습니다.
Hyper-V는 동적 메모리를 사용하므로 사용자가 최대량과 최소량을 지정하면 VM에 필요한 메모리가 동적으로 할당되거나 회수되고, VM 간에 사용되지 않은 메모리를 공유할 수 있습니다. 4GB의 RAM이 있는 컴퓨터에서는 3~4개의 VM을 운영할 수 있지만 VM이 5개 이상으로 늘어나면 RAM이 추가로 필요합니다. 최대 32개의 프로세서와 512GB의 RAM을 갖춘 대규모 VM을 여러 개 만들 수도 있습니다.
VM에 대한 사용자 경험 측면에서 Windows는 가상 컴퓨터를 보기 위한 두 가지 방식을 제공합니다. 바로 VM 콘솔과 원격 데스크톱 연결입니다.
VMConnect라고도 하는 VM 콘솔은 VM을 콘솔 방식으로 보여 주며, 최대 1600x1200의 해상도에서 32비트 컬러로 VM의 작동 상황을 한 눈에 파악할 수 있습니다. 이 콘솔에는 VM의 부팅 프로세스도 표시됩니다.
원격 데스크톱 연결(RDC)을 사용하면 더 다양한 방식으로 VM에 연결할 수 있습니다. RDC를 통해 VM은 물리적 PC에 존재하는 기능들을 이용합니다. 예를 들어, 다중 모니터를 사용하는 경우에 VM은 이러한 모든 모니터에 그래픽을 표시할 수 있습니다. 마찬가지로, PC에서 터치 방식의 다중 포인트 인터페이스를 사용한다면 VM에서도 이 인터페이스를 사용하여 터치 기능을 경험할 수 있습니다. 또한 VM은 물리적 시스템의 스피커와 마이크를 사용하는 완벽한 멀티미디어 기능을 갖추고 있습니다. VM을 관리하는 기본 Windows OS인 루트 OS는 VM과 클립보드 및 폴더를 공유할 수도 있습니다. 마지막으로, RDC를 사용하면 VM에 USB 장치를 직접 연결할 수도 있습니다.
저장소의 경우, VM에서 사용할 수 있는 IDE 또는 SCSI 컨트롤러에 하드 디스크를 여러 개 추가할 수 있습니다. 가상 하드 디스크(.VHD 또는 .VHDX 파일)를 사용하거나 가상 컴퓨터에 실제 디스크를 직접 연결하여 사용할 수 있습니다. VHD는 원격 파일 서버에 둘 수도 있으므로 팀 전체가 사전 정의된 VHD를 공용으로 관리하고 공유하기가 쉽습니다.
Hyper-V의 '실시간 저장소 이동(Live Storage Move)' 기능은 VM을 기본 저장소와는 별도로 유지 관리하는 데 매우 유용합니다. 즉, VM을 중단하지 않고도 VM 저장소를 하나의 로컬 드라이브에서 다른 로컬 드라이브로 이동하거나, USB 메모리 또는 원격 파일 공유 위치로 이동할 수 있습니다. 이 기능은 신속히 배포하는 데 매우 유용합니다. 제 경우에는 VM이 급하게 필요할 때 파일 공유 위치에서 관리되는 VM 라이브러리에서 VM을 시작한 후 이 VM의 저장소를 제 로컬 드라이브로 이동합니다.
VM 실행 중에 가상 컴퓨터의 '스냅숏'을 만들 수 있다는 점도 Hyper-V의 중요한 기능 중 하나입니다. 스냅숏은 가상 컴퓨터의 모든 것을 저장하므로 VM을 사용하면서 이전의 특정 시점으로 되돌아갈 수 있어 해결하기 어려운 문제를 디버깅할 때 훌륭한 도구로 쓰입니다. 이와 동시에 Hyper-V 가상 컴퓨터는 Windows를 매우 간편하게 관리할 수 있는 기능을 모두 갖추고 있습니다. Windows Update로 Hyper-V 구성 요소에 패치가 적용되므로 유지 관리 프로세스를 별도로 설정할 필요가 없으며, Windows에는 Hyper-V로 설치된 것과 동일한 기능이 기본적으로 포함되어 있습니다.
이러한 장점들이 있는 반면, 가상화에는 몇 가지 제한도 있습니다. 특정 하드웨어를 사용해야 하는 기능이나 응용 프로그램은 VM에서 정상적으로 작동하지 않습니다. 예를 들어, TPM(신뢰할 수 있는 플랫폼 모듈)에 의존하는 Windows BitLocker와 Measured Boot는 VM에서 올바로 작동하지 않을 수 있으며, 소프트웨어 폴백을 제공하지 않고 GPU로 처리해야 하는 게임이나 응용 프로그램도 제대로 작동하지 않을 수 있습니다. 또한 10ms 이하의 타이머를 사용하는 응용 프로그램, 즉 라이브 음악 믹싱 앱과 같이 대기 시간에 민감한 고정밀 앱은 VM에서 실행했을 때 문제가 발생할 수 있습니다. 루트 OS는 Hyper-V 가상화 계층 위에서 실행되기도 하지만 모든 하드웨어에 직접 액세스한다는 점이 특수합니다. 특수 하드웨어를 사용해야 하는 응용 프로그램은 루트 OS에서 문제 없이 작동하지만, 대기 시간에 민감한 고정밀 앱을 루트 OS에서 실행할 때 문제가 발생하는 이유가 바로 여기에 있습니다.
VM에서 사용하는 운영 체제에도 라이선스가 필요하다는 점을 참고로 알려드립니다.
아래 데모를 통해 Windows 8에서 Hyper-V의 작동 방식을 간단히 확인할 수 있습니다.
다른 미디어 플레이어로 보려면 이 비디오를 다운로드하십시오.
고화질 MP4 | 저화질 MP4
무선 NIC를 이용한 VM 통신 지원
데모에서 보시다시피 외부 네트워크 스위치를 생성하는 작업은 드롭다운 목록에서 물리적 네트워크 어댑터(NIC)를 선택하고 '확인'을 클릭하는 것만큼이나 간단합니다. Windows Server의 경우 이미 Hyper-V의 정상 작동이 입증되었지만 Windows 8에서도 동일한 결과를 얻으려면 Hyper-V가 무선 NIC에서도 작동하도록 조치를 취해야 하는 새로운 문제가 따릅니다.
문제
Hyper-V에서 가상 스위치는 '계층-2 스위치'이므로, 물리적 및 가상 네트워크 어댑터 카드를 각각 고유하게 식별하는 MAC 주소를 사용하여 전환합니다. 즉, 특정 이더넷 패킷이 이동하는 경로를 결정합니다. 각 이더넷 패킷에서 소스와 대상 컴퓨터의 MAC 주소가 보내지고, 계층-2 스위치는 이 주소를 사용하여 들어오는 패킷을 보내야 하는 위치를 결정합니다. '외부' 가상 스위치는 물리적 NIC를 통해 외부 환경과 연결됩니다. 외부 환경의 컴퓨터로 보내야 하는 VM의 이더넷 패킷은 이 물리적 NIC를 통해 보내집니다. 다시 말해, 물리적 NIC는 이 가상 스위치에 연결된 모든 VM의 트래픽을 전달할 수 있어야 하며, 이는 물리적 NIC를 통해 전달되는 패킷에 다수의 MAC 주소(각 VM의 가상 NIC별로 하나씩)가 포함된다는 것을 의미합니다. 물리적 유선 NIC에서는 NIC를 무차별 모드에 놓음으로써 이러한 부분이 지원되지만, WiFi NIC와 해당 액세스 지점으로 구성되는 무선 채널이 단지 WiFi NIC의 MAC 주소를 포함한 이더넷 패킷만 허용한다는 점 때문에 무선 NIC에서는 지원되지 않습니다. 즉, 현재의 가상 스위치 아키텍처를 계속 사용한다면 Hyper-V는 WiFi NIC를 외부 스위치로 사용하지 못합니다.
그림 1: 유선 연결을 사용한 VM과 외부 컴퓨터 사이의 네트워크 구성
솔루션
이 제한을 해결하기 위해 ARP 프록싱(IPv4의 경우)과 네트워크 환경 검색 프록싱(IPv6의 경우)을 구현하여 나가는 패킷에 대해 '가상' NIC의 MAC 주소를 WiFi 어댑터의 MAC 주소로 대체하는 Microsoft 브리징 솔루션을 사용했습니다. 이 브리지는 가상 NIC의 IP 주소와 MAC 주소 간의 내부 매핑을 관리하여 외부 환경에서 들어오는 패킷이 해당하는 가상 NIC로 보내지도록 합니다.
Hyper-V는 WiFi 어댑터를 사용하여 외부 가상 스위치를 만들 때 Hyper-V가 다음과 같이 작동하도록 이러한 브리지를 가상 스위치 생성 과정의 일부로 통합합니다.
- WiFi 어댑터에 연결되는 단일 어댑터 브리지 생성
- 외부 가상 스위치 생성
- 외부 가상 스위치를 결합시켜 WiFi 어댑터를 직접 사용하지 않고 브리지 사용
이 모델에서도 가상 스위치에 이더넷 스위칭이 계속 사용되며 브리지에서 MAC 변환이 이루어집니다. 외부 네트워크를 생성하는 최종 사용자의 경우, 작업 흐름은 유선 또는 무선 NIC를 선택하는 경우에 모두 동일합니다.
그림 2: WiFi 연결을 사용한 VM과 외부 컴퓨터 사이의 네트워크 구성
결론적으로, Windows Server에서 Windows 클라이언트로 Hyper-V를 연결함으로써 대부분의 데이터 센터에 요구되는 확장성, 보안, 신뢰성 및 성능 조건을 충족하는 완벽한 가상화 기술을 제공할 수 있었습니다. Hyper-V를 통해 개발자와 시스템 관리자는 이제 더욱 저렴한 비용으로 여러 컴퓨터를 사용하여 테스트를 수행하는 데 효율적인 환경을 구축할 수 있습니다.
- Mathew John