콘텐츠로 이동






Proxmox VE VM 관리 메뉴 이해하기 - Hardware, Options, Firewall, Permissions

Proxmox VE VM 관리 메뉴 이해하기

Proxmox VE에서 VM을 생성한 뒤 실제 운영에 필요한 설정은 크게 네 영역으로 나눌 수 있습니다.

Proxmox VE VM Management

VM
├── Hardware
│   └── 가상 CPU, 메모리, 디스크, NIC, BIOS, USB 등 가상 하드웨어
│
├── Options
│   └── 부팅, 종료, Guest Agent, Hotplug, 보호, 태그 등 운영 동작 정책
│
├── Firewall
│   └── VM 단위 네트워크 접근 제어
│
└── Permissions
    └── 사용자·그룹·역할·ACL 기반 VM 접근 권한

각 메뉴의 역할을 단순화하면 다음과 같습니다.

메뉴 핵심 역할 대표 설정
Hardware VM이 사용할 가상 장치 구성 CPU, Memory, Disk, NIC, CD/DVD, BIOS, TPM
Options VM의 기동·종료·관리 동작 설정 On Boot, Startup Order, Agent, Hotplug, Protection
Firewall VM 네트워크 접근 제어 Inbound/Outbound Rule, IPSet, Security Group
Permissions VM 관리 권한 제어 User, Group, Role, ACL, Pool 권한

이 문서는 VM 단위 설정을 중심으로 작성했지만, 대부분은 LXC 컨테이너에도 유사한 방식으로 적용할 수 있습니다.

VM Hardware 메뉴

VM의 Hardware 메뉴는 가상 머신이 사용할 CPU, 메모리, 디스크, 네트워크 카드, CD-ROM, BIOS, TPM, USB 장치 등의 가상 하드웨어를 관리하는 영역입니다.

Web UI에서 다음 경로로 이동합니다.

Datacenter
└── Node
    └── VM
        └── Hardware

일반적인 Linux VM은 아래와 같은 구성으로 시작할 수 있습니다.

VM Hardware Example

├── Memory: 8192 MiB
├── Processors: 4 Cores
├── BIOS: OVMF (UEFI)
├── Machine: q35
├── SCSI Controller: VirtIO SCSI single
├── Hard Disk: scsi0, 100GB
├── CD/DVD Drive: Linux ISO
├── EFI Disk: efidisk0
├── Network Device: net0, VirtIO
├── CloudInit Drive: ide2
└── TPM State: 필요 시 추가

Memory

Memory는 Guest OS에 제공할 최대 메모리 용량입니다.

Memory: 8192 MiB

위 설정은 VM에 최대 8GB 메모리를 할당한다는 의미입니다.

항목 설명
Memory VM이 사용할 최대 메모리
Ballooning Device 호스트 메모리 압박 시 Guest 메모리를 동적으로 조정하는 기능
Minimum Memory Ballooning 시 줄어들 수 있는 최소 메모리
Memory Hotplug 실행 중인 VM에 메모리 추가
NUMA 다중 Socket 서버에서 CPU·메모리 토폴로지를 반영하는 기능

운영 기준은 다음과 같습니다.

일반 Linux VM
└── 고정 메모리 또는 제한적 Ballooning 검토

Database / Redis / Prometheus / Elasticsearch
└── 고정 메모리 우선 검토

Kubernetes Worker
└── Pod Resource와 Node 자원 여유를 고려해 보수적으로 설정

메모리 Hotplug 필요
└── NUMA + Memory Hotplug + Guest OS 지원 여부 확인

메모리는 CPU보다 과할당에 더 신중해야 합니다.

CPU 부족은 일반적으로 지연 시간 증가로 이어지지만, 메모리 부족은 Guest OS OOM, 호스트 OOM, Swap 증가, 서비스 장애로 이어질 수 있습니다.

Processors

Processors는 VM의 가상 CPU(vCPU)를 설정하는 항목입니다.

Sockets: 1
Cores: 4

Total vCPU = Sockets × Cores
Total vCPU = 1 × 4 = 4
항목 설명
Sockets Guest OS에 노출할 CPU Socket 수
Cores Socket당 Core 수
vCPU Guest OS에서 인식하는 논리 CPU 수
CPU Type Guest OS에 노출할 CPU 모델
CPU Limit VM 최대 CPU 사용량 제한
CPU Units CPU 경합 시 상대적 우선순위
NUMA 대규모 CPU·메모리 VM의 NUMA 구조 반영

일반적인 Linux VM은 Sockets: 1로 두고 필요한 Cores를 할당하는 구성이 단순합니다.

Small VM
├── Sockets: 1
└── Cores: 2

Application VM
├── Sockets: 1
└── Cores: 4

Database VM
├── Sockets: 1
└── Cores: 8

CPU Type은 클러스터 운영에 중요한 항목입니다.

CPU Type 특징 적합한 환경
host 현재 노드 CPU 기능을 최대한 Guest에 노출 단일 노드 또는 동일 CPU 세대 클러스터
호환성 CPU 모델 여러 노드 간 공통 CPU 기능 중심 이기종 CPU 클러스터, 라이브 마이그레이션
기본 CPU 모델 호환성 중심의 기본 설정 일반적인 범용 환경

host CPU Type은 성능과 CPU 명령어 활용 측면에서 유리할 수 있습니다.

하지만 노드별 CPU 세대나 CPU 제조사가 다른 클러스터에서는 라이브 마이그레이션 시 CPU 기능 차이로 VM 이동이 제한될 수 있습니다.

동일한 CPU 세대의 균질 클러스터
└── CPU Type: host 검토

서로 다른 CPU 세대가 섞인 클러스터
└── 공통 호환 CPU Type 검토

장기적으로 노드 교체·증설 예정
└── 마이그레이션 호환성 기준의 CPU 정책 수립

BIOS

BIOS는 Guest OS가 부팅할 때 사용하는 펌웨어 방식입니다.

Proxmox VE에서는 일반적으로 SeaBIOS와 OVMF(UEFI)를 제공합니다.

BIOS 설명 적합한 환경
SeaBIOS Legacy BIOS 방식 오래된 OS, 단순 Linux VM, 기존 BIOS 기반 VM
OVMF UEFI 펌웨어 방식 최신 Linux, Windows 11, TPM, Secure Boot, PCIe Passthrough 
SeaBIOS
└── Legacy BIOS Boot

OVMF
└── UEFI Boot
    ├── EFI Disk 필요
    ├── TPM 연계 가능
    ├── Secure Boot 검토 가능
    └── 최신 OS·PCIe 구성에 적합

다음과 같은 환경에서는 OVMF를 우선 검토합니다.

  • Windows 11
  • Windows Server의 UEFI 표준 구성
  • Secure Boot가 필요한 환경
  • TPM이 필요한 환경
  • GPU 또는 PCIe Passthrough
  • 신규 Linux VM 표준화
  • UEFI 부팅이 필요한 Appliance

BIOS 변경은 기존 운영 VM의 부팅 방식에 영향을 줄 수 있습니다.

운영 VM BIOS 변경
└── 부팅 불가 위험

권장
├── 신규 VM 또는 템플릿에서 표준 결정
└── 기존 VM은 별도 Clone 환경에서 충분히 검증 후 변경

Machine

Machine Type은 VM에 제공되는 가상 칩셋과 장치 구조를 설정합니다.

일반적으로 i440fx와 q35를 사용합니다.

Machine Type 특징 적합한 환경
i440fx 전통적인 PC 칩셋 기반 기존 VM 호환성, 단순 구성
q35 최신 PC 칩셋, PCIe 지원 UEFI, 최신 OS, PCIe Passthrough, 신규 표준 VM 
i440fx
├── 전통적인 가상 칩셋
└── 기존 OS 호환성 중심

q35
├── PCIe 기반 장치 구성
├── OVMF와 자주 조합
└── 신규 VM 표준화에 적합

일반적인 신규 Linux VM에서는 q35를 표준으로 검토할 수 있습니다.

단, 기존 운영 VM은 Machine Type을 변경하면 NIC, 디스크, PCI 장치 순서가 바뀌거나 부팅 문제가 생길 수 있으므로, 사전 검증 없이 변경하지 않는 것이 좋습니다.

SCSI Controller

SCSI Controller는 VM의 가상 디스크 컨트롤러입니다.

일반적인 Linux VM에서는 다음 구성을 우선 검토할 수 있습니다.

