16. ProxmoxVE 환경설정

Proxmox VE Datacenter Options 설정 이해하기

Proxmox VE의 Datacenter → Options 메뉴는 개별 VM의 옵션을 설정하는 화면이 아닙니다.

이 메뉴는 Proxmox VE Datacenter 또는 클러스터 전체에 적용되는 공통 기본값과 운영 정책을 설정하는 영역입니다.

Proxmox VE Configuration Scope

Datacenter
├── 클러스터 전체 기본 설정
├── 콘솔·알림·태그 정책
├── Migration·Replication 정책
├── HA 관련 기본 정책
├── WebAuthn·U2F 인증 설정
└── Datacenter 메타데이터

Node
├── 개별 물리 노드 설정
├── 네트워크·스토리지·DNS·NTP
├── 인증서·업데이트
└── 노드별 서비스 상태

VM / Container
├── CPU·메모리·디스크·NIC
├── 부팅·Guest Agent·Hotplug
├── VM/CT 단위 방화벽
└── 개별 리소스 권한

Datacenter Options 설정은 일반적으로 다음 파일에 저장됩니다.

/etc/pve/datacenter.cfg

클러스터 환경에서 /etc/pve는 pmxcfs 기반의 Proxmox Cluster File System으로 관리됩니다. 따라서 Datacenter 설정을 변경하면 클러스터 전체 노드에 영향을 줄 수 있습니다.

pve-01
└── /etc/pve/datacenter.cfg
        │
        ▼
pmxcfs / Corosync
        │
        ├── pve-02
        └── pve-03

운영 클러스터에서 Datacenter Options를 변경하기 전에는 현재 설정을 백업하고, Migration·HA·백업·권한·보안에 미치는 영향을 확인해야 합니다.

현재 설정 요약

화면에 표시된 설정은 다음과 같습니다.

항목	현재 값	간단한 의미
키보드 배열	English (USA) (`en-us`)	콘솔 기본 키보드 레이아웃
HTTP 프록시	없음	외부 다운로드용 HTTP Proxy 미사용
콘솔 뷰어	기본 (`xterm.js`)	브라우저 기본 터미널 콘솔
이메일 발신 주소	`root@$hostname`	알림 메일 기본 발신자
MAC 주소 접두사	`BC:24:11`	VM·CT NIC MAC 자동 생성 Prefix
마이그레이션 설정	기본	VM·CT Migration 공통 설정
복제 설정	기본	Storage Replication 공통 설정
HA 설정	기본	HA Manager 관련 공통 설정
클러스터 리소스 예약	기본	HA·Failover 관련 자원 예약 정책
U2F 설정	없음	U2F 기반 2차 인증 미설정
WebAuthn 설정	없음	FIDO2·WebAuthn 기반 2차 인증 미설정
대역폭 제한	없음	Migration·Backup 등 대용량 작업 제한 없음
최대 작업자/일괄 동작	`4`	HA·일괄 Start/Stop 병렬 작업 수
다음 빈 VMID 범위	기본	자동 VMID 제안 탐색 범위
태그 인식	자동 오버라이드	태그 표시 방식 관련 기본 설정
사용자 태그 액세스	`free`	사용자가 자유롭게 새 태그 생성 가능
등록한 태그	없음	사전 등록된 태그 목록 없음
동의서 텍스트	없음	로그인 화면 보안 경고 문구 없음
위치	없음	Datacenter·클러스터 위치 정보 없음

콘솔 설정

키보드 배열

현재 설정은 다음과 같습니다.

키보드 배열: English (USA) (en-us)

이 설정은 Proxmox VE Web UI에서 VM 콘솔, LXC 콘솔, Node Shell 등을 사용할 때 기본 키보드 레이아웃에 영향을 줍니다.

Administrator Browser Keyboard
        │
        ▼
Proxmox Web Console
├── xterm.js
├── noVNC
└── SPICE
        │
        ▼
VM / Container / Node Shell

Linux 서버 운영, Shell 명령어, YAML, JSON, Bash Script 입력이 많은 환경이라면 en-us 유지가 가장 무난합니다.

Recommended for Linux Infrastructure

Keyboard Layout: en-us

특히 다음과 같은 특수문자 입력에서 US 배열은 문서·CLI 예시와 일치하는 경우가 많습니다.

/  ?  :  ;  |  \  [  ]  {  }  @  #  $  ^  &  *

운영 권장값

환경	권장
Linux Server 중심	`en-us` 유지
Kubernetes·DevOps 환경	`en-us` 유지
CLI 중심 폐쇄망 운영	`en-us` 유지
Windows Desktop VM 중심	실제 콘솔에서 한글·특수문자 입력 테스트
다국어 GUI VM 환경	Guest OS 키보드 설정과 함께 검증

