10.VM 리소스 조정과 핫플러그 정보

Proxmox VE VM 리소스 조정과 Hotplug

VM을 운영하다 보면 CPU, 메모리, 디스크, NIC 증설이 필요합니다.

• Kubernetes Worker의 Pod 증가로 CPU·메모리가 부족한 경우
• GitLab·Harbor·Prometheus 데이터 증가로 디스크를 확장해야 하는 경우
• DB 데이터·WAL·백업 영역을 별도 디스크로 분리해야 하는 경우
• 서비스·백업·스토리지용 NIC를 추가해야 하는 경우
• 운영 중 일부 자원을 가능한 한 중단 없이 증설해야 하는 경우

Proxmox VE는 Hotplug로 실행 중인 VM에 일부 가상 하드웨어를 추가·변경할 수 있습니다. 하지만 Hotplug는 “옵션만 켜면 무중단 변경이 보장된다”는 뜻이 아닙니다.

성공 여부는 Proxmox 설정, QEMU VM 구성, Guest OS 커널·드라이버, 애플리케이션의 자원 인식 방식에 따라 달라집니다.

Proxmox VE VM Settings
        │
        ▼
Guest OS Hotplug Support
        │
        ▼
Application Resource Recognition
        │
        ▼
Monitoring and Validation

Hotplug 지원 범위

Proxmox VE는 다음 QEMU 장치의 Hotplug를 지원합니다.

항목	기본 활성화	설명
Disk	예	디스크 추가·제거, 기존 디스크 확장
Network	예	VirtIO NIC 등 가상 NIC 추가·제거
USB	예	USB 장치 추가·제거
CPU	아니오	실행 중 vCPU 증설·축소 가능 여부는 Guest OS 확인 필요
Memory	아니오	NUMA와 Guest OS Memory Hotplug 지원 필요
Cloud-Init	아니오	Cloud-Init Drive 변경 허용. 일반 운영 증설에는 드물게 사용

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

network,disk,usb

CPU와 메모리 Hotplug까지 사용하려면 VM Options에서 별도로 활성화합니다.

qm set 401 --hotplug network,disk,usb,cpu,memory
qm config 401 | grep '^hotplug'

Cloud-Init은 최초 부팅 전 초기 설정이 주 목적입니다. 실행 중 운영 VM의 일반적인 자원 증설 방식으로 사용하지 않습니다.

변경 전 점검

Hotplug 전에는 Proxmox 설정뿐 아니라 Guest OS와 애플리케이션 상태를 함께 확인합니다.

영역	확인 사항
백업·복구	최근 백업 성공 여부와 복구 절차
VM 상태	VM, Guest OS, 애플리케이션 오류 여부
Guest OS	커널·드라이버의 Hotplug 지원 여부
스토리지	확장 가능한 여유 공간과 I/O 영향
클러스터	노드, 스토리지, HA, 마이그레이션 상태
변경 영향	유지보수 창, 롤백, 콘솔 접근 경로
모니터링	CPU·메모리·I/O·네트워크 변경 전후 비교 지표

권장 변경 절차

1. 변경 목표와 대상 VM 확인
2. VM·애플리케이션 상태 점검
3. 백업과 복구 경로 확인
4. 필요 시 스냅샷 생성
5. Proxmox VE에서 리소스 변경
6. Guest OS에서 장치·용량 인식 확인
7. 파일시스템·네트워크·애플리케이션 설정 반영
8. 모니터링과 로그 확인
9. 변경 이력 기록

스냅샷은 단기 변경 보호 수단일 뿐 독립 백업을 대체하지 않습니다.

현재 VM 설정은 다음처럼 확인합니다.

qm status 401
qm config 401

qm config 401 | grep -E '^(cores|sockets|cpu|memory|balloon|numa|hotplug)'
qm config 401 | grep -E '^(scsi|sata|virtio|ide)'
qm config 401 | grep '^net'

CPU 증설

CPU Hotplug는 VM에서 미리 정의한 최대 vCPU 범위 안에서 현재 활성 vCPU 수를 늘리는 방식입니다.