SCSI Controller: VirtIO SCSI single
Disk Bus: SCSI
Controller 특징 일반적인 사용
VirtIO SCSI single 디스크별 IO Thread 사용 가능 일반 Linux VM, 고IO VM
VirtIO SCSI VirtIO 기반 SCSI Controller 범용 Linux VM
LSI 에뮬레이션 기반 SCSI Controller 일부 호환성 목적
MegaRAID SAS 에뮬레이션 RAID Controller 특수 OS·드라이버 호환성
VirtIO Block 단순 VirtIO Block Device 일부 경량 Linux VM

일반적인 Linux VM에서는 VirtIO 기반 SCSI Controller가 성능과 효율성 측면에서 적합할 수 있습니다.

Recommended Linux VM Storage

SCSI Controller
└── VirtIO SCSI single

Virtual Disk
├── scsi0: OS Disk
├── scsi1: Application Data
├── scsi2: Database WAL
└── scsi3: Backup Staging

Windows VM은 VirtIO SCSI를 사용하려면 설치 과정에서 VirtIO Driver ISO가 필요할 수 있습니다.

Hard Disk

Hard Disk는 VM이 사용할 가상 디스크입니다.

Disk Example

scsi0
├── Storage: local-lvm
├── Size: 100GB
├── Cache: No cache
├── Discard: Enabled
├── IO Thread: Enabled
├── SSD Emulation: Enabled
└── Backup: Enabled

주요 설정 항목은 다음과 같습니다.

항목 설명
Bus/Device SCSI, SATA, VirtIO, IDE 등 디스크 연결 방식
Storage VM 디스크를 저장할 Proxmox Storage
Disk Size 가상 디스크 용량
Cache 디스크 캐시 정책
Discard Guest OS의 TRIM·Discard 전달 여부
IO Thread 디스크 IO 처리 스레드 사용 여부
SSD Emulation Guest OS에 SSD로 표시할지 여부
Backup 백업 작업에 포함할지 여부
Replicate 스토리지 복제 정책 대상 여부
Async IO 디스크 비동기 IO 방식
Read-only 읽기 전용 Disk 여부

Disk Bus

Bus 특징 일반적인 용도
SCSI VirtIO SCSI Controller와 조합 일반 Linux·Windows VM
VirtIO Block 고성능 VirtIO Block Device 일부 Linux VM
SATA OS 기본 드라이버 호환성이 좋음 호환성 우선 VM
IDE 오래된 인터페이스 ISO CD/DVD, 레거시 OS
NVMe NVMe 장치 에뮬레이션 특수 요구·성능 검증 환경

Cache

디스크 Cache 정책은 성능과 데이터 안정성에 영향을 줍니다.

Cache Mode 특징 운영 판단
No cache Host Page Cache를 사용하지 않음 일반적인 안정성 중심 기준
Write through 쓰기 안정성 우선 일부 특수 환경
Write back 쓰기 성능 향상 가능 UPS·Flush·스토리지 안정성 검토 필요
Write back (unsafe) 성능 우선 데이터 손실 위험으로 운영 환경 비권장
Direct sync 동기 쓰기 중심 특수 목적 환경 검토

운영 DB, GitLab, Harbor, Registry, 로그 수집 시스템처럼 쓰기 일관성이 중요한 서비스는 성능 수치만 보고 Cache 정책을 변경하면 안 됩니다.

Disk Cache Decision Factors
├── UPS 존재 여부
├── RAID Controller BBU / CacheVault
├── Storage Flush 보장
├── SAN / NAS Write Cache 정책
├── ZFS Sync 정책
├── DB의 fsync 동작
├── 장애 시 데이터 손실 허용 범위
└── 백업·복구 절차

Discard

Discard는 Guest OS에서 삭제된 블록을 스토리지에 전달하는 기능입니다.

Thin Provisioning, LVM-thin, ZFS, Ceph, SSD·NVMe 환경에서는 사용하지 않는 공간을 회수하는 데 도움이 될 수 있습니다.

Guest OS File Delete
        │
        ▼
fstrim / TRIM
        │
        ▼
Virtual Disk Discard
        │
        ▼
Storage Space Reclaim

Linux Guest에서 TRIM 타이머를 확인할 수 있습니다.

systemctl status fstrim.timer

IO Thread

IO Thread는 VM 디스크 IO 처리를 별도 스레드로 분리하는 기능입니다.

다음 조건에서 검토할 수 있습니다.

  • VirtIO SCSI single 사용
  • VM에 여러 가상 디스크 사용
  • DB, Registry, CI Workspace, 로그 플랫폼처럼 IO가 많은 서비스
  • NVMe, SSD, Ceph, SAN 등 성능이 충분한 스토리지
  • 성능 테스트와 모니터링이 가능한 환경

모든 VM에서 무조건 활성화해야 하는 옵션은 아니며, 서비스와 스토리지 성격에 따라 표준화해야 합니다.

CD/DVD Drive

CD/DVD Drive는 OS 설치 ISO, Windows VirtIO Driver ISO, 복구 ISO 등을 연결하는 가상 장치입니다.

CD/DVD Drive 1
└── Rocky Linux ISO

CD/DVD Drive 2
└── virtio-win.iso

주요 사용 사례는 다음과 같습니다.

  • Linux OS 설치 ISO 연결
  • Windows Server 설치 ISO 연결
  • Windows VirtIO Driver ISO 연결
  • 복구·진단 ISO 연결
  • 오프라인 패키지·도구 ISO 연결
  • VM 부팅 문제 분석용 Live ISO 연결

OS 설치가 완료되면 설치 ISO를 제거하거나 CD/DVD Drive를 Do not use any media로 변경하는 것이 좋습니다.

운영 VM 권장

OS 설치 완료
├── CD/DVD ISO 제거
└── Boot Order에서 OS Disk 우선 확인

EFI Disk

EFI Disk는 OVMF(UEFI) BIOS를 사용하는 VM에서 UEFI 변수와 부팅 관련 정보를 저장하는 가상 디스크입니다.

OVMF VM
├── efidisk0
├── scsi0
└── net0

EFI Disk는 다음 환경에서 필요합니다.

  • OVMF 기반 UEFI VM
  • Windows 11
  • Secure Boot 사용
  • UEFI 기반 Linux VM
  • 일부 PCIe Passthrough 환경

EFI Disk는 일반 OS 데이터 디스크와 다르지만, 백업·스냅샷·마이그레이션 영향을 고려해야 합니다.

TPM State

TPM State는 가상 TPM 장치 상태를 저장하는 항목입니다.

다음 환경에서 필요할 수 있습니다.

  • Windows 11
  • BitLocker
  • TPM 기반 보안 요구사항
  • Secure Boot와 TPM을 함께 사용하는 환경
  • 특정 보안·컴플라이언스 요구사항
Windows 11 VM Example

├── BIOS: OVMF
├── Machine: q35
├── EFI Disk: Enabled
└── TPM State: TPM 2.0

TPM State 디스크는 VM 보안 상태와 연결될 수 있습니다. VM Clone, Backup, Restore, Migration 시 TPM 관련 동작을 사전에 검증해야 합니다.

Network Device

Network Device는 VM이 사용할 가상 NIC입니다.

net0
├── Bridge: vmbr1
├── Model: VirtIO
├── VLAN Tag: 20
├── Firewall: Enabled
├── MAC Address: Auto-generated
└── Rate Limit: Optional
항목 설명
Bridge VM NIC를 연결할 Linux Bridge
Model VirtIO, E1000, vmxnet3 등 가상 NIC 모델
VLAN Tag VLAN-aware Bridge에서 사용할 VLAN ID
MAC Address VM NIC의 MAC 주소
Firewall 해당 NIC에 VM Firewall 규칙 적용 여부
Rate Limit NIC 대역폭 제한
Disconnect NIC Link를 논리적으로 끊는 설정
Multiqueue 고성능 NIC 처리 Queue 설정
MTU Jumbo Frame 등 MTU 지정
Queues 다중 Queue 처리 수

일반 Linux VM은 VirtIO NIC를 우선 검토할 수 있습니다.

Recommended Linux VM NIC

Bridge: vmbr1
Model: VirtIO (paravirtualized)
VLAN Tag: 20
Firewall: Enabled

Windows VM에서 VirtIO NIC를 사용하려면 virtio-win.iso의 네트워크 드라이버가 필요할 수 있습니다.

Bridge

Bridge는 VM과 물리 네트워크를 연결하는 가상 스위치 역할을 합니다.

Physical NIC: eno1
        │
        ▼
Linux Bridge: vmbr0
        │
        ├── Proxmox Management
        ├── VM 101
        ├── VM 102
        └── VM 103

운영 환경에서는 역할별 Bridge를 분리할 수 있습니다.

vmbr0: Proxmox Management Network
vmbr1: VM Service Network
vmbr2: Kubernetes Network
vmbr3: Storage Network
vmbr4: Backup Network

VLAN Tag