Proxmox 콘솔의 키보드 배열은 Guest OS의 키보드 언어 설정과 별개입니다. Windows 또는 Linux Guest OS 내부 키보드 설정도 함께 확인해야 합니다.

콘솔 뷰어

현재 설정은 다음과 같습니다.

콘솔 뷰어: 기본 (xterm.js)

xterm.js는 브라우저 안에서 텍스트 기반 터미널 콘솔을 제공하는 방식입니다.

xterm.js Use Cases

├── Proxmox VE Node Shell
├── Linux VM Serial Console
├── LXC Container Console
├── 장애 점검
├── CLI 기반 운영
└── 텍스트 기반 복구 작업

일반적인 Linux 서버 운영에는 기본값을 유지하면 됩니다.

콘솔 방식	적합한 용도
`xterm.js`	Node Shell, LXC, Linux Serial Console
noVNC	OS 설치 화면, BIOS/UEFI 화면, 일반 VM 콘솔
SPICE	GUI Desktop VM, 해상도·클립보드 기능 필요 시
Serial Console	Headless Linux VM, 서버 운영

Windows 설치 화면, Linux GUI 화면, BIOS·UEFI 화면처럼 그래픽 콘솔이 필요한 경우에는 noVNC 또는 SPICE를 사용합니다.

Text-based Linux Server
└── xterm.js 또는 Serial Console

Windows Server GUI
└── noVNC 또는 SPICE

Desktop Linux VM
└── noVNC 또는 SPICE

알림과 Proxy 설정

HTTP 프록시

현재 설정은 다음과 같습니다.

HTTP 프록시: 없음

HTTP Proxy는 Proxmox VE 노드가 외부 Repository, LXC 템플릿, 업데이트 서버 등에 접근할 때 중간 Proxy를 통해 통신해야 하는 환경에서 사용합니다.

Proxmox VE Node
        │
        ▼
HTTP Proxy
        │
        ▼
External Services
├── Debian Repository
├── Proxmox VE Repository
├── LXC Template Download
├── ACME CA
└── 외부 패키지 저장소

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

http://proxy.example.internal:3128

인증이 필요한 Proxy는 다음 형태를 사용할 수 있습니다.

http://username:password@proxy.example.internal:3128

하지만 Proxy URL에 비밀번호를 직접 포함하면 설정 파일·백업·화면 캡처에 민감 정보가 노출될 수 있으므로 주의해야 합니다.

환경별 권장

환경	HTTP Proxy 권장
일반 인터넷 연결	Proxy가 없으면 비워 둠
기업 Proxy 필수 환경	승인된 내부 Proxy 설정
제한된 인터넷망	Proxy 주소와 ACL 정책 확인 후 설정
완전 폐쇄망	비워 둠
폐쇄망 + 내부 Mirror	내부 APT/YUM Repository 사용
고객사 망분리 환경	고객사 Proxy·Repository 정책에 맞춤

완전 폐쇄망에서는 외부 HTTP Proxy보다 내부 Repository를 사용하는 구조가 일반적입니다.

Air-gapped Proxmox VE

Proxmox VE Node
├── apt-mirror.example.internal
├── iso-storage.example.internal
├── template-storage.example.internal
├── internal-dns.example.internal
└── internal-ntp.example.internal

이메일 발신 주소

현재 설정은 다음과 같습니다.

이메일 발신 주소: root@$hostname

이 값은 Proxmox VE에서 백업 실패, 작업 오류, 스토리지 경고, 클러스터 이벤트 같은 알림을 보낼 때 기본 발신자 주소로 사용됩니다.

기본값은 다음처럼 표시됩니다.

root@pve-01
root@pve-seoul-prod-01
root@hostname

운영 환경에서는 실제 SMTP Relay 정책과 수신 정책에 맞는 발신 주소를 사용하는 것이 좋습니다.

Recommended Examples

proxmox-alert@example.internal
pve-notify@example.internal
infra-alert@example.internal
noreply-proxmox@example.internal

권장 알림 흐름입니다.

Proxmox VE
        │
        ▼
Notification Target
        │
        ▼
SMTP Relay
        │
        ▼
Mail Server
        │
        ▼
infra-alert@example.internal

발신 주소만 설정한다고 이메일 전송이 자동으로 보장되지는 않습니다.

다음도 함께 확인해야 합니다.

Mail Notification Checklist