Maximum vCPU = Sockets × Cores

예를 들어 최대 4 vCPU로 구성한 VM에서 현재 2 vCPU만 사용하다가 실행 중 4 vCPU로 늘릴 수 있습니다.

Before
Sockets: 1
Cores: 2

After
Sockets: 1
Cores: 4

CPU Hotplug를 사용하려면 다음을 확인합니다.

• VM Options에서 CPU Hotplug가 활성화되어 있는가
• VM Hardware에서 최대 Socket·Core 수가 설정되어 있는가
• Guest OS가 CPU Hotplug를 지원하는가
• 새 CPU가 Guest OS에서 online 상태가 되는가
• 애플리케이션이 증가한 CPU를 실제로 활용하는가

qm set 401 --cores 4
qm set 401 --sockets 1

Linux Guest에서는 다음으로 확인합니다.

nproc
lscpu
cat /sys/devices/system/cpu/online

새 CPU가 offline이면 필요한 경우 online 처리합니다.

for cpu in /sys/devices/system/cpu/cpu[0-9]*; do
  [ -f "$cpu/online" ] || continue
  if [ "$(cat "$cpu/online")" = "0" ]; then
    echo 1 | sudo tee "$cpu/online"
  fi
done

최근 Linux 커널에서는 자동 online이 가능한 경우도 있지만, 배포판·커널·udev 정책별 검증이 필요합니다.

운영 환경에서 vCPU 축소는 Hot-unplug 지원 여부와 애플리케이션 영향이 복잡하므로, 일반적으로 VM을 정상 종료한 뒤 변경하고 재기동하는 방식을 권장합니다.

Linux Guest에서 메모리 확인

메모리 Hotplug를 적용한 뒤에는 Guest OS가 새 메모리 영역을 인식했는지 확인합니다.

# 전체 메모리 확인
free -h

# 메모리 블록 목록 확인
ls -d /sys/devices/system/memory/memory*

# 메모리 블록 상태 확인
grep -H . /sys/devices/system/memory/memory*/state 2>/dev/null | head -n 30

예를 들어 새로 추가된 메모리 블록이 다음처럼 offline 상태로 보일 수 있습니다.

/sys/devices/system/memory/memory30/state:online
/sys/devices/system/memory/memory31/state:online
/sys/devices/system/memory/memory32/state:offline
/sys/devices/system/memory/memory33/state:offline

이 경우 해당 메모리 블록을 online 상태로 전환해야 할 수 있습니다.

# 예시: memory32 블록을 online 상태로 전환
echo online | sudo tee /sys/devices/system/memory/memory32/state

# 상태 재확인
cat /sys/devices/system/memory/memory32/state
free -h

다만 새 메모리 블록의 번호는 VM과 Guest OS 상태에 따라 달라집니다. memory32를 그대로 사용하지 말고, 먼저 offline 상태인 블록을 확인한 뒤 적용해야 합니다.

# offline 상태 메모리 블록 찾기
grep -l offline /sys/devices/system/memory/memory*/state 2>/dev/null

여러 offline 메모리 블록을 일괄 online 처리해야 하는 경우에는 아래와 같이 실행할 수 있습니다.

for memory in /sys/devices/system/memory/memory*; do
  [ -f "${memory}/state" ] || continue

  if [ "$(cat "${memory}/state")" = "offline" ]; then
    echo online | sudo tee "${memory}/state"
  fi
done

메모리 Hotplug 후에는 반드시 실제 용량이 증가했는지 확인합니다.

free -h
grep -H . /sys/devices/system/memory/memory*/state 2>/dev/null | sort

Red Hat 계열 자동 Online 설정

RHEL, Rocky Linux, AlmaLinux, Oracle Linux 등 Red Hat 계열 Guest OS에서는 새로 Hotplug된 메모리 블록을 자동으로 online 상태로 전환하도록 커널 파라미터를 설정할 수 있습니다.

Linux kernel 4.7 이상에서는 memhp_default_state=online 커널 파라미터를 사용해 새 메모리 블록의 기본 상태를 online으로 지정할 수 있습니다.