VLAN-aware Bridge를 사용하면 VM NIC마다 VLAN Tag를 지정할 수 있습니다.

vmbr1
├── VM 101: VLAN 10 - Management
├── VM 102: VLAN 20 - Application
├── VM 103: VLAN 30 - Kubernetes
└── VM 104: VLAN 40 - Database

VLAN Tag를 설정하려면 다음 조건을 확인해야 합니다.

Required Conditions
├── Proxmox Bridge가 VLAN-aware로 구성됨
├── Physical NIC가 정상 연결됨
├── Switch Port가 VLAN Trunk를 허용함
├── VLAN이 Switch·Router에 구성됨
├── Gateway와 Routing 정책이 존재함
└── Firewall / ACL 정책이 허용됨

Rate Limit

Rate Limit은 VM NIC의 송수신 대역폭을 제한하는 데 사용할 수 있습니다.

Example

Development VM
└── Rate Limit: 100 Mbps

Temporary Test VM
└── Rate Limit: 50 Mbps

운영 서비스 VM에 Rate Limit을 적용할 때는 서비스 트래픽, 백업, 복제, API 요청량, 피크 트래픽을 고려해야 합니다.

USB Device

USB Device는 USB 장치 또는 USB Passthrough를 VM에 연결할 때 사용합니다.

대표적인 사용 사례는 다음과 같습니다.

  • USB License Dongle
  • USB Smart Card Reader
  • USB Security Key
  • USB Storage Device
  • 특수 계측 장비
  • USB Serial Adapter
Proxmox VE Host
└── USB Device
        │
        ▼
Virtual Machine
└── USB Passthrough

USB Passthrough는 Host와 VM 간 장치 소유권을 변경하므로, 운영 환경에서는 다음을 확인해야 합니다.

  • 장치가 Host 운영에 필요하지 않은가
  • VM이 종료되거나 Migration될 때 장치 접근은 어떻게 되는가
  • 다른 노드로 Migration 가능한가
  • USB 장치 재연결 시 Guest OS가 정상 인식하는가
  • 물리 서버 교체 시 장치 연결 경로가 유지되는가
  • 보안 장치·License Dongle의 벤더 지원 정책은 어떠한가

PCI Device

PCI Device는 GPU, NIC, HBA, FPGA, USB Controller 같은 PCI 장치를 VM에 직접 할당하는 기능입니다.

Physical Server
├── GPU
├── High Performance NIC
├── HBA
└── FPGA
        │
        ▼
PCI Passthrough
        │
        ▼
Virtual Machine

주요 사용 사례는 다음과 같습니다.

  • GPU Passthrough
  • 고성능 NIC 직접 할당
  • DPDK 기반 네트워크 워크로드
  • SR-IOV Virtual Function 할당
  • HBA 직접 할당
  • 특수 하드웨어 장치 사용
  • VDI 또는 AI/ML GPU 워크로드

PCI Passthrough는 VM Hardware 메뉴에서 설정할 수 있지만, 실제 사용 전 다음 항목이 필요합니다.

PCI Passthrough Requirements
├── CPU / Motherboard IOMMU 지원
├── Intel VT-d 또는 AMD IOMMU 활성화
├── BIOS / UEFI 설정
├── Kernel IOMMU Parameter
├── IOMMU Group 확인
├── Host Driver Binding 확인
├── Guest Driver 준비
├── VM BIOS / Machine Type 검토
├── Migration 제한 확인
└── 장애 복구 절차 준비

PCI 장치를 직접 할당한 VM은 일반적으로 다른 노드로 라이브 마이그레이션하기 어렵거나 불가능할 수 있습니다. 따라서 HA와 Migration 요구사항이 있는 서비스에는 신중하게 적용해야 합니다.

VM Options 메뉴

Options 메뉴는 VM의 부팅, 종료, 보호, Guest Agent, Hotplug, 태그 등 운영 동작을 제어합니다.

Web UI에서 다음 경로로 이동합니다.

Datacenter
└── Node
    └── VM
        └── Options

대표 옵션은 다음과 같습니다.

VM Options

├── Name
├── Start at boot
├── Start/Shutdown order
├── OS Type
├── Boot Order
├── Use tablet for pointer
├── Hotplug
├── KVM hardware virtualization
├── Freeze CPU at startup
├── Protection
├── QEMU Guest Agent
├── Spice Enhancements
├── VGA
├── ACPI
├── Tags
├── Description
└── SMBIOS Settings

Proxmox VE 버전에 따라 UI에서 보이는 항목, 명칭, 세부 옵션은 달라질 수 있습니다.

Name

Name은 VM의 표시 이름입니다.

k8s-cp-prod-01
gitlab-prod-01
harbor-prod-01
postgresql-prod-01

VM 이름은 CLI, API, 백업, 모니터링, 운영 문서에서 사용되므로 네이밍 규칙을 유지하는 것이 중요합니다.

권장 형식입니다.

<service>-<environment>-<sequence>

Examples
├── k8s-cp-prod-01
├── k8s-worker-prod-01
├── gitlab-dev-01
├── harbor-prod-01
└── monitoring-prod-01

Start at boot

Start at boot은 Proxmox VE 노드가 부팅된 뒤 VM을 자동으로 시작할지 설정합니다.

Start at boot: Enabled

다음과 같은 서비스는 자동 기동을 검토할 수 있습니다.

Auto Start Candidates
├── DNS
├── NTP
├── Bastion
├── Database
├── GitLab
├── Harbor
├── Kubernetes Control Plane
├── Monitoring
└── Core Application VM

모든 VM에 자동 기동을 설정하면 노드 부팅 직후 CPU, 메모리, 디스크 IO가 집중될 수 있습니다.

Node Boot
        │
        ▼
All VMs Start at Once
        │
        ├── CPU Spike
        ├── Disk IO Spike
        ├── Storage Connection Delay
        ├── DB Recovery Competition
        └── Service Start Failure Risk

따라서 중요한 서비스는 시작 순서와 지연 시간을 함께 설정하는 것이 좋습니다.

Start/Shutdown Order

Start/Shutdown Order는 VM의 시작 순서와 종료 순서를 지정합니다.

Startup Example

Order 1
├── dns-prod-01
└── ntp-prod-01

Order 2
└── postgresql-prod-01

Order 3
├── gitlab-prod-01
└── harbor-prod-01

Order 4
└── k8s-cp-prod-01

Order 5
└── k8s-worker-prod-01

CLI 예시입니다.

# DNS VM을 가장 먼저 시작하고, 시작 후 30초 대기
qm set 101 --startup order=1,up=30,down=30

# Database VM을 두 번째로 시작
qm set 601 --startup order=2,up=30,down=60

# GitLab VM을 세 번째로 시작
qm set 301 --startup order=3,up=20,down=60
항목 의미
order VM 시작 순서
up VM 기동 후 다음 VM 시작 전 대기 시간
down VM 종료 전 대기 시간 또는 종료 순서 관련 값
onboot 노드 부팅 후 자동 기동 여부

시작 순서는 “VM 프로세스가 시작되었다”는 것만 보장합니다.

애플리케이션이 실제로 준비되었는지까지 보장하지는 않습니다.

VM Started
≠
Application Ready

예를 들어 Database VM이 부팅되었더라도 PostgreSQL 서비스가 복구를 완료하기 전에는 GitLab이 정상 기동하지 않을 수 있습니다.

서비스 의존성이 강한 환경에서는 systemd dependency, health check, Load Balancer Health Check, Ansible 대기 로직, Kubernetes Readiness Probe 등을 함께 사용해야 합니다.

OS Type

OS Type은 Guest OS 특성에 맞는 기본 동작을 설정하는 항목입니다.

일반적인 값은 다음과 같습니다.

OS Type 예시
Linux Rocky Linux, Ubuntu, Debian, RHEL, AlmaLinux
Microsoft Windows Windows Server, Windows Desktop
Other 특수 Appliance, BSD 등

OS Type은 VM 생성 시 선택하는 것이 일반적이며, 운영 중 변경하면 일부 최적화 설정이나 Guest 동작에 영향을 줄 수 있습니다.

Boot Order

Boot Order는 VM이 부팅할 장치 순서를 정합니다.

Install Phase
├── CD/DVD ISO
└── OS Disk

Production Phase
└── OS Disk Only

OS 설치 중에는 CD/DVD Drive가 우선이어야 할 수 있습니다.

Install Boot Order
1. CD/DVD Drive
2. scsi0
3. Network

설치가 끝난 운영 VM은 OS Disk를 첫 번째로 설정하는 것이 좋습니다.

Production Boot Order
1. scsi0
2. Network
3. CD/DVD Drive

CLI 예시입니다.