├── SMTP Relay 설정
├── 발신 도메인 정책
├── SPF / DKIM / DMARC 정책
├── 내부 메일 릴레이 허용
├── 수신자 설정
├── Backup 알림 설정
├── Notification Target 설정
└── 실제 테스트 메일 전송

운영 환경에서는 다음처럼 설정하는 것을 권장합니다.

Email From: proxmox-alert@example.internal

MAC 주소 정책

MAC 주소 접두사

현재 설정은 다음과 같습니다.

MAC 주소 접두사: BC:24:11

이 값은 Proxmox VE가 새 VM 또는 LXC 컨테이너 NIC를 만들 때 자동 생성하는 MAC 주소의 접두사입니다.

Generated MAC Examples

BC:24:11:12:34:56
BC:24:11:AA:BB:CC
BC:24:11:DE:AD:BE

새 VM의 네트워크 인터페이스는 일반적으로 다음과 같이 표시됩니다.

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

기본 BC:24:11 Prefix는 일반적인 단일 클러스터 또는 홈랩 환경에서는 유지해도 무방합니다.

MAC Prefix 변경이 필요한 경우

아래와 같은 환경에서는 MAC 주소 충돌 가능성을 줄이기 위해 클러스터별 Prefix 분리를 검토할 수 있습니다.

MAC Prefix Separation Candidates

├── 운영·개발·검증 클러스터가 동일 L2 네트워크 일부를 공유
├── 운영과 DR 클러스터가 같은 VLAN에 연결될 수 있음
├── 백업 복구 VM이 운영 네트워크에 임시 연결될 수 있음
├── 여러 Proxmox 클러스터가 같은 사설망에 존재
├── 고객사별 클러스터가 공용 네트워크를 일부 사용
└── 대규모 VM·LXC 환경에서 식별 규칙이 필요

예시 정책입니다.

Production:  BC:24:11:0
Development: BC:24:11:1
DR:          BC:24:11:2
Lab:         BC:24:11:3

MAC Prefix 변경은 이후 새로 자동 생성되는 MAC 주소에 영향을 줍니다. 기존 VM·CT의 MAC 주소는 자동으로 변경되지 않습니다.

변경 전에는 DHCP Reservation, IPAM, NAC, 방화벽, MAC 기반 ACL, 라이선스 정책 영향을 확인해야 합니다.

MAC Address Change Impact

├── DHCP Reservation
├── MAC-based ACL
├── NAC / 802.1X
├── IPAM Registration
├── VM License Binding
├── Monitoring Agent Mapping
├── Firewall Rule
└── Network Inventory

Migration과 Replication

마이그레이션 설정

현재 설정은 다음과 같습니다.

마이그레이션 설정: 기본

Migration은 VM 또는 컨테이너를 한 Proxmox VE 노드에서 다른 노드로 이동하는 기능입니다.

Before Migration

pve-01
└── VM 401 Running

Migration
pve-01 ──────────────── pve-02

After Migration

pve-02
└── VM 401 Running

Migration은 일반적으로 다음 용도로 사용합니다.

Migration Use Cases

├── Proxmox VE 노드 업데이트
├── 커널 업데이트와 재부팅
├── 서버 하드웨어 유지보수
├── 노드 CPU·메모리 부하 분산
├── 디스크·스토리지 작업
├── 장애 예방 조치
└── 랙·전원·네트워크 작업

Migration Network 분리

운영 클러스터에서는 Migration Network를 관리망, Corosync망, 스토리지망과 분리하는 것을 권장합니다.

Recommended Cluster Network Design

Management Network
└── Proxmox Web UI, SSH, API

Corosync Network
└── Cluster Membership, Quorum

Migration Network
└── VM Memory Transfer

Storage Network
└── Ceph, NFS, iSCSI

Backup Network
└── PBS, NAS, Backup Transfer

Migration은 VM의 메모리 상태를 전송하므로, 큰 VM일수록 대역폭을 많이 사용할 수 있습니다.

VM Memory: 64GB
        │
        ▼
Migration Network
        │
        ├── 1Gbps: Migration 시간이 길어질 수 있음
        ├── 10Gbps: 일반적인 운영 환경에서 검토
        └── 25Gbps+: 대규모·고성능 환경에서 검토

Migration Network를 지정하지 않으면 관리망 또는 노드 기본 통신 경로가 사용될 수 있습니다.

이 경우 다음 문제가 생길 수 있습니다.

Migration Traffic Impact

├── 관리 UI 응답 지연
├── API 응답 지연
├── Corosync 패킷 지연 위험
├── 스토리지 네트워크 혼잡
├── VM 서비스 트래픽 영향
└── Backup 작업과 대역폭 경쟁

Migration Network 예시입니다.

