00. 하이퍼바이져 정보

하이퍼바이저란

1. 하이퍼바이저(Hypervisor)는 하나의 물리 서버에서 여러 가상 머신(VM)을 실행하고 관리하는 가상화 계층입니다.
2. 각 VM은 vCPU, 메모리, 디스크, NIC를 독립 장치처럼 사용하지만, 실제 자원은 하이퍼바이저와 호스트 운영체제가 분배·제어합니다. 따라서 하나의 서버에서 Linux, Windows, 데이터베이스, GitLab, Kubernetes 노드처럼 서로 다른 역할의 시스템을 분리해 운영할 수 있습니다.

하이퍼바이저의 주요 역할은 다음과 같습니다.

역할	설명
CPU/메모리 가상화	물리 CPU와 메모리를 VM별 자원으로 분리·할당
디스크 가상화	스토리지를 VM별 가상 디스크로 제공
네트워크 가상화	물리 NIC, 브리지, VLAN을 VM의 가상 NIC와 연결
장치 가상화	디스크 컨트롤러, NIC, USB, GPU, PCI 장치를 가상화하거나 직접 할당
격리와 운영	VM 간 장애 영향을 줄이고 생성, 백업, 복구, 마이그레이션을 관리

가상화가 필요한 이유

가상화의 목적은 단순한 서버 통합이 아닙니다. 자원 활용, 서비스 격리, 표준화, 복구, 테스트 환경 재현에 더 큰 가치가 있습니다.

• 여러 워크로드를 하나의 서버 또는 클러스터에 배치해 자원 활용률을 높일 수 있습니다.
• 서비스별 운영체제와 의존성을 분리해 패키지 충돌과 장애 전파를 줄일 수 있습니다.
• 템플릿과 Cloud-Init으로 표준 OS와 보안 설정을 반복 배포할 수 있습니다.
• VM 단위 백업, 복구, 복제, 스냅샷을 사용할 수 있습니다.
• Kubernetes, CI/CD, 장애 시나리오를 동일한 조건에서 재현하기 쉽습니다.

다만 VM을 많이 만들 수 있다고 해서 안정적으로 운영할 수 있는 것은 아닙니다. CPU 경합, 메모리 부족, 디스크 I/O 경쟁, 네트워크 병목을 함께 설계해야 합니다.

스냅샷도 백업이 아닙니다. 스냅샷은 단기 변경 보호에 유용하지만, 스토리지 장애, 랜섬웨어, 사이트 장애까지 대비하려면 별도 저장소의 백업과 실제 복구 검증이 필요합니다.

Type 1과 Type 2

하이퍼바이저는 일반적으로 Type 1과 Type 2로 구분합니다.

구분	Type 1	Type 2
설치 방식	물리 서버에 전용 가상화 플랫폼으로 설치	일반 OS 위에서 애플리케이션으로 실행
주 용도	서버, 데이터센터, 프라이빗 클라우드	개인 PC, 개발, 교육, 실습
예시	Proxmox VE, VMware ESXi, Nutanix AHV, Hyper-V 기반 서버 환경	VirtualBox, VMware Workstation, Fusion, Parallels
운영 기능	클러스터, HA, 백업, 마이그레이션	로컬 VM 생성과 테스트 중심

Proxmox VE는 Debian Linux와 KVM을 기반으로 하지만, 일반 데스크톱 OS에서 VirtualBox를 실행하는 방식이 아닙니다. 물리 서버에 전용 가상화 플랫폼으로 설치해 운영하므로 실무적으로 Type 1 또는 bare-metal Linux hypervisor로 이해하면 됩니다.

VM은 어떻게 동작하는가

VM은 독립 서버처럼 보이지만, 실제로는 하이퍼바이저가 제공하는 가상 하드웨어 위에서 실행됩니다.

Guest OS
├── vCPU / vMemory
├── Virtual Disk
├── Virtual NIC
└── BIOS or UEFI
        │
        ▼
QEMU / KVM / VirtIO
        │
        ▼