# OS 설치 단계
qm set 401 --boot order=ide2\;scsi0

# 설치 완료 후 OS Disk 우선
qm set 401 --boot order=scsi0

설치 ISO를 그대로 연결해 두면, 재부팅 시 설치 화면으로 다시 진입하거나 부팅 순서가 꼬일 수 있습니다.

Use tablet for pointer

Use tablet for pointer는 VNC 또는 콘솔 환경에서 마우스 포인터 동작을 개선하는 옵션입니다.

Use tablet for pointer: Enabled

일반적인 GUI OS 또는 원격 콘솔 사용 환경에서는 활성화할 수 있습니다.

다만 특정 OS, KVM Console, 원격 제어 도구에서 마우스 인식 문제가 있는 경우 비활성화·재활성화로 동작을 확인할 수 있습니다.

Hotplug

Hotplug는 실행 중인 VM에 가상 하드웨어를 추가하거나 변경할 수 있도록 하는 옵션입니다.

Hotplug Options
├── Disk
├── Network
├── USB
├── CPU
├── Memory
└── Cloud-Init

Proxmox VE의 기본 Hotplug 설정은 일반적으로 다음과 같습니다.

network,disk,usb

CPU와 Memory Hotplug는 별도로 활성화해야 합니다.

qm set 401 \
  --hotplug network,disk,usb,cpu,memory,cloudinit
Hotplug 항목 설명
network 실행 중 NIC 추가·제거
disk 실행 중 가상 디스크 추가·제거
usb USB 장치 추가·제거
cpu 실행 중 vCPU 증설
memory 실행 중 메모리 증설
cloudinit Cloud-Init Drive 변경
0 Hotplug 전체 비활성화

Hotplug는 Proxmox VE 설정뿐 아니라 Guest OS와 애플리케이션의 지원 여부가 중요합니다.

Proxmox VE Hotplug Enabled
        │
        ▼
Guest OS Supports Device Hotplug?
        │
        ├── Yes → Online resource recognition possible
        │
        └── No → VM reboot may be required

CPU와 메모리는 증설보다 축소가 복잡합니다.

권장 정책

CPU 증설
└── Hotplug 검토

Memory 증설
└── NUMA + Guest OS 지원 확인 후 Hotplug 검토

CPU 축소
└── VM 정상 종료 후 변경 권장

Memory 축소
└── VM 정상 종료 후 변경 권장

자세한 내용은 다음 문서를 참고합니다.

KVM Hardware Virtualization

KVM hardware virtualization은 CPU의 Intel VT-x 또는 AMD-V 기능을 사용해 VM을 하드웨어 가상화 방식으로 실행하는 옵션입니다.

KVM Hardware Virtualization: Enabled

일반적인 VM에서는 활성화 상태를 유지해야 합니다.

비활성화하면 QEMU 에뮬레이션 기반으로 동작할 수 있어 성능이 크게 저하될 수 있습니다.

다음 조건을 확인해야 합니다.

KVM Requirements
├── Intel VT-x 또는 AMD-V 지원 CPU
├── BIOS / UEFI에서 Virtualization Enabled
├── KVM Kernel Module 정상 로드
└── Nested Virtualization은 별도 설정 필요

Freeze CPU at startup

Freeze CPU at startup은 VM이 시작된 직후 CPU 실행을 일시 중지하는 옵션입니다.

일반적인 운영 VM에서는 자주 사용하지 않습니다.

다음과 같은 특수한 환경에서 검토할 수 있습니다.

  • 디버깅
  • 외부 툴 기반 초기화
  • 특정 하드웨어·부팅 테스트
  • VM 기동 직후 수동 제어가 필요한 환경

일반적인 서버 VM에는 기본값을 유지하는 것이 좋습니다.

Protection

Protection은 VM의 실수로 인한 삭제를 줄이기 위한 보호 기능입니다.

Protection: Enabled

Protection을 활성화하면 Web UI 또는 CLI에서 VM 삭제 같은 작업을 수행할 때 보호 동작이 적용됩니다.

다음 VM에는 활성화를 권장합니다.

Protection Recommended
├── Production Database
├── GitLab
├── Harbor
├── Core DNS
├── Bastion
├── Kubernetes Control Plane
├── Monitoring Server
├── Backup Server
└── 고객사 핵심 업무 VM

CLI에서 설정할 수 있습니다.

# 보호 활성화
qm set 601 --protection 1

# 보호 비활성화
qm set 601 --protection 0

Protection은 백업, 권한 분리, 변경 승인 절차를 대체하지 않습니다.

Protection
└── 실수 방지 보조 기능

Backup
└── 삭제·손상 후 복구 수단

RBAC
└── 누가 삭제할 수 있는지 제어

Change Management
└── 삭제·변경 승인 절차

QEMU Guest Agent

QEMU Guest Agent는 Proxmox VE Host와 Guest OS 사이의 관리 통신 기능입니다.

Proxmox VE
        │
        ▼
QEMU Guest Agent Channel
        │
        ▼
Guest OS
├── IP Address Information
├── OS Information
├── Graceful Shutdown
├── File System Freeze / Thaw
└── Guest Command Execution

VM Options에서 Agent를 활성화합니다.

QEMU Guest Agent: Enabled

CLI 예시입니다.

qm set 401 --agent enabled=1

하지만 Proxmox VE에서 옵션만 활성화해도 기능이 동작하지 않습니다.

Guest OS 내부에도 Agent를 설치하고 실행해야 합니다.

# Debian / Ubuntu
sudo apt update
sudo apt install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

# Rocky / AlmaLinux / RHEL
sudo dnf install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

상태를 확인합니다.

systemctl status qemu-guest-agent

Proxmox VE Host에서 Agent 응답을 확인할 수 있습니다.

qm agent 401 ping

qm guest cmd 401 network-get-interfaces

qm guest cmd 401 get-osinfo

QEMU Guest Agent는 다음 기능에 유용합니다.

  • Web UI에서 Guest IP 확인
  • Guest OS 정상 종료
  • 파일시스템 Freeze/Thaw 기반 백업 일관성 향상
  • Guest OS 정보 조회
  • Cloud-Init·Clone 이후 상태 확인
  • 자동화 스크립트의 Guest 상태 점검

Spice Enhancements

SPICE는 그래픽 콘솔, 원격 화면, 클립보드, 해상도 조정 등을 위한 원격 디스플레이 프로토콜입니다.

Spice Enhancements는 SPICE Guest Tools를 설치한 Guest OS에서 다음 기능을 개선할 수 있습니다.

  • 해상도 자동 조정
  • 클립보드 공유
  • 마우스 통합
  • 원격 디스플레이 경험 개선

GUI 기반 Windows 또는 Linux Desktop VM에서 검토할 수 있습니다.

서버 VM, CLI 전용 Linux VM, Kubernetes Node 같은 워크로드에서는 일반적으로 우선순위가 낮습니다.

VGA

VGA는 VM 콘솔에 제공할 가상 그래픽 장치를 설정합니다.

VGA 유형 일반적인 용도
Default 일반적인 서버 콘솔
VirtIO-GPU Linux GUI, SPICE 등
QXL SPICE 기반 그래픽 환경
VMware Compatible 일부 Guest OS 호환성
Serial Terminal GUI 없이 Serial Console 중심 서버
None 별도 GPU Passthrough 등 특수 구성

일반 Linux 서버는 기본 VGA 또는 Serial Console을 사용할 수 있습니다.

Headless Linux Server
├── VGA: Default 또는 Serial Terminal
└── SSH 중심 관리

Windows Desktop / VDI
├── VGA: 환경별 검증
└── SPICE 또는 RDP 사용

GPU Passthrough VM은 별도 PCI GPU를 직접 할당할 수 있으므로, VGA 설정과 충돌하지 않도록 구성해야 할 수 있습니다.

ACPI

ACPI는 Guest OS에 전원 관리 및 정상 종료 인터페이스를 제공하는 기능입니다.

ACPI: Enabled

일반적으로 활성화 상태를 유지합니다.

qm shutdown 명령은 ACPI Shutdown 또는 QEMU Guest Agent를 이용해 Guest OS에 정상 종료 요청을 보낼 수 있습니다.

qm shutdown 401

Guest OS가 응답하지 않을 때는 강제 종료가 필요할 수 있습니다.

qm stop 401

강제 종료는 파일시스템 손상, DB 복구, 애플리케이션 오류를 유발할 수 있으므로 정상 종료가 불가능한 긴급 상황에만 사용해야 합니다.

Tags

Tags는 VM을 논리적으로 분류하기 위한 메타데이터입니다.

Tags Example

environment:prod
service:kubernetes
tier:control-plane
owner:platform-team
backup:daily
criticality:high