Migration CIDR: 10.10.70.0/24

pve-01: 10.10.70.11
pve-02: 10.10.70.12
pve-03: 10.10.70.13

복제 설정

현재 설정은 다음과 같습니다.

복제 설정: 기본

Replication은 로컬 스토리지 기반 VM 디스크를 다른 노드로 비동기 복제하는 기능입니다.

Source Node

pve-01
└── VM 401
    └── Local ZFS Disk
            │
            │ Scheduled Replication
            ▼
Target Node

pve-02
└── VM 401 Replica Disk

Replication은 공유 스토리지나 Ceph와 같은 개념이 아닙니다.

구분	공유 스토리지	Ceph	ZFS Replication
디스크 접근	여러 노드가 같은 디스크 접근	분산 스토리지 접근	원본·복제본을 노드별로 보관
데이터 동기화	스토리지 시스템 기준	분산 복제	주기적 비동기 복제
일반 HA	가능	가능	별도 설계 필요
RPO	스토리지 정책 기준	복제 정책 기준	마지막 복제 시점에 영향
대표 구성	NFS, iSCSI, FC SAN	Ceph RBD	Local ZFS Replication
주요 목적	공유 VM Disk	HCI·분산 스토리지	로컬 스토리지 VM의 복구 보조

Replication Network는 디스크 변경 데이터를 전송할 수 있으므로 Migration Network 또는 별도 고대역폭 네트워크를 사용하는 것을 검토할 수 있습니다.

Network Separation Example

Corosync Network
└── Low latency, stable communication

Migration / Replication Network
└── High bandwidth data transfer

Storage Network
└── Ceph, NFS, iSCSI traffic

Replication은 Backup을 대체하지 않습니다. 마지막 복제 이후의 데이터는 손실될 수 있으며, 논리적 삭제·랜섬웨어·애플리케이션 데이터 손상도 복제될 수 있습니다.

HA와 리소스 예약

HA 설정

현재 설정은 다음과 같습니다.

HA 설정: 기본

HA(High Availability)는 노드 장애 시 HA 대상으로 등록된 VM 또는 컨테이너를 다른 정상 노드에서 재기동하는 기능입니다.

Before Failure

pve-01
└── VM 401
    └── HA Managed

pve-01 Failure
        │
        ▼
Proxmox HA Manager
        │
        ▼
pve-02
└── VM 401 Restart

HA를 사용하려면 다음 조건이 필요합니다.

HA Requirements

├── Proxmox VE Cluster
├── 정상적인 Quorum
├── 안정적인 Corosync Network
├── HA Resource 등록
├── 대상 노드 CPU·메모리 여유
├── VM Disk 접근 가능
├── 공유 스토리지 또는 Ceph 또는 복제 기반 설계
├── 정상적인 네트워크
└── 백업과 복구 절차

HA는 일반적으로 VM을 다른 노드에서 재기동하는 방식입니다.

HA is not Zero Downtime

Node Failure
        │
        ▼
Failure Detection
        │
        ▼
HA Decision
        │
        ▼
VM Restart on another node
        │
        ▼
Guest OS Boot
        │
        ▼
Application Recovery

따라서 실제 서비스 중단 시간은 다음 요소에 따라 달라집니다.

Service Recovery Time

├── 장애 감지 시간
├── Quorum 유지 여부
├── 대상 노드 자원 여유
├── 스토리지 접근성
├── VM 부팅 시간
├── DB 복구 시간
├── 애플리케이션 기동 시간
├── Load Balancer Health Check
└── DNS·네트워크 전환 시간

Datacenter 레벨의 HA 설정은 운영 클러스터 전체에 영향을 줄 수 있으므로, 기본값을 변경하기 전에는 반드시 테스트 환경에서 Failover 시나리오를 검증해야 합니다.

클러스터 리소스 예약

현재 설정은 다음과 같습니다.

클러스터 리소스 예약: 기본

이 설정은 HA Failover 시 VM을 다른 노드에서 재기동할 수 있도록 클러스터 자원 사용량과 예약 정책을 고려하는 영역입니다.

HA 운영에서 가장 중요한 것은 N+1 용량 계획입니다.

3-Node Cluster

Normal State
├── pve-01: 50% CPU / Memory
├── pve-02: 50% CPU / Memory
└── pve-03: 50% CPU / Memory

pve-01 Failure
├── pve-02: 75% CPU / Memory
└── pve-03: 75% CPU / Memory

반대로 평상시에 모든 노드를 높은 사용률로 운영하면, 노드 장애 시 HA VM을 수용할 자원이 부족합니다.

3-Node Cluster