Linux Kernel, Storage, Network
        │
        ▼
Physical CPU, RAM, Disk, NIC

CPU와 메모리

1. VM에 할당한 vCPU는 물리 CPU 코어가 아니라 게스트 OS에 제공하는 논리 CPU입니다. 물리 코어보다 많은 vCPU를 할당하는 CPU overcommit은 가능하지만, 고부하 VM이 동시에 실행되면 CPU 경합과 응답 지연이 발생할 수 있습니다.
2. 메모리 overcommit은 더 보수적으로 접근해야 합니다. CPU 부족은 주로 성능 저하로 이어지지만, 메모리 부족은 게스트 또는 호스트의 swap, OOM, VM 불안정으로 이어질 수 있습니다.
3. Proxmox VE의 Ballooning은 VM 메모리를 동적으로 조정하는 기능입니다. 하지만 호스트 메모리가 부족하면 게스트가 메모리를 회수하거나 swap/OOM 상황에 놓일 수 있으므로, 데이터베이스처럼 메모리 요구량이 예측 가능한 핵심 서비스에는 신중히 적용해야 합니다.

디스크와 네트워크

VM 디스크는 LVM, ZFS, NFS, iSCSI, Ceph 같은 스토리지 위의 이미지 또는 논리 볼륨으로 제공됩니다.

Guest File System
→ Guest Block Layer
→ VirtIO SCSI / VirtIO Block
→ QEMU 또는 vhost backend
→ Host Kernel
→ Storage Backend
→ Physical Disk or Network Storage

따라서 VM 디스크 성능은 게스트 파일시스템만으로 결정되지 않습니다. 스토리지 종류, 캐시 정책, 디스크 성능, 스토리지 네트워크, 동시 I/O, 백업 및 스냅샷 작업이 함께 영향을 줍니다.

Proxmox VE에서는 일반적으로 Linux Bridge로 VM NIC를 물리 NIC에 연결합니다.

Physical NIC
└── Linux Bridge: vmbr0
    ├── VM 101
    ├── VM 102
    └── VM 103

VLAN-aware Bridge를 사용하면 VM별 VLAN Tag로 관리망, 서비스망, 스토리지망 등을 논리적으로 분리할 수 있습니다. 다만 스토리지, 백업, VM 서비스, 클러스터 통신을 하나의 NIC 또는 스위치에 집중하면 병목과 장애 영향 범위가 커질 수 있습니다.

KVM, QEMU, VirtIO

Proxmox VE의 KVM 기반 VM은 KVM, QEMU, VirtIO가 함께 동작합니다.

구성 요소	역할
KVM	Linux 커널의 가상화 기능입니다. Intel VT-x 또는 AMD-V를 사용해 게스트 CPU 실행을 하드웨어 가속합니다.
QEMU	VM의 주 실행 프로세스입니다. BIOS/UEFI, 디스크 컨트롤러, NIC 등 가상 하드웨어를 제공합니다.
VirtIO	디스크·네트워크 등의 성능을 높이기 위한 반가상화 장치 인터페이스입니다.

KVM 사용을 위해서는 CPU와 BIOS/UEFI에서 Intel VT-x 또는 AMD-V가 활성화되어야 합니다. PCI Passthrough나 SR-IOV를 사용하려면 Intel VT-d 또는 AMD IOMMU도 확인해야 합니다.

# Intel: vmx, AMD: svm 플래그 확인
$> grep -E -c '(vmx|svm)' /proc/cpuinfo

# CPU 가상화 관련 정보 확인
$> lscpu | grep -i virtualization

QEMU/KVM 기반 VM은 qm 명령으로 관리합니다.

$> qm list
$> qm config 101
$> qm start 101
$> qm shutdown 101

VirtIO는 게스트 OS가 가상화 환경을 인식하고 하이퍼바이저와 효율적으로 통신하도록 하는 반가상화 장치입니다. 일반적인 Linux VM에서는 다음 구성을 우선 검토할 수 있습니다.