Kernel Parameter
└── memhp_default_state=online
        │
        ▼
Memory Hotplug
        │
        ▼
New Memory Block
└── Automatically Online

Red Hat 계열에서는 grubby를 사용해 모든 현재 커널 엔트리에 커널 파라미터를 적용하는 방식을 권장합니다.

1. 현재 커널 파라미터 확인

먼저 현재 실행 중인 커널과 등록된 커널 엔트리의 파라미터를 확인합니다.

# 현재 실행 중인 커널 확인
uname -r

# 모든 부팅 엔트리의 커널 파라미터 확인
sudo grubby --info=ALL | grep -E '^(index|kernel|args)'

# 현재 커널 명령행 확인
cat /proc/cmdline

현재 memhp_default_state=online이 이미 적용되어 있는지 확인합니다.

cat /proc/cmdline | grep -w memhp_default_state

2. 모든 커널에 파라미터 추가

다음 명령은 등록된 모든 커널 엔트리에 memhp_default_state=online을 추가합니다.

sudo grubby \
  --update-kernel=ALL \
  --args="memhp_default_state=online"

Red Hat 문서 기준으로 --update-kernel=ALL은 모든 커널 부팅 엔트리에 커널 파라미터를 추가합니다. 새로 설치되는 커널도 해당 커널 옵션을 상속할 수 있습니다. [124][126]

설정 후 등록된 커널 엔트리를 다시 확인합니다.

sudo grubby --info=ALL | grep -E '^(index|kernel|args)'

예상 결과는 아래와 유사합니다.

args="ro crashkernel=1G-4G:192M ... memhp_default_state=online"

3. 재부팅 후 적용 확인

커널 파라미터는 재부팅 후 적용됩니다.

sudo reboot

재부팅 후 다음 명령으로 실제 적용 여부를 확인합니다.

# 현재 실행 중인 커널 명령행 확인
cat /proc/cmdline

# memhp_default_state 적용 여부 확인
cat /proc/cmdline | grep -w memhp_default_state

# 메모리 상태 확인
free -h

# 메모리 블록 상태 확인
grep -H . /sys/devices/system/memory/memory*/state 2>/dev/null | sort

4. 커널 파라미터 제거

문제가 있거나 정책을 되돌려야 한다면 다음 명령으로 모든 커널 엔트리에서 파라미터를 제거할 수 있습니다.

sudo grubby \
  --update-kernel=ALL \
  --remove-args="memhp_default_state=online"

제거 후에는 재부팅해야 실제 실행 커널에 반영됩니다.

sudo reboot

Red Hat 계열 적용 시 주의사항

memhp_default_state=online은 새로 추가되는 메모리 블록을 자동 online 상태로 만들기 위한 설정입니다. 하지만 모든 환경에서 무조건 적용해야 하는 옵션은 아닙니다.

다음 조건을 먼저 확인합니다.

• Guest OS 커널이 Memory Hotplug를 지원하는가
• Proxmox VE VM에서 NUMA와 Memory Hotplug가 활성화되어 있는가
• Guest OS가 새 메모리를 정상 인식하는가
• 애플리케이션이 증설된 메모리를 실제로 활용하는가
• 대형 VM, NUMA 구성, DB, JVM, 캐시 서버에서 메모리 정책 영향이 없는가
• 재부팅 가능한 유지보수 창이 있는가
• 변경 전 백업과 롤백 절차가 준비됐는가

특히 운영 VM에서는 먼저 동일한 OS 버전·커널·VM 설정의 검증 환경에서 Hotplug를 재현하는 것이 좋습니다.

권장 검증 절차

1. 테스트 VM에서 NUMA와 Memory Hotplug 활성화
2. Guest OS에 memhp_default_state=online 적용
3. VM 실행 중 메모리 증설
4. free -h와 memory block 상태 확인
5. 애플리케이션 메모리 인식 확인
6. OOM·swap·kernel log 확인
7. 운영 환경 적용 여부 판단

Memory Hotplug가 정상 동작하더라도, 애플리케이션이 즉시 증가한 메모리를 활용하지 않을 수 있습니다.