Normal State
├── pve-01: 85% CPU / Memory
├── pve-02: 85% CPU / Memory
└── pve-03: 85% CPU / Memory

pve-01 Failure
├── pve-02: HA VM 수용 불가 가능성
└── pve-03: HA VM 수용 불가 가능성

운영 환경에서는 다음을 정기적으로 점검해야 합니다.

HA Capacity Checklist

├── 핵심 HA VM 목록
├── VM별 vCPU·Memory 요구량
├── 노드별 현재 사용률
├── 노드 1대 장애 시 남은 자원
├── Failover 대상 노드 우선순위
├── 중요도별 VM 재기동 순서
├── 비핵심 VM 종료 정책
├── 스토리지 성능 여유
└── 정기 HA Failover Test

최대 작업자/일괄 동작

현재 설정은 다음과 같습니다.

최대 작업자/일괄 동작: 4

이 값은 HA Manager 작업 또는 다수 VM을 한 번에 시작·정지하는 작업에서 노드당 동시에 실행할 수 있는 Worker 수와 관련됩니다.

max_workers: 4

Proxmox VE Node
├── VM Start / Stop Task 1
├── VM Start / Stop Task 2
├── VM Start / Stop Task 3
└── VM Start / Stop Task 4

값이 너무 높으면 대규모 장애·재부팅 이후 다음 문제가 발생할 수 있습니다.

High Parallelism Risk

├── CPU Spike
├── Storage IO Spike
├── Ceph / SAN / NAS 부하
├── VM Boot Storm
├── Database Recovery 경쟁
├── Network Saturation
├── Backup 작업 지연
└── 서비스 시작 순서 무시

값이 너무 낮으면 장애 후 복구 시간이 길어질 수 있습니다.

현재 기본값인 4는 소규모·중간 규모 환경에서는 무난한 시작값입니다.

환경	권장 접근
단일 노드·홈랩	기본값 유지
소규모 3노드 클러스터	기본값 유지 후 Failover Test
DB·상태 기반 서비스가 많음	낮은 병렬도 + Startup Order 검토
대규모 고성능 환경	스토리지 성능·RTO 기준으로 조정
Ceph·SAN 성능이 충분함	테스트 후 점진적으로 상향 검토

대역폭 제한

현재 설정은 다음과 같습니다.

대역폭 제한: 없음

이 영역은 Migration, Backup, Restore, Clone, Disk Move 같은 대용량 작업이 네트워크·스토리지를 과도하게 사용하지 않도록 제한을 두는 설정과 관련됩니다.

High Bandwidth Operations

├── Live Migration
├── Offline Migration
├── Storage Migration
├── VM Backup
├── VM Restore
├── VM Clone
├── Disk Move
├── ZFS Replication
└── Ceph Recovery / Rebalance

대역폭 제한이 없으면 Migration이나 Backup이 서비스망 또는 스토리지망의 대역폭을 대부분 사용해 서비스 성능에 영향을 줄 수 있습니다.

Backup / Migration Saturation

Backup Job
        │
        ▼
Network Link 100% Usage
        │
        ├── VM Response Delay
        ├── Storage Latency Increase
        ├── Corosync Packet Delay
        ├── PBS / NAS Saturation
        └── Monitoring Delay

환경별 권장

환경	권장
전용 25Gbps Migration 망	제한 없음 또는 높은 제한 검토
전용 10Gbps Backup 망	실제 백업 윈도우 기준 조정
관리망과 Migration 망 공유	대역폭 제한 권장
1Gbps 공용망	백업 시간 분리 + 제한 강력 권장
Ceph와 Migration 망 공유	가능하면 물리 분리, 불가하면 제한 검토
업무 시간 Backup	제한·스케줄 분산 권장
야간 전용 Backup Window	서비스 영향 확인 후 제한 완화 가능

대역폭 제한은 항상 낮게 설정하는 것이 정답은 아닙니다.

Bandwidth Policy Trade-off

낮은 제한
├── 서비스 영향 감소
└── Backup / Restore 시간 증가

높은 제한
├── Backup / Restore 시간 단축
└── 서비스·스토리지 영향 증가 가능

RTO, 백업 윈도우, 네트워크 속도, PBS·NAS 성능, 서비스 피크 시간을 함께 고려해야 합니다.

U2F와 WebAuthn

U2F 설정

현재 설정은 다음과 같습니다.

U2F 설정: 없음

U2F(Universal 2nd Factor)는 보안키 기반 2차 인증 방식입니다.

Login
├── User ID
├── Password
└── U2F Security Key

신규 환경에서는 U2F보다 WebAuthn/FIDO2 기반 MFA를 우선 검토하는 것이 일반적입니다.