항목	권장
디스크 컨트롤러	VirtIO SCSI single
디스크 버스	SCSI
네트워크 모델	VirtIO
Guest Agent	활성화
펌웨어	SeaBIOS 또는 OVMF
머신 타입	i440fx 또는 q35

Windows는 VirtIO 드라이버를 설치 과정에서 별도로 로드해야 할 수 있습니다. 반면 대부분의 Linux 배포판은 VirtIO 드라이버를 기본 포함합니다.

VM과 LXC 컨테이너

Proxmox VE는 KVM 기반 VM과 LXC 컨테이너를 모두 관리합니다.

구분	VM	LXC 컨테이너
커널	VM마다 게스트 커널 사용	호스트 Linux 커널 공유
격리	하드웨어 가상화 기반의 상대적으로 강한 격리	OS 수준 격리
운영체제	Linux, Windows, BSD 등	일반적으로 Linux
자원 사용량	상대적으로 큼	상대적으로 가벼움
적합한 용도	Windows, DB, Kubernetes 노드, 강한 격리 필요 서비스	경량 Linux 서비스, 유틸리티, 테스트

Kubernetes와 LXC는 같은 의미가 아닙니다. 실무에서는 Kubernetes 노드를 VM으로 구성하고, VM 내부의 containerd 또는 CRI-O에서 애플리케이션 컨테이너를 실행하는 구조가 일반적입니다.

Proxmox VE
└── KVM VM
    └── Linux
        └── Kubernetes Node
            └── containerd or CRI-O
                └── Application Container

Proxmox VE 운영 관점

Proxmox VE는 단순한 VM 실행기가 아니라 VM/컨테이너, 스토리지, 네트워크, 백업, 클러스터, HA, 권한, API를 통합한 가상화 플랫폼입니다.

Web UI / CLI / REST API
        │
Proxmox VE Management
        │
QEMU / KVM / LXC / VirtIO
        │
Linux Kernel / Storage / Network
        │
Physical Hardware

운영 시에는 다음 원칙을 기억하면 좋습니다.

• VM 수보다 CPU, 메모리, I/O, 네트워크 대역폭을 먼저 산정합니다.
• CPU overcommit은 가능하지만 메모리 overcommit은 보수적으로 적용합니다.
• 스냅샷과 독립 백업을 구분하고, 백업은 실제 복구까지 검증합니다.
• 템플릿과 Cloud-Init으로 OS, 보안, 에이전트 구성을 표준화합니다.
• VirtIO 디스크/NIC와 QEMU Guest Agent를 우선 검토합니다.
• 관리망, 서비스망, 스토리지망, 클러스터망은 요구사항에 따라 분리합니다.
• 장애는 게스트 OS → VM 설정 → Proxmox 노드 → 스토리지 → 물리 네트워크 순서로 계층화해 점검합니다.

핵심 정리

• 하이퍼바이저는 물리 서버에서 여러 VM을 실행하고 자원을 분리·관리하는 계층입니다.
• Proxmox VE는 Debian 기반에서 KVM/QEMU VM과 LXC 컨테이너를 통합 관리하는 가상화 플랫폼입니다.
• KVM은 CPU 가상화 가속, QEMU는 VM과 가상 장치 제공, VirtIO는 고성능 반가상화 장치 인터페이스를 담당합니다.
• VM은 게스트 커널을 포함하고, LXC는 호스트 Linux 커널을 공유합니다.
• 안정적인 운영을 위해서는 VM 설정뿐 아니라 스토리지, 네트워크, 백업, 클러스터, 표준화, 복구 검증까지 함께 설계해야 합니다.

 

http://igoni.kr/02.Open-Infra/13.%20Proxmox%20%EC%A0%95%EB%B3%B4/00.%20%ED%95%98%EC%9D%B4%ED%8D%BC%EB%B0%94%EC%9D%B4%EC%A0%B8%20%EC%A0%95%EB%B3%B4.html

00. 하이퍼바이져 정보 - 이곤아이.kr