예를 들어 다음 워크로드는 별도 튜닝 또는 재시작이 필요할 수 있습니다.

• Java Heap 크기가 고정된 JVM 애플리케이션
• PostgreSQL, MySQL, MariaDB의 공유 버퍼·캐시 설정
• Redis maxmemory 설정
• Elasticsearch·OpenSearch JVM Heap
• Prometheus 메모리 사용량과 TSDB 설정
• Kubernetes kubelet의 Node Allocatable 및 예약 리소스 정책
• 메모리 기준 라이선스 또는 용량 정책을 사용하는 상용 미들웨어

따라서 Memory Hotplug 성공 여부는 단순히 free -h의 숫자가 증가했는지만으로 판단하지 말고, 애플리케이션 상태·성능·메모리 압박·swap·OOM 이벤트까지 함께 확인해야 합니다.

디스크 추가와 확장

디스크 변경은 다음 두 가지로 나뉩니다.

작업	Proxmox VE	Guest OS
새 디스크 추가	scsi1, scsi2 등 신규 디스크 생성	디스크 인식, 파티션, LVM, 파일시스템, 마운트
기존 디스크 확장	기존 디스크 용량 증가	파티션, PV·LV, 파일시스템 확장

새 디스크 추가 예시입니다.

qm set 401 \
  --scsi1 local-lvm:100,cache=none,discard=on,iothread=1,ssd=1

Guest OS에서 디스크를 확인합니다.

lsblk

기존 디스크 확장 예시입니다.

# scsi0에 50GB 추가
qm resize 401 scsi0 +50G

qm resize는 가상 디스크만 키웁니다. Guest OS에서 파티션·LVM·파일시스템까지 확장해야 실제 사용 가능 용량이 증가합니다.

LVM 기반 Root 디스크의 일반적인 흐름은 아래와 같습니다.

# 파티션 확장
sudo growpart /dev/sda 2

# LVM Physical Volume 확장
sudo pvresize /dev/sda2

# Root LV와 파일시스템 확장
sudo lvextend -r -l +100%FREE /dev/mapper/rl-root

# 결과 확인
df -h /

RHEL 계열에서 growpart가 없다면 cloud-utils-growpart, Debian·Ubuntu 계열에서는 cloud-guest-utils 패키지를 확인합니다.

XFS는 온라인 확장이 가능하지만 일반적으로 축소를 지원하지 않습니다. 디스크 축소는 새 디스크 생성 → 데이터 복사 → 마운트 경로 전환 → 기존 디스크 제거 방식이 안전합니다.

디스크 축소 권장 절차

1. 새로 작은 디스크 생성
2. 파일시스템 생성
3. 데이터 복사
4. 애플리케이션 중지 또는 경로 전환
5. 충분히 검증
6. 기존 디스크 제거

NIC 추가와 네트워크 변경

새 NIC는 기본 Hotplug 범위에 포함됩니다.

qm set 401 \
  --net1 virtio,bridge=vmbr2,tag=40,firewall=1

Guest OS에서 새 NIC를 식별합니다.

ip -br link
ip -br addr
ip route

새 인터페이스 이름은 ens19처럼 보일 수 있지만, PCI device order와 Guest OS naming 정책에 따라 달라질 수 있습니다. 이름을 가정하지 말고 MAC address와 ip link 결과로 확인합니다.

다중 NIC 환경에서는 일반적으로 기본 게이트웨이를 하나만 설정합니다.

net0: Service Network
├── IP: 10.10.20.101/24
└── Default Gateway: 10.10.20.1

net1: Storage / Backup Network
├── IP: 10.10.40.101/24
└── Default Gateway: 없음

두 번째 NIC에 기본 게이트웨이를 추가하면 비대칭 라우팅이나 응답 경로 문제가 발생할 수 있습니다. 추가 네트워크는 정적 라우트 또는 정책 기반 라우팅으로 처리합니다.

NIC 제거 전에는 Guest OS의 IP·라우팅·서비스 바인딩·방화벽·스토리지 마운트·백업·DB 복제 의존성을 먼저 제거하거나 이전해야 합니다.