U2F는 기존 레거시 보안키 환경에서 호환성 목적으로 사용할 수 있지만, 새로 구축하는 경우 WebAuthn이 더 유연한 선택이 될 수 있습니다.

WebAuthn 설정

현재 설정은 다음과 같습니다.

WebAuthn 설정: 없음

WebAuthn은 브라우저와 FIDO2 보안키를 이용한 현대적인 MFA(Multi-Factor Authentication) 방식입니다.

WebAuthn Authentication

User Login
├── User ID
├── Password
└── WebAuthn Factor
    ├── FIDO2 USB Security Key
    ├── NFC Security Key
    ├── Biometric Security Key
    └── Platform Authenticator

WebAuthn을 사용하려면 일반적으로 다음 요소가 필요합니다.

WebAuthn Requirements

├── HTTPS
├── 일관된 FQDN
├── Browser Origin 일치
├── Relying Party ID
├── 신뢰 가능한 TLS Certificate
└── 사용자별 Security Key 등록

운영 환경에서 Proxmox VE Web UI 접속 주소는 가능한 한 하나의 표준 FQDN 또는 노드별 FQDN으로 통일하는 것이 좋습니다.

Recommended

[https://pve-01.example.internal:8006](https://pve-01.example.internal:8006)
[https://pve-02.example.internal:8006](https://pve-02.example.internal:8006)
[https://pve-03.example.internal:8006](https://pve-03.example.internal:8006)

아래처럼 IP와 FQDN을 혼용하면 WebAuthn Origin 문제가 생길 수 있습니다.

Not Recommended

[https://10.10.10.11:8006](https://10.10.10.11:8006)
[https://pve-01.example.internal:8006](https://pve-01.example.internal:8006)
[https://pve.example.internal](https://pve.example.internal)

환경별 권장

환경	권장
개인 홈랩	TOTP 또는 WebAuthn 선택
개발 환경	관리자 계정 MFA 적용 검토
사내 운영	관리자 계정 WebAuthn 또는 TOTP 권장
고객사 운영	고객사 MFA·접근통제 정책 준수
폐쇄망	사설 CA + 내부 FQDN + WebAuthn 검토
자동화 계정	MFA 대신 최소 권한 API Token 사용

API 자동화 계정에 사람용 MFA를 적용하는 방식보다, 목적별 API Token을 만들고 Pool·Storage·VM 범위로 최소 권한을 부여하는 방식이 일반적입니다.

MFA 적용 전에는 Break-glass 계정, Recovery Code, 보안키 분실 절차, 관리자 퇴사·권한 회수 절차를 함께 준비해야 합니다.

VMID와 태그 정책

다음 빈 VMID 범위

현재 설정은 다음과 같습니다.

다음 빈 VMID 범위: 기본

VMID는 Proxmox VE에서 VM과 LXC 컨테이너를 구분하는 숫자 식별자입니다.

VMID / CTID Usage

├── Web UI Resource ID
├── qm / pct CLI Target
├── API Resource Path
├── Backup Filename
├── VM Config Filename
├── Monitoring Label
├── Terraform Variable
└── CMDB Mapping Key

운영 환경에서는 VM과 LXC, 템플릿, 임시 리소스의 ID 범위를 분리하는 것이 좋습니다.

VMID / CTID Policy Example

100 - 199
└── Core Infrastructure VM

200 - 299
└── Monitoring / Logging VM

300 - 399
└── DevOps Platform VM

400 - 499
└── Kubernetes Control Plane VM

500 - 599
└── Kubernetes Worker VM

600 - 699
└── Database VM

700 - 799
└── Development / Test VM

800 - 899
└── VM Template

1000 - 1099
└── Infrastructure LXC

1100 - 1199
└── Utility LXC

1200 - 1299
└── Development LXC

1300 - 1399
└── Temporary Test LXC

이 설정은 자동으로 제안되는 다음 ID 탐색 범위와 연관될 수 있습니다.

가장 중요한 것은 팀 전체가 동일한 VMID·CTID 정책을 문서화하고 지키는 것입니다.

태그 인식

현재 설정은 다음과 같습니다.

태그 인식: 자동 오버라이드

태그는 VM과 컨테이너를 환경, 서비스, 담당팀, 중요도 같은 기준으로 분류하는 메타데이터입니다.

Tag Categories

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

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

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

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

태그 표시 방식은 환경에 따라 다음처럼 다르게 보일 수 있습니다.

full
└── 태그 텍스트 전체 표시

circle
└── 색상 원형 중심 표시

dense
└── 작은 사각형 중심으로 표시
    많은 태그가 있는 환경에 적합

none
└── 태그 UI 표시 최소화

사용자 태그 액세스

현재 설정은 다음과 같습니다.

사용자 태그 액세스: mode free

free 모드는 사용자가 VM 또는 CT에 새로운 태그를 자유롭게 만들고 적용할 수 있다는 의미입니다.

개인 홈랩이나 소규모 실습 환경에서는 편리할 수 있습니다.

free Mode Example

prod
production
Production
prd
운영
service
important
very-important

하지만 여러 팀이 함께 운영하는 환경에서는 태그 난립이 발생할 수 있습니다.

Tag Standardization Problem

prod
production
Production
prd
운영
production-system

운영 환경에서는 사전 등록된 태그를 사용하고, 가능한 한 사용자 임의 태그 생성을 제한하는 방식을 검토하는 것이 좋습니다.

환경	권장 태그 정책
개인 홈랩	`free` 유지 가능
소규모 개발 환경	`free` 또는 최소 표준
사내 운영	등록 태그 기반 통제 권장
고객사 운영	CMDB·보안·자산 정책 기준 태그 통제
자동화 환경	태그 명명 규칙과 허용 목록 관리

등록한 태그

현재 설정은 다음과 같습니다.

등록된 태그 없음

운영 환경에서는 자주 쓰는 태그를 사전에 등록하고 명명 규칙을 정하는 것이 좋습니다.

Recommended Registered Tags

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

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

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

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

VM 적용 예시입니다.

VM: k8s-cp-prod-01

Tags
├── prod
├── k8s
├── control-plane
├── platform
└── critical

태그를 다음 시스템과 연결하면 운영 가치가 높아집니다.

Proxmox Tags
        │
        ├── VM Inventory
        ├── Monitoring Labels
        ├── Backup Policy
        ├── Cost Allocation
        ├── CMDB Classification
        ├── Terraform Variables
        └── Ansible Target Group

동의서와 위치

동의서 텍스트

현재 설정은 다음과 같습니다.

동의서 텍스트: 없음

동의서 텍스트는 Proxmox VE 로그인 화면에 표시할 수 있는 보안 경고·사용 조건·무단 접근 금지 문구입니다.

개인 홈랩에서는 선택 사항이지만, 사내 운영 환경·고객사 환경·보안 감사 대상 환경에서는 설정을 권장합니다.

예시입니다.

본 시스템은 승인된 사용자만 접근할 수 있는 정보시스템입니다.

무단 접근, 계정 공유, 권한 없는 구성 변경, 데이터 반출은 금지됩니다.
모든 접속 및 작업 내역은 내부 보안 정책에 따라 기록·감사될 수 있습니다.

접속을 계속하면 위 정책에 동의한 것으로 간주합니다.

영문 병기가 필요한 환경에서는 다음처럼 사용할 수 있습니다.

Authorized access only.

This system is restricted to authorized users.
All access and activities may be monitored, recorded, and audited.

Unauthorized access, configuration changes, or data extraction are prohibited.

동의서 문구는 법무·보안·감사 부서가 승인한 표준 문구를 사용하는 것이 좋습니다.

위치

현재 설정은 다음과 같습니다.

위치: 없음

위치는 Datacenter 또는 클러스터의 물리적·논리적 위치 정보를 기록하는 메타데이터입니다.

예시는 다음과 같습니다.

Seoul DC 1 / Rack A12
Pangyo IDC / Zone B
Customer A / Production DC
Seoul Office Lab
Busan DR Site

위치 값은 VM 동작에 직접 영향을 주지는 않습니다.

하지만 다수 사이트·다수 클러스터·DR 환경에서는 운영 가시성과 장애 대응에 도움이 됩니다.

Multi-site Example

Datacenter Location
├── seoul-prod-cluster
│   └── Seoul DC 1 / Rack A12
├── busan-dr-cluster
│   └── Busan DR Site / Rack B05
└── lab-cluster
    └── Seoul Office Lab

권장 위치 정보입니다.

<Site> / <Datacenter> / <Rack or Zone>

Examples
├── Seoul / DC-1 / Rack-A12
├── Pangyo / IDC-2 / Zone-B
├── Busan / DR-Site / Rack-C05
└── Customer-A / Production / Zone-1

설정 확인 CLI

Datacenter 설정은 다음 파일에서 확인할 수 있습니다.

cat /etc/pve/datacenter.cfg

주요 항목만 보고 싶다면 다음 명령을 사용할 수 있습니다.

grep -E \
'^(keyboard|http_proxy|email_from|mac_prefix|migration|replication|ha|max_workers|next_id|tag-style|user-tag-access|description|location|webauthn|u2f)' \
/etc/pve/datacenter.cfg

클러스터 상태도 함께 확인합니다.

pvecm status
pvecm nodes

설정 변경 전 백업 예시입니다.

BACKUP_DIR="/root/pve-config-backup/$(date +%F)"

mkdir -p "${BACKUP_DIR}"

cp -a /etc/pve/datacenter.cfg \
  "${BACKUP_DIR}/datacenter.cfg"

변경 후에는 다음 항목을 점검합니다.

Datacenter Option Change Validation

├── Web UI 접속
├── Node Shell 접속
├── VM Console 접속
├── Backup 알림
├── SMTP Relay
├── Migration 테스트
├── Replication 상태
├── HA 상태
├── WebAuthn 로그인
├── Tag 등록·적용
└── Cluster 상태

환경별 권장값

개인 홈랩·개발 환경

항목	권장
키보드 배열	`en-us`
HTTP 프록시	Proxy가 없으면 비움
콘솔 뷰어	`xterm.js` 유지
이메일 발신 주소	기본값 또는 개인 알림 주소
MAC Prefix	기본값 유지 가능
Migration	단일 노드면 기본값
Replication	미사용이면 기본값
HA	단일 노드면 기본값
WebAuthn	선택
대역폭 제한	기본값 또는 필요 시 설정
최대 작업자	`4` 유지
사용자 태그	`free` 유지 가능
등록 태그	필요 시 추가
동의서	선택
위치	선택

사내 운영·폐쇄망 환경

항목	권장
키보드 배열	`en-us`
HTTP 프록시	내부 Proxy 또는 내부 Repository 정책
콘솔 뷰어	`xterm.js` 유지
이메일 발신 주소	`proxmox-alert@도메인` 권장
MAC Prefix	운영·개발·DR 클러스터별 분리 검토
Migration	전용 Migration CIDR 권장
Replication	전용 고대역폭 네트워크 검토
HA	3노드·Quorum·N+1 용량과 함께 설계
WebAuthn	관리자 MFA 권장
대역폭 제한	공용망·업무시간 작업 제한 권장
최대 작업자	Failover·부팅 테스트 후 조정
사용자 태그	등록 태그 기반 통제 권장
등록 태그	환경·서비스·소유자·중요도 기준 등록
동의서	보안·감사 문구 등록 권장
위치	센터·고객사·DR 사이트 정보 등록 권장

핵심 정리

Datacenter → Options는 개별 VM 옵션이 아니라 Proxmox VE Datacenter 또는 클러스터 전체의 공통 기본 설정입니다.
설정은 일반적으로 /etc/pve/datacenter.cfg에 저장되며, 클러스터에서는 모든 노드에 공유될 수 있습니다.
키보드 배열 en-us와 콘솔 뷰어 xterm.js는 Linux·CLI 중심 운영 환경에서 일반적으로 적합합니다.
HTTP Proxy는 외부 Repository·템플릿 접근이 필요한 환경에서만 설정하며, 완전 폐쇄망은 내부 APT Repository를 사용하는 방식이 적합합니다.
이메일 발신 주소 root@$hostname은 운영 환경에서 실제 SMTP 정책에 맞는 proxmox-alert@도메인 형태로 변경하는 것을 권장합니다.
MAC Prefix BC:24:11은 단일 클러스터에서는 유지할 수 있지만, L2 네트워크가 겹치는 여러 클러스터·DR 환경에서는 Prefix 분리를 검토해야 합니다.
Migration과 Replication은 Corosync·관리망·스토리지망과 분리된 고대역폭 네트워크를 사용하는 것이 좋습니다.
HA는 무중단이 아니라 장애 노드의 VM을 다른 노드에서 재기동하는 기능이며, Quorum·공유 스토리지·Ceph·N+1 용량 계획이 필요합니다.
max workers = 4는 일반적인 시작값이지만, 서비스 기동 순서·스토리지 성능·RTO를 기준으로 테스트 후 조정해야 합니다.
WebAuthn은 FIDO2 보안키 기반 MFA이며, 운영 관리자 계정에는 TOTP 또는 WebAuthn 같은 MFA 적용을 권장합니다.
user tag access: free는 홈랩에는 편리하지만, 다중 운영자 환경에서는 등록 태그 기반의 통제가 더 적합합니다.
동의서 텍스트와 위치는 기능상 필수값은 아니지만, 사내 운영·고객사·감사 환경에서 보안 고지와 운영 가시성에 도움이 됩니다.

참고 자료

cluster datacenter high-availability migration options proxmox proxmox-ve security tags webauthn

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