안녕하세요.
오늘은 Microsoft의 Hyper-V에 대해 알아보려합니다.
원래 Hyper-V에 대한 구축만 다룰까 했지만 그렇게 했다가는 동전 없는 깡통만 업로드 한 것으로 보일 수 있어서 이론적인 부분을 먼저 다루고 구축을 진행하겠습니다. 참고로 오늘은 그림이 많지 않습니다.(1장 있습니다.)
[On-premise 환경 구축]
Windows server 2012 R2 ~ 2019 (~2008 R2도 가능하지만 EOS 제품은 굳이 올리지 않겠습니다.)
Active Directory Domain Services (AD DS, 이중화 포함)
Active Directory Certificate Services (AD CS)
Active Directory Rights Management Services (AD RMS)
Active Directory Federation Services (AD FS, O365 및 G Suite federation 포함)
Active Directory Rights Management Services (AD RMS)
DHCP Server (Failover Clustering을 통한 이중화 및 기본 이중화 포함)
DNS Server
File and Storage Services
Failover Clustering
Hyper-V (이중화 및 SCVMM 포함)
Network Policy and Access Services (NPS, RADIUS를 통한 무선 연결 포함)
Remote Destop Services (RDS)
Print and Document Services
Web Server (IIS, ARR 및 URL Rewrite 포함)
Windows Server Update Services (WSUS, 이중화 포함)
Network Load Balacing (NLB)
Exchange Server 2013 ~ 2019
LYNC server 2013 & Skype for Business (SFB)
MDT 2013 ~ 최신 (ImageX를 통한 배포 및 SCCM을 통한 배포 포함)
MDOP Packages
- BitLocker Administration and Monitoring (MBAM)
- DaRT
MS SQL 2012 ~ 2019 (SSMS, SSRS 세부 설정까지 포함)
- Failover Clustering 및 AlwaysOn 구성 가능
OCS, OWA 등
Syatem Center Confuguration Manager (SCCM 설치부터 간단 구성까지)
[Table of contents]
서론
Hypervisor 역할 및 기능 설명
가상화 종류
Hosted virtualization (hypervisor type 2)
Native virtualization (or bare-metal virtualization, hypervisor type 1)
Hyper-V architecture
Second Level Address Translation (SLAT)
Hyper-V internal architecture
Virtual disk architecture (vhd, vhdx)
vNUMA
System reqirements
지원되는 Windows Guest 운영체제
지원되는 linux 및 FreeBSD VM
세대 및 게스트 별 기능 호환성
Plan for Hyper-V on Windows Server
Scalability
Security
Networking
VM Generation
Discreate Device Assignment
Hyper-V Install and configuration
Hyper-V 설치
가상 스위치 만들기
가상 머신 만들기
Hyper-V deployment
배포
가상 컴퓨터 내보내기 및 가져오기
실시간 마이그레이션을 위한 호스트 설정
가상 컴퓨터 버전 업그레이드
DDA를 사용하여 그래픽 장치 배포
DDA를 사용하여 저장 장치 배치
Manamgent
각 기능 설명
Standard or production checkpoint 선택
검사점 활성화 또는 비활성화
Hyper-V 관리자로 host 관리
호스트 CPU 리소스 제어 관리
VM CPU 그룹 사용
PowerShell Direct로 Windows VM 관리
Hyper-V 복제본 생성
Failover Clustering없이 실제 마이그레이션을 사용하여 VM 이동
서론
오늘은 Microsoft의 Hyper-V에 대해 알아보려합니다.
Hyper-V는 Microsoft가 Hypervisor(하이퍼 바이저) 기반으로 제작한 가상화 플랫폼이며, 이미 널리 사용되고 있는 VMWare나 VirtualBox와 비슷한 존재하지 않는 매체를 존재하게 만드는 기술(가상화)이라고 보면 됩니다. 이 가이드에서는 Hyper-V가 사용하는 Hypervisor는 무엇이며 Hyper-V의 기본적인 architecture는 어떻게 이루어졌는지와 타사 VMWare, VirtualBox와 어떻게 다른지 거시에서 미시로 설명합니다. 내용이 긴 관계로 Part 1과 Part 2로 나누어서 업로드 합니다.
Hypervisor 역할 및 기능 설명
가상화 종류
가상화는 여러 종류로 나누어져 있습니다. 다음 설명을 통해 Micorosoft Hyper-V가 사용하는 기술과 타 솔루션의 차이를 검토할 수 있습니다.
- Hosted virtualization (hypervisor type 2)
- 관리 계층 접근 방식이라고 하는 hosted virtualization은 최종 사용자가 자신의 머신에서 호스트하는 가상화를 말하는 것입니다.
- Hosted virtualization에서는 일반적으로 고유한 시스템의 하드웨어 및 운영 체제를 사용하여 VMWare 서버, VMWare Workstation, Oracle Virtual Box 또는 Microsoft Virtual PC와 같은 가상화 software를 실행하고 이 호스트된 플랫폼 내에서 가상 시스템을 실행합니다.
- 이러한 hosted virtualization은 guest OS 실행을 위해 최소 3단계까지(Hardware - Hypervisor - OS - Software)의 Ring을 거쳐 실행되므로 host 머신에 OS를 반드시 설치해야 합니다. 이러한 개념은 hypervisor type 2에 해당하는 개념이며, 하드웨어에 직접 액세스하지 않고 OS를 거쳐야 하므로 리소스에 대한 I/O overflow 및 성능저하가 발생할 수 있으며 Host 머신에서 실행중인 software의 잠재적 리소스를 guest 머신이 점유할 가능성이 높습니다.
|
※ 여기서 알아야 할 개념은 Host와 Guest입니다. Host를 여관에 비유하겠습니다. 여러분이 여관에 입장했을 때 여관의 관점에서 여러분은 guest가 됩니다. 해당 Guest를 맞아들여 여러분의 니즈에 맞는 서비스를 제공해주고 여관 자체를 관리 및 감독하는 주체를 여관 주인 또는 host라고 합니다. 따라서 host는 무언가를 서비스해주기 위한 사전작업 및 사후작업을 진행하는 개체라고 이해하시면 됩니다. (서비스 개념도 중요하지만 여기서는 다루지 않겠습니다.) 많이들 알고 계시겠지만 IT 용어의 Host는 네트워크 상의 다른 호스트와 통신하는 컴퓨터 또는 기타 장치를 의미합니다. 다시 말하면 여관1의 호스트가 여관2의 호스트와 통신한다는 의미입니다. 하지만 가상화에서 얘기하는 Host는 하나의 물리적 서버에서 여러 Guest OS를 구현하기 위해 실행하는 기술을 의미합니다. 가상화에서는 보통 Host와 Guest로 분리하며, Host는 Guest를 구성하기 위한 서버 머신을 의미하며 Guest는 가상화 개체를 제공하는 가상 머신을 의미합니다. host와 guest의 기초 개념은 가상화 이론에 상당히 중요한 부분을 차지하므로 반드시 이해하고 넘어가야 합니다. |
- Native virtualization (or bare-metal virtualization, hypervisor type 1)
- Native virtualization은 host 머신에서 다수의 guest 머신을 동시에 운용하기 위한 논리적 플랫폼입니다.
- Microsoft의 Hyper-V는 Hypervisor의 Type 1을 사용하여 하드웨어 위의 host OS에서 직접 실행됩니다. Hyper-V 이외에도 VMWare ESX 서버와 Citrix의 Xen Server가 있으며 VMWare ESX 서버 또는 Xen 서버는 별도의 OS 설치없이 하드웨어 위에서 직접 실행되어(bare-metal) 중개자 호스트 운영 체제가 없이 실행할 수 있습니다.
- 각 솔루션 마다 사용하는 기술이 다르며, 이러한 차이는 하드웨어 가상화(Hardware assited, Hardware virtualization)의 기술적인 개발 차이로 구분됩니다. 하드웨어 가상화는 BT (Binary Translation on Software virtualization, Hypervisor type 2)와 다르게 Processor의 Virtualization technology에 따라 구분됩니다. 하드웨어 지원에 가장 유명한 기술은 Intel의 VT (Virtualization Technology)와 AMD의 SVM (Security and Vritual Machine)입니다.
Intel의 VT와 AMD의 SVM에 대한 개괄적인 architecture는 아래 문서(링크)에서 확인할 수 있습니다.
Intel VT: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/virtualization-enabling-intel-virtualization-technology-features-and-benefits-paper.pdf
AMD SVM: https://www.mimuw.edu.pl/~vincent/lecture6/sources/amd-pacifica-specification.pdf - Microsoft의 Hyper-V의 자세한 architecture는 아래 챕터를 확인 바랍니다.
Hyper-V architecture
-
Second Level Address Translation (SLAT)
SLAT는 Intel 및 AMD의 64 비트 Processor architecture에 사용되는 기술입니다. SLAT를 통해 GPA과정을 소프트웨어 방식으로 처리하는 것이 아니라 CPU에서 직접 처리해 소프트웨어 레벨에서 처리하던 것 보다 높은 성능을 낼 수 있습니다. SLAT를 이용하면 CPU는 2~10%, 메모리는 VM당 1MB의 오버헤드를 줄일 수 있다고 합니다. Intel은 Extended page tables (EPT)이라 불리며, AMD는 Nested Page Tables (NPT)라고 부릅니다. SLAT를 알기 앞서 page table, Guest Virutal Address (GVA) 영역, Guest Physical Address (GPA) 및 SPA (System Physical Address) 등 Hyper-V의 Virtual memory 관리 방안에 대해 알아야 합니다. 또한 Hyper-V에서 SLAT를 어떻게 활용하는지 알아야 합니다.- Virtual memory: 우리가 흔히 사용하고 있는 Windows는 하이브리드 커널을 사용하여 운영 되고 있습니다.(Linux는 모놀리식 커널을 사용하고 있죠) 모든 커널의 요점은 "1. 실체하는 하드웨어를 어떻게하면 추상화할 수 있는가"와 "2. 어디까지 최적화하고 효율적으로 추상화할 수 있는가"일 것입니다. 우리가 사용하는 WIndows의 경우도 이러한 추상화를 하이브리드 커널의 HAL (Hardware Abstraction Layer)을 통해 진행합니다. HAL을 통해 실체하는 Hardware resources(Physical hardware resources)와 추상화된 Hardware resources(Logical hardware resources)로 구분하게 되었지요. 우리는 이렇게 실체하는 Hardware 자원(resources)을 활용하고 계산하여 Windows 또는 Linux 등의 OS를 설치하고 그 위에 Applications를 설치하여 사용합니다. 만약 우리가 이 과정(사용자모드)에서 Physical resouces만 사용한다고 가정합시다. 고 사양으로 Program 된 Applications 또는 overflow를 발생시키는 소스코드를 실행하게 된다면 BSOD (Blue Screen Of Death) 또는 Debugger를 진행하라는 창이 발생하게 될 것입니다. 이러한 문제를 방지하고자 개발자가 아무리 디버그를 진행한다고 하더라도 Physical resouces에 한계가 있다면 개발을 다시 하던가(더 낮은 사양에서 안전하게 구동되도록 재 개발), 사용자의 Physical resources를 늘리라는 권고를 주던가해야 할 것입니다. 그러므로 HAL을 통해 구분된 Logical resouces까지 사용하는 것이 여러므로 좋습니다. 하이브리드 커널의 커널 모드에는 이러한 Physical resources와 비슷한 구조를 가진 각각의 드라이버 모듈이 구성되어 있으며 이러한 모듈(또는 어댑터)은 Physical resouces와 작동하는 방식 또한 비슷하게 구성되어 있는것들이 많습니다. Processor (CPU)에 내장 된 MMU (Memory Management Unit)와 커널 모드의 VMM (Virtual Memory Management)은 서로 유기적으로 작동하여 Virtual memory를 관리하여 커널의 메모리 관리의 부담을 줄여줍니다. 이로 인해 물리적 메모리의 단편화(Memory fragmentation; 사용 가능한 memory가 충분하지만 allocated가 불가능한 상태)를 숨기고, 커널에 메모리 계층 관리 부담을 줄임으로써 applications을 더 쉽게 만들며 각 Process가 자체 전용 주소 공간에서 실행될 때 소스 코드를 재 배치(Relocation; 위치 의존 코드 및 프로그램 데이터에 불러올 주소를 할당하고 할당 된 주소를 반영하도록 코드 및 데이터를 조정하는 작업)할 필요가 없습니다. 보통 상대적인 주소 지정(relative addressing)을 사용하여 메모리에 액세스합니다. 참고로 memory는 CPU (Central Processing Unit)에도 cache 형태로 존재합니다.
- Address: Virtual memory에 설명했던 하이브리드 커널에서 사용자 모드를 통해 Applications으로 어떠한 명령을 내렸을 때 Processor는 해당 명령을 해석하기 위해 Processor의 Control unit이 해석하고 ALU (Arthmetic Logic Unit)가 계산하여 해석된 데이터가 IR (Instruction Register)와 Bus interface를 통해 Memory로 해당 명령어를 저장하게 됩니다. (전처리기 -> 컴파일러 -> 어셈블러 -> 링커 -> 실행파일 -> 로드 -> 명령어 -> Bus interface -> IR -> Control Unit -> ALU -> IR -> Bus interface -> Memory (Data, Address, Control) 문제는 이러한 과정을 2진수 또는 16진수로 진행한다는 것입니다. 우리가 어떤 Applications을 실행(Run)했을 때 Run이라는 명령어는 16진수로 변환되다가 최종적으로 2진수로 변환됩니다. 이러한 Hardware resources가 이해하는 문장의 공간을 address space라고 합니다.
- Page Memory: Page는 위와 같은 과정을 통해 physical memory에 저장된 주소 값(address values) 중 logical memory 영역에서 사용해야 할 주소 범위를 cache 화 한 것이라고 볼 수 있습니다. 앞서 진행했던 run 명령어가 logical memory에 있다고 가정할 때 해당 명령어를 translation해서 executive 하는 것이 하이브리드 커널의 Windows API가 하는 역할입니다. 허나 x86과 같은 운영체제에서 PTE를 사용하지 않을 경우 커널 모드 2GB, 사용자 모드 2GB까지만 사용 가능하기 때문에 Logical memory가 한계에 도달한다면 run 명령어는 실행되지 않거나 오류가 발생할 수 있습니다. 따라서 page cache 주소 공간(address space)을 실제 주소로 변환해야 applications에서 실행했던 run 명령어를 logical memory (virtual memory)영역에서 안전하게 실행할 수 있습니다. 만약 해당 명령어를 바로 실행할 수 없거나 해당 application이 점유하고 있는 Physical memory 공간이 부족할 경우 Windows는 해당 명령어를 file로 page할 수도 있습니다.
- Page Table: Page table은 OS가 각 mapping을 Page table entry라고 하는 물리적 주소에 대한 가상 주소 매핑(mappings of virtual addresses)을 저장하는(Stored) 곳입니다. Process는 memory에 있는 데이터에 대한 액세스를 요청합니다. Process가 제공한 가상의 주소(Virtual addresses)를 해당 데이터가 저장된 실제 메모리(actual memory)의 물리적 주소(physical addresses)로 mapping하는 것은 OS의 의무입니다.
- GVA (Guest virtual address), GPA (Guest Physical address), SPA (System virutla adress): (해당 내용은 sankim님 블로그 내용을 일부 발췌했습니다. https://blogs.technet.microsoft.com/sankim/2011/08/16/hyper-v-memory-management/)
우리는 위 내용을 통해 Windows의 각 Process가 Physical memory에 접근하는 것이 아니라 virtual memory를 이용하며 process가 virtual memory의 특정 주소 공간에 접근하려고 하면 Page라는 과정을 거쳐 실제 Physical memory에 접근하게 된다는 것을 알게 되었습니다. 이와 같은 개념은 Hyper-V에서도 비슷하게 구조화됩니다. 각 Guest OS에서 가상메모리 역할을하는 GVA 영역이 있고 이것을 물리 메모리에 연결하여 page address table을 가지고 있는 GPA와 실제 몰리 주소인 SPA가 있습니다. Guest 머신은 자신의 가상 메모리인 GVA를 통해 GPA를 실제 물리 메모리인 것처럼 접근하게 되고 GPA는 SPA에 mapping하게 됩니다. Guest 머신은 실제 물리 컴퓨터에서의 virtual memory와 마찬가지로 실제 physical memory와 페이징 파일에 메모리 정보를 저장할 수 있는데, 페이징 작업이 필요한 경우 각 Guest OS의 페이징 파일에 보낼 수도 있습니다.
- SLAT 참고 자료: (해당 내용은 Koalra님의 블로그 내용을 일부 발췌했습니다. (https://blogs.technet.microsoft.com/koalra/2009/02/12/second-level-address-translation-slat-hyper-v-r2/)
"SLAT의 경우에는 메모리 관리에 대한 부분입니다. 먼저 실제 물리적인 운영 체제의 경우, 메모리에 대한 사용은 실제 메모리를 사용하는 것이 아니라, Windows에서 제공하는 가상 메모리(Virtual Memory)를 사용하고, 이에 대한 실제 물리적인 메모리(Physical Memory) 맵핑은 CPU를 통해서 일어나게 됩니다. 이를 주소 변환(Address Translation)이라고 하고 있습니다.
그러나, 가상화 환경이 되면 조금 생각을 달리해야 합니다. 실제 물리적인 머신이 있지만, 가상 머신도 존재를 하게 되겠죠? 가상 머신내에도 운영 체제가 설치되게 되고, 가상 머신내에 설치되는 운영 체제도 가상 메모리를 실제 메모리로 맵핑해주는 일을 해줘야 합니다. 쉽게 정리해보면 다음과 같습니다.
가상 머신내 운영 체제의 가상 메모리 주소(Guest Virtual Memory Address - GVA)가 가상 물리적인 메모리 주소(Guest Physical Memory Address - GPA), 그리고 이 실제 GPA가 시스템의 물리적인 메모리 주소(System Physical Memory Address – SPA)로 맵핑되어야 합니다. 위에 실제 머신 환경에서 생각해보시면, VA가 바로 PA로 맵핑되는 구조였지만, 가상화 환경이 되면서, 가상화 환경내 메모리 관리가 별도로 필요해진다는 의미입니다. GPA를 SPA로 맵핑하는 일을 지금까지는 Hypervisor가 담당하고 있었으며, Hypervisor에서는 Shadow Page Table(SPT)을 통하여, GVA가 바로 SPA로 맵핑될 수 있도록 처리하고 있었습니다. 이유는 단 한가지.. CPU가 Address Translation을 한번에 처리를 해줘야(One-Level) 했기 때문입니다. 만약 CPU가 GVA를 GPA로 GPA를 SPA로 2단계 주소 변경이 가능했다면, 구지 Hypervisor가 SPT을 통해 어떤 가상 머신내 GVA가 실제 메모리의 SPA와 연결되는지 일일히 관리하지 않았어도 된다는 의미입니다."
-
- Hyper-V internal architecture
잘못된 형식의 이미지 링크입니다.
Hyper-V 내부 구조를 microsoft 내부 문서를 통해 확인해보겠습니다.
(https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/reference/hyper-v-architecture)
"Hyper-V는 특정 x64 버전의 Windows를 위한 하이퍼바이저 기반 가상화 기술입니다. 하이퍼바이저는 가상화의 핵심입니다. 여러 개의 분리된 운영 체제가 단일 하드웨어 플랫폼을 공유할 수 있도록 지원하는 프로세서별 가상화 플랫폼입니다.
Hyper-V는 파티션의 분리를 지원합니다. 파티션은 운영 체제가 실행되는 하이퍼바이저에서 지원하는 격리 논리 단위입니다. Microsoft 하이퍼바이저에는 Windows를 실행하는 상위 또는 루트 파티션이 하나 이상 있어야 합니다. 가상화 관리 스택은 상위 파티션에서 실행되며 하드웨어 디바이스에 직접 액세스할 수 있습니다. 그런 다음 루트 파티션은 게스트 운영 체제를 호스팅하는 하위 파티션을 생성합니다. 루트 파티션은 API (Hypercall Application Programming Interface)를 사용하여 하위 파티션을 생성합니다.
파티션은 물리적 프로세서에 액세스할 수 없으며 프로세서 인터럽트를 처리하지도 않습니다. 대신 프로세서에 대한 가상 보기가 있고 각 게스트 파티션에 전용인 가상 메모리 주소 영역에서 실행됩니다. 하이퍼바이저는 인터럽트를 프로세서로 처리하고 해당 파티션으로 리디렉션합니다. 또한 Hyper-V는 CPU에서 사용하는 메모리 관리 하드웨어와 독립적으로 작동하는 IOMMU (Input Output Memory Management Unit)를 사용하여 다양한 게스트 가상 주소 공간 간의 주소 변환 시간을 단축할 수도 있습니다. IOMMU는 물리적 메모리 주소를 하위 파티션에서 사용하는 주소로 다시 매핑하는 데 사용됩니다.
하위 파티션은 또한 다른 하드웨어 리소스에 직접 액세스할 수 없으며 가상 디바이스(VDev)로 리소스에 대한 가상 보기를 제공합니다. 가상 디바이스에 대한 요청은 VMBus 또는 하이퍼바이저를 통해 상위 파티션의 디바이스로 리디렉션되며 이 디바이스는 이 요청을 처리합니다. VMBus는 논리적 파티션 간 통신 채널입니다. 상위 파티션은 VMBus를 통해 통신하여 하위 파티션의 디바이스 액세스 요청을 처리하는 VSP(가상화 서비스 공급자)를 호스팅합니다. 하위 파티션은 VMBus를 통해 디바이스 요청을 상위 파티션의 VSP로 리디렉션하는 VSC(Virtualization Service Consumer)를 호스팅합니다. 이 전체 프로세스는 게스트 운영 체제에 영향을 주지 않습니다.
가상 장치는 스토리지, 네트워킹, 그래픽 및 입력 하위 시스템에 대해 Enlightened I/O라는 윈도우즈 서버 가상화 기능을 활용할 수도 있습니다. I/O는 디바이스 에뮬레이션 계층을 거치지 않고 VMBus를 직접 사용하는 고급 통신 프로토콜(예: SCSI)을 전문적으로 구현하는 가상화 인식 구현입니다. 이렇게 하면 통신 효율성은 향상되지만 하이퍼바이저 및 VMBus를 인식하는 계몽된 게스트가 필요합니다. Hyper-V의 향상된 I/O 및 하이퍼바이저 인식 커널은 Hyper-V 통합 서비스 설치를 통해 제공됩니다. VSC(가상 서버 클라이언트) 드라이버를 포함하는 통합 구성 요소는 다른 클라이언트 운영 체제에서도 사용할 수 있습니다. Hyper-V에는 Intel VT 또는AMD-V(AMD-V) 기술과 함께 제공되는 하드웨어 지원 가상화가 포함된 프로세서가 필요합니다."
간단히 말하면 부모 파티션(Parent partition)은 hosted virtualization의 host가 되는 것이며 자식 파티션(Child partition)은 guest OS라고 보면 됩니다. 따라서 Hyper-V가 설치된 실제 물리적인 머신은 부모이며 부모 파티션에서는 자식 파티션이라 불리는 가상 머신을 만들고 관리하는 역할을 합니다. Hyper-V의 Hypervisor는 부모 파티션도 VM과 같이 일종의 파티션으로 인식하고 있으며, 에뮬레이션과 같이 부모 파티션의 영향이나 간섭을 받지 았습니다.
다음은 Hyper-V에서 사용하는 용어에 대해 설명합니다.- APIC (Advanced Programmable Interrupt Controller): 우선 순위 레벨을 인터럽트 출력에 할당할 수 있는 장치입니다.
- 하위 파티션: 게스트 운영 체제를 호스팅하는 파티션이며, 하위 파티션에 의한 물리적 메모리 및 디바이스에 대한 모든 액세스는 VMBus(가상 시스템 버스) 또는 하이퍼바이저를 통해 제공됩니다.
- 하이퍼콜: 하이퍼바이저와의 통신을 위한 인터페이스로 하이퍼콜 인터페이스는 하이퍼바이저가 제공하는 최적화 기능에 대한 액세스를 수용합니다.
- 하이퍼바이저: 하드웨어와 하나 이상의 운영 체제 사이에 있는 소프트웨어 계층입니다. 기본 작업은 파티션이라고 하는 분리된 실행 환경을 제공하는 것입니다. 하이퍼바이저는 기본 하드웨어에 대한 액세스를 제어하고 중재합니다.
- IC (Integration Component): 하위 파티션이 다른 파티션 및 하이퍼바이저와 통신할 수 있는 구성 요소입니다.
- I/O 스택: 입력/출력 스택입니다.
- MSR: 메모리 서비스 루틴입니다.
- 루트 파티션: 상위 파티션이라고도 합니다. 장치 드라이버, 전원 관리 및 장치 핫 추가/제거와 같은 시스템 레벨 기능을 관리합니다. 루트(또는 상위) 파티션은 물리적 메모리 및 장치에 직접 액세스할 수 있는 유일한 파티션입니다.
- VID (Virtualization Infrastructure Driver): 파티션에 대한 파티션 관리 서비스로 가상 프로세서 관리 서비스 및 메모리 관리 서비스를 제공합니다.
- VMBus: 여러 개의 활성 가상화 파티션이 있는 시스템에서 파티션 간 통신 및 장치 열거에 사용되는 채널 기반 통신 메커니즘입니다. VMBus는 Hyper-V 통합 서비스와 함께 설치됩니다.
- VMMS (Virtual Machine Management Service): 하위 파티션에 있는 모든 가상 시스템의 상태를 관리합니다.
- VMWP (Virtual Machine Worker Process): 가상화 스택의 사용자 모드 구성 요소입니다. Worker Process는 상위 파티션의 윈도우즈 Server 2008 인스턴스에서 하위 파티션의 게스트 운영 체제까지 가상 시스템 관리 서비스를 제공합니다. 가상 시스템 관리 서비스는 실행 중인 각 가상 시스템에 대해 별도의 작업자 프로세스를 생성합니다.
- VSP: Virtualization Service Provider: 루트 파티션에 상주하고 VMBus(Virtual Machine Bus)를 통해 하위 파티션에 대한 통합 디바이스 지원을 제공합니다.
- VSC (Virtualization Service Client): 하위 파티션에 있는 통합 디바이스 인스턴스입니다. VSC는 상위 파티션의 VSP(Virtualization Service Providers)에서 제공하는 하드웨어 리소스를 활용합니다. VMBus를 통해 상위 파티션의 해당 VSP와 통신하여 하위 파티션 디바이스 I/O 요청을 충족합니다.
- WinHv (Windows Hypervisor Interface Library): WinHv는 기본적으로 분할된 운영 체제의 드라이버와 표준 Windows 호출 규칙을 사용하여 하이퍼바이저를 호출할 수 있는 하이퍼바이저 간의 브리지입니다.
- WMI: 가상 시스템 관리 서비스는 가상 시스템을 관리하고 제어하기 위한 WMI(Windows Management Instrumentation) 기반API 집합을 제공합니다.
- VM은 하드웨어에 직접 액세스(Access)하지 않고 VM과 하드웨어 사이에 위치한 부모 파티션(Parent Partition)을 통해 액세스 하게 됩니다. Hyper-V의 hypervisor는 부모 파티션에만 드라이버를 설치하면 모든 자식 파티션이 그 장치를 사용할 수 있어 별도로 자식 파티션을 위해 Hypervisor에 특화된 디바이스 드라이버(Device Driver)를 별도로 탑재 시켜야 할 필요가 없습니다. 이러한 구조는 Hypervisor를 최소화 하여 Bug인한 문제의 가능성을 최소화 시켜주고 관리적 이점을 최대화 합니다.
조금 더 쉽게 설명하기 위해 아래와 같이 Hyper-V에서 VM이 디스크 액세스를 과정을 예로 들겠습니다.- User mode의 Application이 디스크 요청을 Kernel Mode에있는 Storage Stack에게 보냅니다.
- Storage Stack의 VSC(Storflt.sys)에서 VMBus로 요청을 보냅니다
- VSC에서 받은 요청은 VMBus를 통해 VSP에게 전달됩니다
- VSP는 받은 요청을 내부 Storage Stack에게 보내 H/W에 액세스 합니다.
이와 같은 Type을 SyntheticType이라고 합니다. 이런 Type을 실행하기 위해서는 Hyper-V가 지원하는 OS이어야 합니다.
이하 Part 2 내용 입니다.
Virtual disk architecture (vhd, vhdx)
vNUMA
System reqirements
지원되는 Windows Guest 운영체제
지원되는 linux 및 FreeBSD VM
세대 및 게스트 별 기능 호환성
Plan for Hyper-V on Windows Server
Scalability
Security
Networking
VM Generation
Discreate Device Assignment
Hyper-V Install and configuration
Hyper-V 설치
가상 스위치 만들기
가상 머신 만들기
Hyper-V deployment
배포
가상 컴퓨터 내보내기 및 가져오기
실시간 마이그레이션을 위한 호스트 설정
가상 컴퓨터 버전 업그레이드
DDA를 사용하여 그래픽 장치 배포
DDA를 사용하여 저장 장치 배치
Manamgent
각 기능 설명
Standard or production checkpoint 선택
검사점 활성화 또는 비활성화
Hyper-V 관리자로 host 관리
호스트 CPU 리소스 제어 관리
VM CPU 그룹 사용
PowerShell Direct로 Windows VM 관리
Hyper-V 복제본 생성
Failover Clustering없이 실제 마이그레이션을 사용하여 VM 이동
예를 들면 윈도우 서버에 vmware workstation을 깔아서 인텔 vm을 만들고 거기에 hyper-v나 vmware esx를 설치해서 win10머신 하나 linux머신 하나 올려서 원활하게 돌리는 것이 가능하다면, 하드웨어 사양은 어느 정도나 되어야 할까요?
단, NT OS만 가능합니다.(https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization)
1. Windows server에 Hyper-V를 구축합니다.
2. Root partition(Host machine)에서 PowerShell cmdlet을 이용하여 ExposeVirtualizationExtensions를 true로 변경합니다.
3. Guest OS를 구동합니다.
4. Hyper-V 기능을 설치합니다.
5. VM을 추가합니다.
자세한 내용은 위에 적어드린 링크를 참고 바랍니다.
본문(게시글)에 적어드린 것처럼 Intel은 VT라는 Processor virtualization 기술을 제공하는 회사입니다. Intel VM이라는 기술을 구글링 해봤으나 나오지 않네요.. 이 부분은 부연 설명 부탁드립니다.
인텔 VM은 기본적으로 인텔 머신을 호스트로 하는 것을 전제로 하는 거라서 당연한 얘기인 것 같긴한데, ARM 에뮬레이션 같은 방식이 아닌 일반적인 VM을 지칭하는 거였습니다.
그리고 리소스에 대한 문의는 실제 하드웨어 설치 대비 어느 정도의 오버헤드나 성능 저하가 발생하는지에 대한 문의입니다. 게스트 머신 자체에 필요한 리소스 + α 일텐데, + α가 어느 정도나 되는지 궁금해셔 여쭙는 것입니다.
그러셨군요!
+@에 대한 부분은 MS 제품의 경우 Hardware recommended가 정해져 있습니다. 대부분의 다른 솔루션들도 +@에 대한 Hardware recommended를 제공할 것입니다.
도움 되셨으면 합니다. 감사합니다.
WSL (Windows subsystem for Linux)은 Microsoft에서 개발한 Linux-compatible kernel interface로 Windows에 Linux (Ubuntu, SUSE)를 설치할 수 있는 architecture를 가지고 있습니다. 문의주신 사항에 대해 Microsoft는 다음과 같이 안내하고 있습니다.(https://docs.microsoft.com/en-us/windows/wsl/wsl2-faq)
"We are investigating ways to help resolve this issue. For example, we expose a set of APIs called Hypervisor Platform that third-party virtualization providers can use to make their software compatible with Hyper-V’s. This lets applications use the Hyper-V architecture for their emulation such as the Google Android Emulator, and VirtualBox 6 and above which are both now compatible with Hyper-V."
해당 덧글이 vmware나 hyper-v를 선택할 때 큰 결정을 줄 수는 없겠지만(선택은 본인의 몫입니다.), 도움이 되었으면 합니다.
vmware로 바꾸니 그런 증상이 없더군요...
뭔가 precision timer에 영향을 미치는거 정도로 추측하는데, 도무지 해결 방법이 없었습니다^^;;
혹시 일반 pc로 hyper-v돌리실때는 참고하셔요.
vmware는 vSGA (Virtual Shared Graphics Accelration)라는 Virtual GPU 기능으로 여러 VM에서 GPU를 공유할 수 있는 기능을 제공하고 있습니다.
하지만 해당 GPU 공유 기술에 대한 최상위 포식자는 사실 Hyper-V의 RemoteFX입니다.
sVGA는 DirectX 9.0c 및 OpenGL 2.1을 지원하는 vmware의 독점 드라이버입니다.
sVGA의 경우 그림과 같이 동작합니다.
이 기술을 API Intercept라고 불리며 아래와 같은 제약이 존재합니다.
1. 그래픽 명령이 사용자 세션에서 GPU를 제어하는 세션 0으로 전송되어야하는 오버 헤드 및 대기 시간을 처리합니다.
2. 3D 렌더링에 사용할 수있는 비디오 메모리가 제한되어 있습니다. vSGA는 VM 당 최대 512MB 비디오 메모리를 지원합니다. 확장성에 도달하기 위해 vRAM은 대개 64-128MB 사이로 설정됩니다. 이것은 거의 모든 티어 1 3D Application에서 너무 낮습니다.
3. 전문 3D 응용 프로그램은 OpenGL 4.3 및 DirectX 11 라이브러리를 찾을 수 없을 때 제대로 실행되지 않거나 실행할 수 없습니다. VMware vSGA의 이전 드라이버는 DirectX 9 및 OpenGL 2.1까지만 지원합니다.
가벼운 작업을 하기에는 sVGA도 나쁘지 않으나 3D 작업 및 복잡한 렌더링을 요구하는 Applications의 경우 Hyper-V의 RemoteFX 기술을 사용하는 것이 좋습니다.
Hyper-V RemoteFX에 대한 기술 요약은 다음 페이지(링크)를 참고하시기 바라며
http://technet.microsoft.com/en-us/library/ff817578(WS.10).aspx
http://technet.microsoft.com/ko-kr/library/ff817602(WS.10).aspx
http://technet.microsoft.com/en-us/library/ff817586(WS.10).aspx
http://technet.microsoft.com/en-us/library/ff817611(WS.10).aspx
http://technet.microsoft.com/en-us/library/ff817591(WS.10).aspx
http://technet.microsoft.com/en-us/library/ff817581(WS.10).aspx
http://technet.microsoft.com/en-us/library/ff817595(WS.10).aspx
추후에는 RemoteFX를 설정하시어 즐겁고 쾌적한 Graphic 환경을 체험- Graphic card driver module에서 바로 가상화하는 즐거움 - 해보시기 바랍니다.
제 경우 홈서버여서 GPU는 인텔 내장 그래픽을 사용중이었습니다.
timer가 아니라 인텔이어도 동영상은 GPU 가속을 할테니 그 문제였을수도 있겠네요.
(내부 VM에서 동영상 재생을 한것은 아니고, host OS에서 재생시 저런 증상이 있었었구요.)
어찌되었든 관심 가져주시고 덧글 남겨주셔서 감사합니다.
혹시 Hyper-V 활성화하면 다른 VM을 쓸 수 없는 이유를
아키텍쳐적 한계 때문에 어쩔 수 없다고 설명해주신 것이 이 글에 포함되어 있나요?
질문주신 내용은 본문에 추가되어있지 않으며, 추가를 하지 않을 예정입니다. 다만 질문주신 내용을 간단히 답변 드리면, Hyper-V 설치 후 vmware 설치는 resources 충돌로 불가능 합니다. 이는 본문에 적어드린 것 처럼 Hyper-V는 Host 또한 Root partition이라는 영역으로 설정하기 때문에 Root partition에 또다른 가상 머신이 올라가게 되면 Processor에서 지원하는 가상화 기능을 중복으로 사용할 수 없기에 vmware와 Hyper-V를 동시에 사용할 수 없습니다. 따라서 Windows server 또는 Windows에 vmware와 Hyper-V를 동시에 구축했다면 Windows에서 Hyper-V의 가상기능을 강제로 Disable 처리한 후 vmware를 사용할 수 있습니다.
관련 명령어는 다음과 같습니다. "bcdedit /set hypervisorlaunchtype off"
올리신 글과 Youtube 모두 소중히 잘 읽고 있습니다.
2장도 기대하겠습니다!
매우 도움이 되는 내용들 감사드립니다.
정독하고 공부해야겠습니다!!