Proxmox VMID, 백업-복원 없이 손으로 바꿔봤습니다

새벽 1시 반, 홈랩 노드의 VM 목록을 스크롤하다가 손이 멈췄습니다. 100번은 두 달 전에 죽여놓고 껍데기만 남은 테스트용 우분투. 매일 도는 건 118번과 121번인데 그 사이에 103, 107이 띄엄띄엄 박혀 있습니다. 기능상 아무 문제 없습니다. VMID는 정수 하나일 뿐이고, Proxmox는 그 숫자로 설정 파일과 디스크를 찾아갈 뿐이거든요.

그런데 저는 그 목록을 보고 있으면 잠이 잘 안 옵니다. 질서에 대한 집착이라고 하면 좀 그럴듯해 보이는데, 실은 그냥 성격입니다.

교과서적인 답은 정해져 있습니다. VM을 백업하고, 지우고, 원하는 VMID로 복원하면 됩니다. 안전하고, Proxmox가 알아서 다 맞춰줍니다. 문제는 속도인데요. 400GB짜리 파일 서버 하나를 그렇게 옮기면 저녁 시간이 통째로 날아갑니다. 숫자 하나 바꾸자고 디스크를 두 번 왕복시키는 셈입니다.

그래서 손으로 바꿔봤습니다. 몇 번 해보니 개념 자체는 허무할 만큼 간단했습니다.

Proxmox가 VM을 붙잡고 있는 두 갈래

Proxmox에서 VM 하나는 두 군데에 이름이 걸려 있습니다.

하나는 구성 파일입니다. /etc/pve/nodes/<노드명>/qemu-server/100.conf 여기에 CPU 코어 수, 메모리, 네트워크 인터페이스, 부팅 순서, 그리고 디스크 참조가 텍스트로 들어 있습니다. 파일 이름 자체가 VMID입니다.

다른 하나는 가상 디스크입니다. 스토리지 백엔드에 따라 LVM 논리 볼륨일 수도, ZFS 볼륨일 수도, 디렉터리 위의 qcow2 파일일 수도 있는데 어느 쪽이든 이름에 VMID가 박혀 있습니다. vm-100-disk-0 이런 식으로요.

VM 100을 101로 바꾼다는 건 그러니까 이름 두 군데를 맞춰주는 작업입니다. 100.conf를 101.conf로 옮기고, 그 안의 vm-100-disk-X 참조를 vm-101-disk-X로 고치고, 실제 디스크나 볼륨 이름도 똑같이 바꿔주면 끝입니다. 한쪽만 바꾸면 VM이 자기 디스크를 못 찾습니다. 그게 전부인데, 손이 미끄러지면 부팅이 안 됩니다.

시작 전에 VM은 반드시 정지 상태여야 합니다. 켜져 있는 상태로 conf를 옮기면 pvedaemon이 붙잡고 있던 참조가 어긋나면서 상당히 지저분해집니다. 저는 한 번 그렇게 해봤고, 그날 밤에 배운 게 있습니다.

구성 파일 이름부터

cd /etc/pve/nodes/$(hostname)/qemu-server/
mv 100.conf 101.conf

/etc/pve는 pmxcfs가 올려주는 가상 파일시스템이라 여기서의 mv는 클러스터 전체에 반영됩니다. 노드 여러 대를 쓰신다면 이 점을 기억해두시는 편이 좋습니다.

파일 이름을 바꿨다고 내용이 따라오지는 않습니다. 열어보면 이전 VMID가 그대로 남아 있습니다.

sata0: local-lvm:vm-100-disk-0,size=32G

이 줄을 이렇게 고칩니다.

sata0: local-lvm:vm-101-disk-0,size=32G

인터페이스 이름은 환경마다 제각각입니다. sata0일 수도 있고 scsi0, virtio0, ide0일 수도 있습니다. 디스크가 여러 개면 전부 고쳐야 하고요. 눈으로 훑다가 하나 빠뜨리는 게 제일 흔한 실수라, 저는 이렇게 확인하고 넘어갑니다.

grep vm-100 101.conf

아무것도 안 나오면 그때 다음 단계로 갑니다.

두 번째 작업, 스토리지 백엔드마다 다릅니다

여기서부터는 무엇을 쓰고 계신지에 따라 명령이 갈립니다.

LVM / LVM-Thin

먼저 볼륨을 확인합니다.

lvs
lvs -a | grep vm-100

이름 변경은 lvrename입니다.

lvrename /dev/pve/vm-100-disk-0 /dev/pve/vm-101-disk-0

디스크가 여러 개면 각각 한 번씩 돌려줍니다.

스냅샷이 있으면 얘기가 길어집니다. LVM-Thin에서 스냅샷을 뜨면 snap_vm-100-disk-0_snapshot-name 같은 볼륨이 따로 생깁니다. lvs -a | grep 100으로 먼저 전부 뽑아보시고요.