Proxmox VE UI의 Tag는 다음 용도에 활용할 수 있습니다.

  • 개발·검증·운영 환경 구분
  • 서비스 유형 분류
  • 담당 팀 구분
  • 중요도 구분
  • 백업 정책 식별
  • 비용·자원 관리 기준
  • VM 검색과 필터링
  • 운영 문서·CMDB와 매핑

권장 태그 예시는 다음과 같습니다.

Environment
├── prod
├── stage
├── dev
├── test
└── lab

Service
├── k8s
├── gitlab
├── harbor
├── database
├── monitoring
└── backup

Criticality
├── critical
├── high
├── medium
└── low

Owner
├── infra
├── platform
├── devops
├── development
└── security

태그는 자유롭게 만들 수 있지만, 팀 단위 표준을 정하지 않으면 검색과 관리 효율이 떨어집니다.

권장
prod
k8s
platform
critical

권장하지 않음
Production
production-server
운영
important
very-important

Description

Description은 VM의 역할, 서비스 정보, 담당자, 네트워크, 백업 정책 등을 기록하는 데 사용할 수 있습니다.

예시입니다.

# k8s-cp-prod-01

- Environment: Production
- Service: Kubernetes Control Plane
- Owner: Platform Team
- VLAN: 30
- IP: 10.10.30.101
- OS: Rocky Linux 9
- Template: rocky-9-k8s-v2
- Backup: Daily / Retention 14 Days
- Monitoring: Prometheus Node Exporter
- Runbook: internal-wiki/platform/k8s-control-plane

Description에 다음 정보는 저장하지 않는 것이 좋습니다.

Do Not Store in Description
├── Password
├── API Token
├── Private Key
├── Secret
├── Customer Personal Information
├── VPN Credential
└── Database Connection Password

SMBIOS Settings

SMBIOS는 Guest OS에 시스템 제조사·제품명·Serial Number·UUID 같은 시스템 정보를 제공하는 인터페이스입니다.

SMBIOS 설정은 다음과 같은 환경에서 사용될 수 있습니다.

  • Windows 라이선스 또는 자산 관리
  • 특정 상용 소프트웨어 라이선스
  • CMDB 연동
  • 하드웨어 정보 기반 Agent
  • VM UUID 관리
  • 벤더 Appliance 요구사항

운영 환경에서는 임의로 Serial Number 또는 UUID를 변경하면 라이선스·자산관리·Agent 등록에 영향을 줄 수 있으므로 신중하게 다뤄야 합니다.

Proxmox VE Firewall

Proxmox VE Firewall은 가상화 인프라의 여러 계층에서 네트워크 접근 제어를 할 수 있는 기능입니다.

Proxmox VE Firewall Zones

Datacenter
├── Cluster-wide Firewall Policy
├── Security Groups
├── IP Sets
└── Global Rules

Node
├── Proxmox Host Protection
├── SSH / Web UI / API Access Control
└── Cluster / Storage Network Protection

VM / Container
├── Guest Inbound Rules
├── Guest Outbound Rules
├── Security Groups
└── IP Set References

VNet
└── SDN VNet-level Firewall Policy

Proxmox VE 공식 문서는 방화벽을 Datacenter, Node, VM/Container 등의 논리 영역으로 구성하며, VM/CT 영역의 방화벽은 해당 Guest로 들어오고 나가는 트래픽에 대한 규칙을 정의한다고 설명합니다. VM·CT Firewall은 Forwarded Traffic Rule을 직접 정의하는 용도가 아니라 Guest In/Out 트래픽을 제어하는 용도입니다. Proxmox VE Firewall

Firewall 활성화 구조

방화벽을 사용하려면 일반적으로 다음 계층을 확인해야 합니다.

Datacenter Firewall
        │
        ▼
Node Firewall
        │
        ▼
VM / CT Firewall
        │
        ▼
VM NIC Firewall Option

VM 방화벽을 적용하려면 다음을 확인합니다.

1. Datacenter Firewall 설정 확인
2. Node Firewall 설정 확인
3. VM Firewall Enable 설정
4. VM NIC의 Firewall 옵션 활성화
5. 허용·차단 규칙 검토
6. 관리자 접근 경로 확인
7. 적용 후 통신 검증

방화벽 정책 적용 전 주의사항

방화벽 정책을 잘못 적용하면 Proxmox VE Web UI, SSH, 클러스터 통신, 스토리지, 백업, VM 서비스 접근이 차단될 수 있습니다.

방화벽을 활성화하기 전에는 Out-of-Band 관리 경로를 준비해야 합니다.

Emergency Access Path
├── iDRAC
├── iLO
├── IPMI
├── KVM over IP
├── Physical Console
└── 승인된 Bastion Host

다음 항목을 먼저 확인합니다.

Firewall Pre-check

├── 관리자 IP 대역
├── SSH TCP 22
├── Proxmox Web UI TCP 8006
├── Corosync UDP 5405~5412
├── Ceph 통신 포트
├── NFS / iSCSI / FC 스토리지 통신
├── PBS 백업 통신
├── DNS TCP/UDP 53
├── NTP UDP 123
├── 모니터링·로그 수집 포트
└── VM 서비스 포트

Datacenter Firewall

Datacenter Firewall은 클러스터 전반에 적용할 공통 정책을 관리하는 영역입니다.

Datacenter
└── Firewall
    ├── Options
    ├── Rules
    ├── Aliases
    ├── IPSet
    ├── Security Groups
    └── Log

Datacenter에서 주로 관리하는 항목은 다음과 같습니다.

항목 용도
Options Datacenter Firewall 기본 동작 설정
Rules 전체 환경 공통 방화벽 규칙
Aliases IP, Port, Network 이름 별칭
IPSet 여러 IP·CIDR을 그룹화
Security Groups 재사용 가능한 Rule 세트
Log 방화벽 로그 확인

Node Firewall

Node Firewall은 Proxmox VE Host 자체를 보호하기 위한 정책입니다.

Node Firewall Protection

Proxmox VE Host
├── Web UI: TCP 8006
├── SSH: TCP 22
├── API
├── Corosync
├── Storage Network
├── PBS
├── Monitoring Agent
└── System Update / Internal Repository

Node Firewall에서 가장 주의해야 할 항목은 관리자 접근 차단입니다.

관리자 접근 예시

Source: 10.10.10.0/24
Destination: Proxmox VE Node
Allow:
├── TCP 22
└── TCP 8006

운영 환경에서는 인터넷에서 TCP 8006과 TCP 22를 직접 열지 않는 것이 좋습니다.

Recommended Management Access

Administrator
        │
        ▼
VPN / Bastion Host
        │
        ▼
Management VLAN
        │
        ├── TCP 22
        └── TCP 8006
                │
                ▼
Proxmox VE Node

VM Firewall

VM Firewall은 특정 VM의 네트워크 트래픽을 제어합니다.

VM
└── Firewall
    ├── Options
    ├── Rules
    ├── IPSet
    └── Log

VM Firewall은 다음과 같이 사용할 수 있습니다.

VM: postgresql-prod-01

Inbound
├── Allow TCP 5432 from Application VLAN
├── Allow TCP 22 from Bastion VLAN
├── Allow ICMP from Monitoring VLAN
└── Drop all others

Outbound
├── Allow DNS to Internal DNS
├── Allow NTP to Internal NTP
├── Allow Backup to PBS
└── Allow required application traffic

VM Firewall 설정 파일은 일반적으로 다음 경로에 저장됩니다.

/etc/pve/firewall/<VMID>.fw

예를 들어 VMID가 601이면 다음 파일에 저장됩니다.

/etc/pve/firewall/601.fw

VM Firewall Options

VM 또는 CT Firewall Options에는 다음과 같은 설정이 포함될 수 있습니다.

옵션 설명
Enable VM Firewall 활성화 여부
Input Policy VM으로 들어오는 트래픽 기본 정책
Output Policy VM에서 나가는 트래픽 기본 정책
DHCP DHCP 트래픽 허용 여부
NDP IPv6 Neighbor Discovery 허용 여부
MAC Filter VM NIC의 MAC 주소 위·변조 방지
IP Filter 허용된 IP와 NIC 설정 기반 IP 필터링
Log Level In Inbound Rule 로그 레벨
Log Level Out Outbound Rule 로그 레벨
Radv IPv6 Router Advertisement 허용 여부

Proxmox VE Firewall 문서에서는 VM·CT Firewall Options에 enable, dhcp, ndp, ipfilter, macfilter, Input/Output 정책, 로그 레벨 등을 설정할 수 있다고 안내합니다. Proxmox VE Firewall

Input Policy와 Output Policy

