XCP-ng & Xen Overview
Xen 기반 오픈소스 가상화 플랫폼 — KVM, ESXi와 근본적으로 다른 마이크로커널 하이퍼바이저
📌 이 글의 목적
Xen은 KVM, ESXi와 함께 서버 가상화의 3대 하이퍼바이저 아키텍처 중 하나임. KVM(Linux 커널 모듈)이나 ESXi(독자 커널)와 달리, Xen은 하드웨어 바로 위에 마이크로커널 하이퍼바이저가 먼저 올라가고, 그 위에 관리 VM(Dom0)이 뜨는 독특한 구조를 가짐.
이 글을 읽고 나면:
- Xen의 Dom0/DomU 아키텍처를 이해하고 KVM/ESXi와 비교할 수 있음
- PV, HVM, PVHVM, PVH 가상화 모드의 차이를 설명할 수 있음
- Split Driver Model(프론트엔드/백엔드)의 I/O 가상화 방식을 이해할 수 있음
- XCP-ng의 관리 스택(Xen Orchestra, XAPI)의 역할을 파악할 수 있음
1. Xen의 역사
1.1 타임라인
1.2 왜 Xen을 알아야 하는가
- AWS EC2가 원래 Xen 기반이었음. 클라우드 역사를 이해하는 핵심
- KVM/ESXi와 근본적으로 다른 아키텍처라 비교 학습에 좋음
- XCP-ng는 Proxmox의 대안으로 종종 언급되는 오픈소스 플랫폼
- Citrix의 구독 전환으로 XCP-ng로의 이동이 증가 중
2. Xen 아키텍처
2.1 핵심 구조
Xen의 가장 큰 차이점: 하이퍼바이저가 하드웨어 바로 위에 먼저 올라감.
2.2 3자 아키텍처 비교
| 항목 | Xen | KVM | ESXi |
|---|---|---|---|
| 하이퍼바이저 위치 | HW 바로 위 | Linux 커널 모듈 | HW 바로 위 (VMkernel) |
| 관리 OS | Dom0 (별도 Linux VM) | 호스트 Linux 자체 | User World (내장) |
| 드라이버 위치 | Dom0 안의 Linux 드라이버 | 호스트 Linux 드라이버 | VMkernel VIB |
| Type | Type 1 (순수) | Type 1 (하이브리드) | Type 1 (순수) |
2.3 Dom0 (관리 도메인)
Dom0는 Xen 부팅 시 가장 먼저 생성되는 **특권 도메인(Privileged Domain)**임.
| 항목 | 설명 |
|---|---|
| OS | 일반적으로 Linux (XCP-ng는 CentOS Stream 기반) |
| 역할 | 하드웨어 드라이버 실행, 관리 API(XAPI), DomU I/O 처리 |
| 특권 | 하드웨어에 직접 접근 가능, Xen 하이퍼콜을 사용하여 하이퍼바이저 제어 |
| 성능 영향 | Dom0가 과부하되면 모든 DomU의 I/O 성능이 저하됨 |
💡 Dom0는 KVM에서의 호스트 OS와 유사한 역할. 차이는 KVM의 호스트 OS는 하드웨어를 직접 제어하지만, Dom0는 Xen 하이퍼바이저를 통해 간접적으로 제어한다는 점.
⚠️ Dom0 병목은 Xen 아키텍처의 고유한 약점임. 모든 DomU의 I/O가 Dom0를 경유하므로, Dom0의 CPU/메모리가 부족하면 전체 시스템 성능에 영향을 미침. 이를 완화하기 위해 Stub Domain, Driver Domain 같은 개념이 존재함.
2.4 DomU (게스트 도메인)
DomU는 일반 게스트 VM. 가상화 모드에 따라 3가지로 나뉨:
| 모드 | 설명 | 게스트 OS 수정 | HW 가상화 필요 |
|---|---|---|---|
| PV (Paravirtualization) | 게스트 커널이 수정되어 하이퍼콜로 직접 통신 | ✅ 필요 | ❌ |
| HVM (Hardware Virtual Machine) | 전가상화. 수정 없는 OS 실행 | ❌ 불필요 | ✅ VT-x/AMD-V |
| PVH (PV in HVM container) | HVM + PV 드라이버 조합. 현재 권장 | ❌ (드라이버만) | ✅ |
3. 가상화 모드 상세
3.1 PV (Paravirtualization)
Xen의 원래 가상화 방식. 2003년 Xen이 처음 나왔을 때는 VT-x가 없어서 소프트웨어적으로 가상화를 구현해야 했음.
- 게스트 OS 커널이 Xen을 인식하도록 수정되어야 함
- 특권 명령어 대신 **하이퍼콜(Hypercall)**을 사용하여 하이퍼바이저와 통신
- 하드웨어 가상화(VT-x)가 없어도 동작
- Linux는 커널에 PV 지원이 내장되어 있음. Windows는 PV 불가능
- 현재는 PVH로 대체되어 레거시 취급됨
3.2 HVM (Hardware Virtual Machine)
VT-x/AMD-V를 활용한 전가상화. KVM, ESXi와 동일한 방식.
- 게스트 OS 수정 불필요. Windows 포함 모든 OS 실행 가능
- QEMU 기반 장치 에뮬레이션 사용 (Xen은 QEMU를 장치 모델로 활용)
- PV 드라이버를 설치하면 성능 향상 (PVHVM)
3.3 PVH (현재 권장)
PV와 HVM의 장점을 결합한 현대적 방식.
| 항목 | PV | HVM | PVH |
|---|---|---|---|
| CPU 가상화 | 하이퍼콜 | VT-x | VT-x |
| I/O | PV 드라이버 | 에뮬레이션 (또는 PV 드라이버) | PV 드라이버 |
| 게스트 수정 | 필요 | 불필요 | 불필요 (드라이버만) |
| Windows | ❌ | ✅ | ✅ (PV 드라이버 설치 시) |
| 성능 | 좋음 | 보통 (PV 드라이버 없이) | 최고 |
| 현재 상태 | 레거시 | 지원됨 | 권장 |
💡 VirtIO와의 비교: KVM의 VirtIO는 "게스트가 가상 환경임을 인지하고 최적화된 드라이버로 통신"하는 준가상화 방식. Xen의 PV 드라이버도 같은 개념이지만, 구현이 다름 (VirtIO는 Virtqueue 기반, Xen은 Grant Table + Event Channel 기반).
4. I/O 가상화 — Split Driver Model
4.1 구조
Xen의 I/O 가상화 핵심은 Split Driver Model임. DomU의 I/O는 Dom0를 경유함.
4.2 핵심 메커니즘
| 메커니즘 | 설명 | KVM 대응 |
|---|---|---|
| Grant Table | DomU가 Dom0에 메모리 영역을 "허가"하여 공유 | Virtqueue (공유 메모리 링 버퍼) |
| Event Channel | 도메인 간 비동기 알림 | eventfd / irqfd |
| XenStore | 도메인 간 설정 공유 (키-값 저장소) | — (없음, QEMU가 직접 처리) |
| Ring Buffer | 요청/응답을 주고받는 원형 버퍼 | Virtqueue의 Available/Used Ring |
4.3 VirtIO와의 비교
| 항목 | Xen Split Driver | KVM VirtIO |
|---|---|---|
| 데이터 교환 | Grant Table + Ring Buffer | Virtqueue (공유 메모리) |
| 알림 | Event Channel | eventfd/irqfd |
| 설정 공유 | XenStore | PCI Configuration Space |
| I/O 경로 | DomU → Dom0 → HW (Dom0 경유 필수) | Guest → QEMU/vhost → HW |
| 커널 가속 | — | vhost-net (커널 레벨) |
| Dom0 병목 | ⚠️ 있음 | 없음 (vhost 시 직접 처리) |
⚠️ Xen의 구조적 약점: 모든 I/O가 Dom0를 경유하므로, Dom0가 병목이 될 수 있음. KVM의 vhost-net은 I/O를 커널에서 직접 처리하여 유저 공간(QEMU)을 우회함. 이 차이가 AWS가 Xen에서 KVM(Nitro)으로 전환한 이유 중 하나.
4.4 PCI Passthrough
Dom0를 우회하여 DomU에 물리 장치를 직접 할당하는 방식. I/O 병목을 해결할 수 있음.
- IOMMU(VT-d/AMD-Vi) 필수
- GPU, NVMe, 고성능 NIC에 사용
- Dom0 경유 없이 네이티브 성능
5. XCP-ng 관리 스택
5.1 XCP-ng란
XCP-ng(Xen Cloud Platform - next generation)는 Citrix XenServer의 오픈소스 포크임.
| 항목 | XenServer (Citrix) | XCP-ng |
|---|---|---|
| 라이선스 | 구독 전용 (2024~) | GPLv2 (무료) |
| 기반 | Xen 하이퍼바이저 | 동일 |
| 관리 | XenCenter (Windows 전용) | Xen Orchestra (웹) |
| API | XAPI | XAPI (동일) |
| 커뮤니티 | Citrix 주도 | Vates 주도, 오픈 커뮤니티 |
5.2 관리 도구
| 도구 | 역할 | 대응 |
|---|---|---|
| Xen Orchestra (XO) | 웹 기반 관리 UI + 백업 + 모니터링 | Proxmox 웹 UI, vCenter |
| XAPI | Xen Management API | Proxmox REST API, vSphere API |
| xe CLI | 커맨드라인 관리 도구 | qm/pct (Proxmox), esxcli (ESXi) |
| XO Backup | 전체/증분/델타 백업, DR | PBS (Proxmox), Veeam (VMware) |
💡 Xen Orchestra는 Proxmox 웹 UI와 달리 별도 VM/컨테이너에 설치해야 함. Proxmox는 각 노드에 관리 UI가 내장되어 있지만, XCP-ng는 XO를 별도로 배포해야 전체 관리가 가능. vCenter와 유사한 구조.
5.3 스토리지
| 스토리지 | 지원 | 비고 |
|---|---|---|
| Local (ext, LVM) | ✅ | 기본 |
| NFS | ✅ | 파일 기반 공유 |
| iSCSI | ✅ | 블록 기반 |
| FC (Fibre Channel) | ✅ | 엔터프라이즈 SAN |
| GlusterFS | ✅ | 분산 파일시스템 |
| ZFS | ⚠️ | 커뮤니티 지원 (공식은 아님) |
| Ceph | ⚠️ | 실험적 |
| XOSTOR | ✅ | XCP-ng 자체 분산 스토리지 (LINSTOR 기반) |
Proxmox의 ZFS/Ceph 네이티브 지원과 비교하면 XCP-ng의 스토리지 옵션은 다소 제한적. XOSTOR가 vSAN/Ceph에 대응하지만 아직 성숙도가 낮은 편.
5.4 네트워크
- Open vSwitch(OVS) 가 기본 가상 스위치 (Proxmox는 Linux Bridge가 기본)
- VLAN, Bonding, LACP 지원
- SDN은 기본적 수준 (NSX나 Proxmox SDN 대비 기능 제한)
5.5 HA와 라이브 마이그레이션
| 기능 | 지원 | 비고 |
|---|---|---|
| 라이브 마이그레이션 | ✅ | 공유 스토리지 필요 |
| Storage Live Migration | ✅ | 로컬 → 로컬 디스크 이동 |
| HA | ✅ | 풀(Pool) 기반, 펜싱 포함 |
| 자동 부하 분산 | ❌ | DRS 같은 기능 없음 (VMware, Proxmox와 동일) |
| XO Backup | ✅ | 전체/증분/델타, 오프사이트 복제 |
6. 하이퍼바이저 4종 비교
6.1 아키텍처 비교
| 항목 | XCP-ng (Xen) | Proxmox (KVM) | VMware (ESXi) | Hyper-V |
|---|---|---|---|---|
| 하이퍼바이저 | Xen 마이크로커널 | Linux + KVM 모듈 | VMkernel | Windows 하이퍼바이저 |
| 관리 OS | Dom0 (Linux) | 호스트 Linux | User World | Root Partition (Windows) |
| I/O 모델 | Split Driver (Dom0 경유) | VirtIO + vhost | VMX + PVSCSI | VMBus (VSP/VSC) |
| 관리 UI | Xen Orchestra (별도) | 웹 UI (노드 내장) | vCenter (별도) | WAC / SCVMM |
| API | XAPI | REST API | REST + SOAP | PowerShell + WMI |
| 컨테이너 | ❌ | LXC 내장 | ❌ | Windows Container |
| 라이선스 | GPLv2 (무료) | AGPL (무료) | 구독 (Broadcom) | Windows Server 필요 |
6.2 XCP-ng의 강점과 한계
강점:
| 강점 | 설명 |
|---|---|
| Xen 아키텍처 | 하이퍼바이저가 커널과 분리되어 보안 모델이 명확 |
| OVS 기본 | 네트워크 가상화에 유리 |
| Xen Orchestra | 웹 UI + 백업 + 모니터링 올인원 (무료) |
| Citrix 호환 | XenServer에서 마이그레이션 용이 |
| 커뮤니티 | Vates 주도로 활발한 개발 |
한계:
| 한계 | 설명 |
|---|---|
| Dom0 병목 | I/O가 Dom0를 경유하여 고부하 시 병목 가능 |
| 스토리지 옵션 | ZFS/Ceph가 공식 지원이 아님. Proxmox 대비 제한적 |
| 국내 레퍼런스 | 거의 없음. 커뮤니티/자료가 Proxmox보다 적음 |
| XO 별도 설치 | 관리 UI가 노드에 내장되지 않아 초기 설정이 번거로움 |
| 컨테이너 미지원 | LXC/Docker 내장 없음 |
6.3 어떤 환경에서 XCP-ng를 선택하는가
| 상황 | 추천 | 이유 |
|---|---|---|
| Citrix XenServer에서 탈출 | ✅ | 아키텍처 동일, 마이그레이션 쉬움 |
| OVS 기반 네트워크 필요 | ✅ | OVS가 기본 |
| Xen 아키텍처 학습 | ✅ | 유일한 오픈소스 Xen 플랫폼 |
| ZFS/Ceph 필요 | ❌ | Proxmox가 더 적합 |
| LXC 컨테이너 필요 | ❌ | Proxmox만 지원 |
| 국내 커뮤니티/자료 | ❌ | Proxmox가 압도적 |
| 일반적인 VMware 대안 | ⚠️ | Proxmox가 더 범용적 |
7. AWS와 Xen — 클라우드 역사
AWS EC2는 2006년 출시 시 Xen 기반이었음.
AWS가 Xen에서 KVM으로 전환한 이유:
- Dom0 병목 제거: Nitro는 I/O를 전용 하드웨어(Nitro Card)로 오프로드하여 Dom0/호스트 OS 병목을 제거함
- 보안 강화: Nitro는 하이퍼바이저를 최소화하고 I/O를 하드웨어로 격리
- 성능 향상: 호스트 오버헤드 감소로 고객에게 더 많은 리소스 제공
- KVM의 발전: KVM이 Xen 대비 성능/기능 격차를 좁히고 역전함
💡 AWS의 전환은 "Xen이 나쁘다"가 아니라 "Dom0 경유 I/O 모델의 한계를 하드웨어로 해결했더니 KVM이 더 적합해졌다"는 의미. Xen 자체는 여전히 안정적인 하이퍼바이저임.
정리
Xen은 KVM, ESXi와 근본적으로 다른 아키텍처를 가진 하이퍼바이저임.
핵심 포인트:
- 마이크로커널 하이퍼바이저가 HW 위에 먼저 올라가고, **Dom0(관리 VM)**가 드라이버와 관리를 담당
- Split Driver Model로 DomU의 I/O가 Dom0를 경유 — 구조적으로 깔끔하지만 Dom0 병목 가능
- PVH가 현재 권장 모드 — HVM의 호환성 + PV 드라이버의 성능
- XCP-ng는 Citrix XenServer의 오픈소스 포크. Xen Orchestra로 관리
- AWS EC2가 Xen에서 KVM으로 전환한 이유는 Dom0 병목을 하드웨어로 해결한 Nitro 아키텍처 때문
🔗 관련 문서
- KVM & QEMU Architecture — KVM 아키텍처 비교
- ESXi Architecture — ESXi 아키텍처 비교
- Hyper-V Overview — Windows 하이퍼바이저
- Hypervisor Virtualization — Type 1/2 하이퍼바이저 개념
- XCP-ng Series Index — 시리즈 목차