lvrename pve/snap_vm-100-disk-0_snapshot-name pve/snap_vm-101-disk-0_snapshot-name

메모리 상태까지 저장한 스냅샷이라면 상태 볼륨도 남아 있습니다.

lvrename pve/vm-100-state-snapshot-name pve/vm-101-state-snapshot-name

스냅샷 이름은 환경마다 다릅니다. 이 명령들을 그대로 붙여넣지 마시라고 굳이 한 문단 더 쓰는 이유가 있는데요, 스냅샷 볼륨 이름이 어긋나면 VM은 멀쩡히 부팅되고 롤백을 시도하는 순간에만 터집니다. 몇 주 뒤에요. 그때 가서 원인 찾기가 정말 성가십니다.

ZFS

ZFS는 오히려 간단합니다.

zfs list | grep vm-100
zfs rename rpool/data/vm-100-disk-0 rpool/data/vm-101-disk-0

풀 이름이나 데이터셋 경로가 다르면 그에 맞춰 조정하시면 됩니다. tank/vmdata/... 같은 구성도 흔하니까요. 디스크 개수만큼 반복합니다.

디렉터리 스토리지 (qcow2 / raw)

디렉터리 스토리지는 VMID가 디렉터리 이름으로도 쓰입니다. 위치는 보통 /var/lib/vz/images/<VMID>/입니다.

cd /var/lib/vz/images/
mv 100 101
cd 101
mv vm-100-disk-0.qcow2 vm-101-disk-0.qcow2

raw 포맷이면 확장자만 .raw로 바꿔서 같은 작업을 합니다. 구성 파일에 적힌 디스크 이름과 글자 하나까지 맞아야 합니다.

정리하면 이렇습니다.

백엔드	확인	이름 변경
LVM / LVM-Thin	lvs -a | grep vm-100	lvrename
ZFS	zfs list | grep vm-100	zfs rename
디렉터리	ls /var/lib/vz/images/100	mv (디렉터리 + 파일)

재스캔하고 UI 깨우기

이름을 다 맞췄으면 Proxmox에게 다시 보라고 시킵니다.

qm rescan --vmid 101

웹 UI를 새로고침하면 대개 여기서 101번이 나타납니다. 안 보이면 데몬을 한 번 흔들어줍니다.

systemctl restart pvedaemon
systemctl restart pveproxy

그래도 목록이 예전 그대로면 십중팔구 브라우저 캐시입니다. Ctrl+F5로 강제 새로고침해보세요. 저는 이 단계에서 conf를 세 번쯤 다시 열어보다가 결국 브라우저 문제였던 적이 있습니다. 30분을 그렇게 썼습니다.

제가 아직 확인 못 한 것들

여기까지가 제 홈랩에서 실제로 돌려본 범위입니다. 단일 노드, LVM-Thin과 ZFS, 스냅샷 두어 개 있는 VM 기준이고요.

건드려보지 않은 영역도 분명히 있습니다. Ceph RBD를 백엔드로 쓰는 클러스터는 제 손에 없어서 rbd rename 이후에 무엇이 더 필요한지 장담을 못 하겠습니다. HA 리소스로 등록된 VM, 특정 VMID를 지목하는 백업 잡, replication job — 이런 것들은 VMID를 참조 키로 들고 있을 텐데 이름만 바꾼 뒤 어떻게 되는지 저는 확인하지 않았습니다. 클러스터라면 새로 쓰려는 번호를 다른 노드가 이미 점유하고 있는지도 먼저 봐야 하고요.

그러니까 프로덕션에서 이 방법을 쓰실 거면, 백업 한 번 떠놓고 시작하시는 편이 낫습니다. 백업-복원이 싫어서 시작한 작업인데 결말이 백업이라니 좀 우습긴 합니다.

그래서 할 만했나

지난주에 이 얘기를 하니까 같은 팀 재현 씨가 그러더군요. "그 숫자 바꾼다고 팬 소리가 조용해지는 것도 아닌데요."

맞는 말입니다. VMID를 100번대로 정렬한다고 VM이 빨라지지도, 전기를 덜 먹지도 않습니다. 아무 이득이 없습니다.

다만 저는 운영 쪽 일을 오래 하면서 이름이 어긋난 채로 굴러가는 시스템이 나중에 어떤 값을 치르는지를 몇 번 봤습니다. 문서에 적힌 번호와 실제 번호가 다르고, 그걸 아는 사람이 한 명뿐이고, 그 사람이 휴가를 가고. 홈랩은 그 사람이 저 하나뿐인 환경이라 더 그렇습니다. 미래의 제가 새벽에 이 노드에 붙었을 때 121번이 뭐였는지 3초 안에 떠올릴 수 있으면, 그걸로 됐다고 생각하는 편입니다.

물론 이게 정당화인지 그냥 강박인지는 저도 아직 잘 모르겠습니다.