Firewall 정책은 기본적으로 허용할 트래픽과 차단할 트래픽을 정의합니다.

Input Policy
└── VM으로 들어오는 트래픽의 기본 정책

Output Policy
└── VM에서 외부로 나가는 트래픽의 기본 정책

예시입니다.

Default Policy Example

Input Policy: DROP
Output Policy: ACCEPT

이 구성은 VM으로 들어오는 트래픽은 기본 차단하고, 명시적으로 허용한 트래픽만 수신하도록 합니다.

VM Firewall

Inbound
├── Allow TCP 22 from Bastion
├── Allow TCP 443 from Service Network
├── Allow ICMP from Monitoring
└── DROP all other traffic

Outbound
└── ACCEPT

Output Policy까지 DROP으로 설정하면 DNS, NTP, 패키지 저장소, 백업, 모니터링, 로그 수집 등 필요한 Outbound 통신을 모두 명시적으로 허용해야 합니다.

Strict Egress Policy

Output Policy: DROP

Required Outbound Rules
├── DNS TCP/UDP 53
├── NTP UDP 123
├── Internal APT/YUM Repository TCP 80/443
├── PBS TCP 8007
├── Monitoring / Logging Port
├── LDAP / AD Port
└── Application-specific Outbound Port

처음부터 Outbound Default DROP을 적용하면 운영 장애가 발생할 수 있으므로, 서비스별 통신 흐름을 먼저 분석하고 단계적으로 적용하는 것이 좋습니다.

방화벽 Rule 예시

SSH 관리 접근 허용

Direction: IN
Action: ACCEPT
Protocol: TCP
Source: 10.10.10.0/24
Destination Port: 22
Comment: Allow SSH from management network

HTTPS 서비스 허용

Direction: IN
Action: ACCEPT
Protocol: TCP
Source: 10.10.20.0/24
Destination Port: 443
Comment: Allow HTTPS from service network

PostgreSQL 접근 허용

Direction: IN
Action: ACCEPT
Protocol: TCP
Source: 10.10.20.0/24
Destination Port: 5432
Comment: Allow PostgreSQL from application network

Prometheus Metrics 허용

Direction: IN
Action: ACCEPT
Protocol: TCP
Source: 10.10.50.0/24
Destination Port: 9100
Comment: Allow Node Exporter from monitoring network

ICMP 허용

Direction: IN
Action: ACCEPT
Protocol: ICMP
Source: 10.10.50.0/24
Comment: Allow ICMP from monitoring network

나머지 Inbound 차단

Direction: IN
Action: DROP
Comment: Drop all other inbound traffic

Aliases

Aliases는 자주 사용하는 IP, CIDR, Port를 이름으로 관리하는 기능입니다.

Aliases

MGMT_NET: 10.10.10.0/24
SERVICE_NET: 10.10.20.0/24
K8S_NET: 10.10.30.0/24
DB_NET: 10.10.40.0/24
MONITORING_NET: 10.10.50.0/24

SSH_PORT: 22
HTTPS_PORT: 443
POSTGRES_PORT: 5432
NODE_EXPORTER_PORT: 9100

Alias를 사용하면 Rule을 읽기 쉽게 만들 수 있습니다.

Without Alias

IN ACCEPT -source 10.10.10.0/24 -p tcp -dport 22

With Alias

IN ACCEPT -source +MGMT_NET -p tcp -dport +SSH_PORT

Alias는 Datacenter 단위에서 표준화하는 것이 좋습니다.

IPSet

IPSet은 여러 IP 주소 또는 CIDR을 하나의 그룹으로 묶는 기능입니다.

IPSet: management_hosts

10.10.10.10
10.10.10.11
10.10.10.12
10.10.10.13

활용 예시입니다.

Rule

Direction: IN
Action: ACCEPT
Source: +management_hosts
Protocol: TCP
Destination Port: 22

IPSet은 다음과 같은 경우에 유용합니다.

  • Bastion Host IP 목록
  • Monitoring Server 목록
  • Backup Server 목록
  • 관리자 PC 대역
  • 허용된 API Client 목록
  • 차단 대상 IP 목록
  • 특정 Kubernetes Node 목록

Security Groups

Security Group은 여러 방화벽 Rule을 재사용 가능한 그룹으로 묶는 기능입니다.

Security Groups

├── ssh-management
├── web-https
├── postgresql-server
├── monitoring-node-exporter
├── dns-server
├── ntp-server
└── k8s-node

예를 들어 ssh-management Security Group은 다음 Rule을 포함할 수 있습니다.

Security Group: ssh-management

IN ACCEPT
├── Source: +MGMT_NET
├── Protocol: TCP
└── Destination Port: 22

monitoring-node-exporter는 다음처럼 구성할 수 있습니다.

Security Group: monitoring-node-exporter

IN ACCEPT
├── Source: +MONITORING_NET
├── Protocol: TCP
└── Destination Port: 9100

VM별로 Security Group을 적용하면 공통 정책을 재사용할 수 있습니다.

VM: gitlab-prod-01
├── Security Group: ssh-management
├── Security Group: web-https
└── Security Group: monitoring-node-exporter

VM NIC Firewall 옵션

VM Firewall Rule을 적용하려면 VM Hardware의 NIC에서 Firewall 옵션이 활성화되어 있어야 합니다.

VM
└── Hardware
    └── Network Device
        └── Firewall: Enabled

CLI에서는 NIC 설정에 firewall=1이 포함되어야 합니다.

qm config 401 | grep '^net'

예시입니다.

net0: virtio=BC:24:11:AA:BB:CC,bridge=vmbr1,firewall=1,tag=20

NIC Firewall 옵션이 비활성화되어 있으면 VM Firewall Rule을 만들어도 해당 NIC 트래픽에 규칙이 적용되지 않을 수 있습니다.

Firewall 로그

방화벽 로그는 차단된 트래픽, Rule 적용 여부, 정책 오류를 분석할 때 중요합니다.

Web UI에서 다음 경로로 확인할 수 있습니다.

VM
└── Firewall
    └── Log

Host CLI에서는 다음과 같이 확인할 수 있습니다.

journalctl -u pve-firewall -n 200 --no-pager

pve-firewall status

pve-firewall compile

nft list ruleset

방화벽 Rule을 적용한 뒤에는 다음을 확인합니다.

1. Rule이 의도한 순서로 배치되었는가
2. VM NIC Firewall 옵션이 활성화됐는가
3. Datacenter·Node·VM Firewall이 모두 활성화됐는가
4. Source·Destination IP가 정확한가
5. VLAN과 Routing이 정상인가
6. Guest OS 내부 방화벽이 별도로 차단하지 않는가
7. Log에서 Drop Rule이 의도대로 동작하는가

Proxmox VE Permissions

Proxmox VE는 사용자(User), 그룹(Group), 역할(Role), ACL(Access Control List), Pool을 이용하는 RBAC(Role-Based Access Control) 방식의 권한 체계를 제공합니다.

Proxmox VE RBAC

User
        │
        ▼
Group
        │
        ▼
Role
        │
        ▼
ACL
        │
        ▼
Path / Resource
├── Datacenter
├── Node
├── Storage
├── Pool
├── VM
├── Container
└── SDN / Firewall

권한 메뉴는 일반적으로 다음 경로에서 확인할 수 있습니다.

Datacenter
└── Permissions
    ├── Users
    ├── Groups
    ├── Roles
    ├── Authentication Realms
    ├── Two Factor
    ├── Permissions
    └── API Tokens

User

User는 Proxmox VE에 로그인하거나 API를 호출하는 주체입니다.

Proxmox VE User ID는 일반적으로 다음 형식입니다.

<username>@<realm>

예시입니다.

root@pam
infra-admin@pam
platform-admin@pam
vm-operator@pam
audit-user@pve
automation@pve
user@example.internal

Realm은 인증 방식을 나타냅니다.

Realm 설명
pam Linux PAM 기반 로컬 사용자 인증
pve Proxmox VE 자체 사용자 데이터베이스
LDAP Realm LDAP 인증 연동
Active Directory Realm AD 인증 연동
OpenID Connect Realm OIDC 기반 인증 연동

운영 환경에서는 여러 관리자가 root@pam 계정을 공유하는 방식을 피하는 것이 좋습니다.

권장

root@pam
└── 긴급 장애 대응 및 초기 설정용

infra-admin@pam
└── 인프라 관리자 개인 계정

platform-admin@pam
└── 플랫폼 관리자 개인 계정

vm-operator@pam
└── VM 운영 담당자 개인 계정

automation@pve
└── API Token 전용 자동화 계정

Group

Group은 여러 사용자를 논리적으로 묶는 단위입니다.

Groups