Guest Agent와 검증

QEMU Guest Agent는 Hotplug의 필수 조건은 아니지만, 운영 상태 확인에 유용합니다.

qm agent 401 ping
qm guest cmd 401 network-get-interfaces

Guest Agent는 다음 기능에 도움을 줍니다.

• Guest OS IP와 기본 정보 조회
• 정상 종료 요청
• 백업·스냅샷 시 파일시스템 freeze/thaw
• Guest 내부 상태 확인과 관리 명령 보조

변경 후에는 Proxmox 설정뿐 아니라 Guest OS와 애플리케이션까지 검증합니다.

변경 대상	주요 확인 항목
CPU	nproc, lscpu, CPU online 상태, 애플리케이션 thread·worker 설정
Memory	free -h, memory block online 상태, OOM·swap·cache 사용량
Disk	lsblk, pvs/vgs/lvs, 파일시스템 용량, mount, backup 포함 여부
NIC	NIC 인식, IP, VLAN, route, DNS, 방화벽, 재부팅 후 유지 여부

Kubernetes Worker는 CPU·메모리·디스크 변경 전후에 Node 상태, kubelet·containerd 상태, Pod 스케줄링, /var/lib/containerd, /var/lib/kubelet, /var/log 용량을 함께 확인합니다.

DB VM은 OS, Data, WAL, Backup 영역을 별도 디스크로 분리할 수 있습니다. 다만 여러 가상 디스크가 같은 물리 디스크·ZFS pool·Ceph pool·SAN LUN에 있다면 실제 I/O 경합은 여전히 발생할 수 있습니다.

자주 하는 실수

• CPU·메모리 Hotplug를 활성화하지 않고 실행 중 증설을 시도하는 경우
• Hotplug만 믿고 Guest OS·애플리케이션 호환성을 확인하지 않는 경우
• qm resize 후 Guest OS의 파티션·LVM·파일시스템 확장을 생략하는 경우
• XFS 파일시스템 또는 가상 디스크를 안전 검증 없이 축소하려는 경우
• Ballooning과 Memory Hotplug를 같은 기능으로 이해하는 경우
• NIC를 추가한 뒤 두 번째 기본 게이트웨이를 설정하는 경우
• 새 디스크·NIC를 백업·방화벽·모니터링 정책에 반영하지 않는 경우
• Hotplug 변경 전 백업·스냅샷·복구 절차를 확인하지 않는 경우

핵심 정리

• Proxmox VE Hotplug는 실행 중 VM의 Disk, NIC, USB, CPU, Memory 등을 변경할 수 있는 기능입니다.
• 기본 Hotplug 범위는 일반적으로 Network, Disk, USB이며 CPU·Memory는 별도로 활성화해야 합니다.
• CPU·Memory Hotplug는 Guest OS와 커널 지원이 필요하고, Memory Hotplug는 NUMA도 필요합니다.
• CPU·Memory는 증설을 검토할 수 있지만, 축소는 일반적으로 VM 종료 후 변경하는 방식이 안전합니다.
• Ballooning은 기존 최대 메모리 범위 안에서 Guest 메모리를 조정하는 기능이며, Memory Hotplug와 다릅니다.
• qm resize는 virtual disk만 확장하므로 Guest OS에서 파티션·LVM·파일시스템 확장을 추가로 수행해야 합니다.
• XFS 축소는 일반적으로 지원되지 않으므로, 디스크 축소는 신규 디스크로 마이그레이션하는 방식이 안전합니다.
• NIC Hotplug 후에는 Guest OS의 인터페이스, IP, route, DNS, 방화벽, 재부팅 후 설정 유지 여부를 확인해야 합니다.
• 변경 전에는 백업·복구·서비스 상태를, 변경 후에는 Guest OS·애플리케이션·모니터링·백업 정책을 검증해야 합니다.

참고 자료

• Proxmox VE Hotplug Guide
• Proxmox VE qm Manual
• Proxmox VE Resize Disks
• Proxmox VE VM Configuration Manual

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