├── infra-admins
├── platform-admins
├── vm-operators
├── backup-operators
├── security-auditors
└── developers

그룹을 사용하면 사용자별로 같은 권한을 반복 부여하지 않아도 됩니다.

Users
├── kim@pam
├── lee@pam
└── park@pam
        │
        ▼
Group
└── platform-admins
        │
        ▼
Role
└── PVEVMAdmin
        │
        ▼
Path
└── /pool/kubernetes-prod

Role

Role은 권한(Privilege)의 집합입니다.

Proxmox VE는 기본 제공 Role을 제공하며, 필요하면 Custom Role을 만들 수 있습니다.

대표적인 기본 Role은 다음과 같습니다.

Role 일반적인 용도
Administrator Datacenter 전체 관리자
PVEAdmin 광범위한 Proxmox 관리 권한
PVEVMAdmin VM·컨테이너 관리
PVEVMUser VM 콘솔·전원 제어 등 제한된 사용자
PVEDatastoreAdmin 스토리지 관리
PVEDatastoreUser 지정 스토리지 사용
PVESysAdmin 노드·시스템 관리
PVEAuditor 읽기 전용 감사·조회
PVEMappingAdmin 리소스 매핑 관리
PVEPoolAdmin Pool 관리
PVETemplateUser 템플릿 사용
NoAccess 명시적 접근 차단

Role 이름과 세부 Privilege는 Proxmox VE 버전에 따라 다를 수 있으므로, 운영 환경에서는 Web UI의 Roles 메뉴 또는 CLI로 실제 권한 구성을 확인해야 합니다.

# Role 목록 확인
pveum role list

# 특정 Role의 Privilege 확인
pveum role list PVEVMAdmin

Privilege

Privilege는 실제 개별 권한입니다.

예시는 다음과 같습니다.

VM Privileges
├── VM.Allocate
├── VM.Clone
├── VM.Config.CPU
├── VM.Config.Disk
├── VM.Config.Memory
├── VM.Config.Network
├── VM.Config.Options
├── VM.Console
├── VM.Migrate
├── VM.PowerMgmt
├── VM.Snapshot
└── VM.Backup

Datastore Privileges
├── Datastore.Allocate
├── Datastore.AllocateSpace
├── Datastore.Audit
└── Datastore.AllocateTemplate

System Privileges
├── Sys.Audit
├── Sys.Modify
├── Sys.PowerMgmt
└── Sys.Console

Permissions Privileges
├── Permissions.Modify
└── Permissions.Audit

예를 들어 VM Operator에게 VM 전원 제어와 콘솔만 제공하고 싶다면, 전체 Administrator 권한 대신 VM.PowerMgmt, VM.Console, VM.Audit 중심의 Custom Role을 검토할 수 있습니다.

ACL

ACL은 특정 User 또는 Group에 Role을 특정 Path 기준으로 부여하는 규칙입니다.

ACL Structure

User or Group
        │
        ▼
Role
        │
        ▼
Path
        │
        ├── /
        ├── /vms/401
        ├── /pool/kubernetes-prod
        ├── /storage/backup-pbs
        └── /nodes/pve-01

예시입니다.

Group: platform-admins
Role: PVEVMAdmin
Path: /pool/kubernetes-prod
Propagate: Enabled

이 ACL은 platform-admins 그룹에 속한 사용자가 kubernetes-prod Pool 안의 VM·컨테이너를 관리할 수 있도록 구성하는 예시입니다.

Path

Path는 권한이 적용되는 리소스 범위입니다.

Path 의미
/ Datacenter 전체
/vms/<VMID> 특정 VM 또는 컨테이너
/pool/<POOL> 특정 Resource Pool
/storage/<STORAGE> 특정 Storage
/nodes/<NODE> 특정 Proxmox Node
/sdn SDN 관련 리소스
/mapping 리소스 매핑
/access 사용자·권한 관리 영역

예시입니다.

전체 Datacenter 읽기 전용 권한
└── Path: /
    Role: PVEAuditor

특정 VM 제어 권한
└── Path: /vms/401
    Role: PVEVMUser

특정 Pool VM 관리 권한
└── Path: /pool/dev-team
    Role: PVEVMAdmin

특정 백업 Storage 사용 권한
└── Path: /storage/backup-pbs
    Role: PVEDatastoreUser

Propagate

Propagate는 상위 Path에 부여한 권한을 하위 리소스에도 상속할지 결정하는 옵션입니다.

Path: /pool/platform-prod
Role: PVEVMAdmin
Propagate: Enabled

위 예시에서는 해당 Pool 아래의 VM·컨테이너 리소스에도 권한이 적용될 수 있습니다.

일반적으로 Pool 단위 권한 위임에는 Propagate를 활성화하는 경우가 많습니다.

단, 상위 Datacenter 경로(/)에서 과도한 권한을 Propagate하면 의도하지 않은 리소스까지 관리 권한이 확대될 수 있으므로 주의해야 합니다.

Resource Pool 기반 권한 분리

Pool은 VM, 컨테이너를 논리적으로 묶는 그룹입니다.

Resource Pools

├── infrastructure-prod
├── kubernetes-prod
├── devops-prod
├── development-team-a
├── development-team-b
├── security-tools
└── temporary-test

Pool을 사용하면 팀 또는 서비스 단위로 권한을 위임하기 쉬워집니다.

Pool: kubernetes-prod
├── VM 401: k8s-cp-prod-01
├── VM 402: k8s-cp-prod-02
├── VM 403: k8s-cp-prod-03
├── VM 501: k8s-worker-prod-01
├── VM 502: k8s-worker-prod-02
└── VM 503: k8s-worker-prod-03

권한 예시입니다.

platform-admins
├── Path: /pool/kubernetes-prod
└── Role: PVEVMAdmin

developers
├── Path: /pool/development-team-a
└── Role: PVEVMUser

security-auditors
├── Path: /
└── Role: PVEAuditor

이 구조를 사용하면 플랫폼팀은 Kubernetes Pool의 VM을 관리하고, 개발팀은 자신의 개발 Pool VM만 콘솔 접속·시작·종료하도록 제한할 수 있습니다.

권한 설계 예시

역할 분리 모델

Proxmox VE Operations Model

Infrastructure Team
├── Datacenter
├── Node
├── Storage
├── Network
├── Cluster
├── Firewall
└── Backup Platform

Platform Team
├── Kubernetes VM
├── GitLab VM
├── Harbor VM
├── Jenkins VM
└── Monitoring VM

Development Team
├── Development VM Console
├── Development VM Start / Stop
└── Limited VM Snapshot

Security / Audit Team
├── Read-only Inventory
├── Task History
├── Firewall Audit
└── Backup Status Audit

권한 매핑 예시

그룹 Path Role 권한 목적
infra-admins / Administrator 또는 최소 권한 Custom Role Datacenter 전체 운영
platform-admins /pool/platform-prod PVEVMAdmin 플랫폼 VM 관리
dev-team-a /pool/dev-team-a PVEVMUser 또는 Custom Role 개발 VM 콘솔·전원 제어
backup-operators /storage/backup-pbs PVEDatastoreAdmin 또는 제한 Role 백업 저장소 운영
security-auditors / PVEAuditor 전체 읽기 전용 감사
automation /pool/dev-team-a Custom API Role API 기반 VM 자동화

Custom Role 예시

개발팀에 “특정 Pool의 VM 시작·종료·콘솔·조회”만 허용하고 싶다면 최소 권한 Role을 만들 수 있습니다.

pveum role add PVEDevVMOperator \
  -privs "VM.Audit VM.Console VM.PowerMgmt"

그룹을 생성합니다.

pveum group add dev-team-a

사용자를 그룹에 추가합니다.

pveum user add developer1@pam
pveum user modify developer1@pam -group dev-team-a

Pool 경로에 ACL을 부여합니다.

pveum acl modify /pool/dev-team-a \
  -group dev-team-a \
  -role PVEDevVMOperator

실제 운영에서는 사용자가 VM Snapshot, Clone, Network 변경, Disk 확장, ISO 업로드, Backup Restore 중 무엇을 수행해야 하는지에 따라 Privilege를 추가로 검토해야 합니다.

API Token 권한 관리

Terraform, Ansible, CI/CD, 내부 포털 같은 자동화 도구는 API Token을 사용할 수 있습니다.

Automation System
├── Terraform
├── Ansible
├── Jenkins
├── GitLab CI
├── Internal Portal
└── Monitoring Collector
        │
        ▼
Proxmox VE API Token
        │
        ▼
Restricted ACL / Role

API Token은 사람 계정의 비밀번호를 자동화 코드에 저장하는 방식보다 관리하기 좋습니다.

권장

automation@pve
└── API Token
    └── 최소 권한 Role
        └── 특정 Pool / 특정 Storage 한정

권장하지 않음

root@pam Password
└── Terraform / CI 변수 / Script에 저장

API Token 운영 원칙은 다음과 같습니다.

  • 자동화 목적별로 별도 User와 Token을 생성합니다.
  • Token에 Datacenter Administrator 권한을 무조건 부여하지 않습니다.
  • 필요한 Pool, Storage, VM Path로 권한을 제한합니다.
  • Token Secret은 Vault, CI/CD Secret Variable, Ansible Vault 등에서 관리합니다.
  • Token 생성일, 사용 목적, 담당자, 만료일을 기록합니다.
  • 더 이상 사용하지 않는 Token은 즉시 폐기합니다.
  • 정기적으로 Token 권한과 사용 여부를 검토합니다.
  • API 호출 로그와 작업 이력을 모니터링합니다.

2FA와 인증 Realm

Proxmox VE 관리 권한을 가진 사용자에게는 2FA를 적용하는 것이 좋습니다.

2FA Options
├── TOTP
├── WebAuthn / FIDO2
└── Recovery Code

권장 대상은 다음과 같습니다.

2FA Required Candidates
├── infra-admin
├── platform-admin
├── backup-operator
├── security-admin
├── root emergency account
└── API 관련 고권한 계정

단, 긴급 상황을 대비해 다음도 함께 준비해야 합니다.

Emergency Access Plan
├── Break-glass Account
├── Recovery Code 보관
├── 관리자 퇴사·분실 절차
├── MFA Device 분실 대응
├── Out-of-Band Console
└── 승인 기반 긴급 접근 절차

LDAP, Active Directory, OpenID Connect 같은 외부 인증 연동을 사용할 경우에는 Proxmox VE 내부 Role과 외부 사용자·그룹 매핑 정책을 함께 설계해야 합니다.

권한과 방화벽의 차이

권한과 방화벽은 모두 보안과 관련 있지만 제어 대상이 다릅니다.

구분 Permissions Firewall
제어 대상 관리자·사용자의 Proxmox 리소스 접근 네트워크 트래픽
대표 질문 누가 VM을 시작·종료·삭제할 수 있는가 어떤 IP가 VM의 TCP 443에 접근할 수 있는가
적용 단위 Datacenter, Node, Storage, Pool, VM, CT Datacenter, Node, VM, CT, VNet
주요 구성 User, Group, Role, ACL, API Token Rule, Alias, IPSet, Security Group
예시 개발팀은 dev Pool VM만 콘솔 접근 관리망만 VM SSH TCP 22 접근
주요 목적 최소 권한·관리 통제 네트워크 세그먼트·서비스 접근 제어

예를 들어 개발자에게 특정 VM의 콘솔 권한을 주더라도, 방화벽 규칙이 막고 있으면 해당 VM의 SSH 서비스에 네트워크로 접근할 수 없습니다.

User Permission
└── VM Console Access: Allowed

Network Firewall
└── SSH TCP 22: Blocked

Result
└── Proxmox Web Console은 가능할 수 있지만
    네트워크 SSH 접속은 불가

반대로 네트워크 방화벽이 SSH를 허용해도, 사용자가 Proxmox VE에서 VM을 종료·삭제하거나 하드웨어를 변경할 권한이 생기는 것은 아닙니다.

운영 체크리스트

Hardware

  • VM의 CPU, 메모리, 디스크가 워크로드 요구사항에 맞는가
  • CPU Type이 클러스터 마이그레이션 정책에 맞는가
  • BIOS와 Machine Type이 OS·TPM·UEFI 요구사항에 맞는가
  • SCSI Controller와 Disk Bus가 표준에 맞는가
  • Disk Cache 정책이 데이터 안정성 요구사항에 맞는가
  • Discard, IO Thread, SSD Emulation을 스토리지 특성에 맞게 적용했는가
  • VM NIC가 올바른 Bridge와 VLAN에 연결됐는가
  • VM NIC의 Firewall 옵션이 활성화됐는가
  • ISO 설치 완료 후 CD/DVD Boot Order를 정리했는가
  • PCI·USB Passthrough가 Migration·HA 요구사항과 충돌하지 않는가

Options

  • VM Name과 Description이 표준에 맞는가
  • 자동 시작이 필요한 VM만 Start at boot을 사용했는가
  • 서비스 의존성을 고려해 Start/Shutdown Order를 설정했는가
  • Boot Order가 OS Disk 우선인지 확인했는가
  • QEMU Guest Agent가 VM Option과 Guest OS 모두에서 활성화됐는가
  • Hotplug 범위가 Guest OS 지원 여부와 맞는가
  • 중요 VM에 Protection을 활성화했는가
  • Tag가 환경·서비스·담당팀·중요도 기준에 맞는가
  • Description에 비밀번호·Token·Private Key가 없는가

Firewall

  • Datacenter·Node·VM Firewall 계층을 이해하고 있는가
  • VM NIC의 Firewall 옵션이 활성화됐는가
  • SSH, Web UI, Corosync, 스토리지, PBS, DNS, NTP 통신을 확인했는가
  • VM의 Inbound Default Policy가 서비스 요구사항에 맞는가
  • 필요한 서비스 포트만 명시적으로 허용했는가
  • Outbound Default DROP 정책은 통신 흐름 분석 후 적용했는가
  • Alias, IPSet, Security Group으로 공통 정책을 표준화했는가
  • 방화벽 적용 전 Out-of-Band 관리 접근을 확보했는가
  • 방화벽 로그와 Guest OS 방화벽을 함께 확인했는가

Permissions

  • root@pam 계정을 여러 사람이 공유하지 않는가
  • 개인별 관리자 계정을 사용하는가
  • 팀 단위 Group을 구성했는가
  • Datacenter 전체 Administrator 권한을 최소화했는가
  • Pool 단위로 VM 운영 권한을 분리했는가
  • 개발·운영·백업·감사 역할을 분리했는가
  • 읽기 전용 감사 계정에 PVEAuditor 또는 최소 권한 Role을 부여했는가
  • 자동화에 root 비밀번호 대신 API Token을 사용하는가
  • API Token을 목적·Pool·Storage 기준으로 제한했는가
  • 관리자 계정에 2FA를 적용했는가
  • 퇴사·부서 이동·권한 변경 시 ACL과 Token을 회수하는 절차가 있는가
  • 정기적으로 User, Group, Role, ACL, Token 권한을 검토하는가

핵심 정리

  • Proxmox VE VM의 Hardware 메뉴는 CPU, 메모리, 디스크, NIC, BIOS, Machine Type, TPM, PCI·USB 장치 같은 가상 하드웨어를 설정하는 영역입니다.
  • VM Options 메뉴는 자동 시작, 기동·종료 순서, 부팅 순서, QEMU Guest Agent, Hotplug, Protection, Tag, Description 같은 운영 동작 정책을 관리합니다.
  • 일반 Linux VM은 VirtIO SCSI Single, SCSI Disk, VirtIO NIC, QEMU Guest Agent 조합을 우선 검토할 수 있습니다.
  • CPU Type은 성능뿐 아니라 클러스터 내 라이브 마이그레이션 호환성에 영향을 줍니다.
  • OVMF와 q35는 UEFI, TPM, Secure Boot, PCIe Passthrough, 최신 OS 표준 VM에 적합할 수 있지만, 기존 VM 변경 전에는 충분한 검증이 필요합니다.
  • Disk Cache, Discard, IO Thread 설정은 성능뿐 아니라 스토리지 안정성, 전원 보호, 데이터 일관성, Guest OS 설정을 함께 고려해야 합니다.
  • Proxmox VE Firewall은 Datacenter, Node, VM/Container, VNet 계층에서 네트워크 정책을 적용할 수 있습니다.
  • VM Firewall은 Guest로 들어오고 나가는 In/Out 트래픽을 제어하며, VM NIC의 Firewall 옵션이 활성화되어 있어야 적용됩니다.
  • 방화벽은 Alias, IPSet, Security Group을 사용해 공통 규칙을 표준화할 수 있습니다.
  • Permissions는 User, Group, Role, ACL, Path, Pool, API Token으로 구성되는 RBAC 권한 체계입니다.
  • 운영 환경에서는 root 계정 공유를 피하고, 개인별 계정·그룹·최소 권한 Role·Pool 기반 ACL·2FA·API Token을 사용해야 합니다.
  • Permissions는 Proxmox 리소스 관리 권한을 제어하고, Firewall은 네트워크 통신을 제어하므로 둘을 함께 설계해야 합니다.

참고 자료




작성일: 2026년 9월 11일 ,  마지막 업데이트: 2026년 9월 11일