결론 요약

1. Proxmox Datacenter Manager 1.1은 서로 떨어진 Proxmox VE 노드·클러스터와 Backup Server를 하나의 관리 화면에 모아줍니다.
2. QEMU·LXC 통합 목록, 전원 및 스냅샷 관리, 크로스 클러스터 마이그레이션, 자동 설치 워크플로가 2026년 홈 서버 운영에서 특히 쓸 만한 기능입니다.
3. PDM은 클러스터 HA나 백업을 대신하지 않으므로 별도 관리 VM 또는 LXC, 최소 권한 API 토큰, VPN, 실제 복구 가능한 백업을 함께 준비해야 합니다.

Proxmox Datacenter Manager 1.1: 흩어진 홈 서버를 한 화면에 모으는 방법

서론: 홈 서버가 두 대가 되는 순간 운영 방식도 달라집니다

홈 서버 한 대를 처음 만들었을 때는 관리가 그리 어렵지 않습니다. Proxmox VE 웹 화면을 열어 가상 머신 상태를 보고, 업데이트가 있으면 적용하고, 문제가 생기면 작업 로그를 확인하면 됩니다. 그런데 미니 PC가 한 대 더 생기고, 가족 사진을 보관할 Proxmox Backup Server를 분리하고, 부모님 댁이나 사무실에도 작은 노드를 두기 시작하면 이야기가 달라집니다. 어느 서버에 어떤 VM이 있었는지 찾느라 브라우저 탭부터 늘어나지 않으셨나요?

서버가 많아서 힘든 것이 아니라 관리 화면과 운영 정보가 흩어져 있어서 힘든 경우가 많습니다. 집의 PVE, 원격지의 PVE, 별도 PBS에 차례로 로그인해 CPU와 메모리 사용량, 실패한 작업, 보류 중인 업데이트를 확인하는 일은 단순하지만 자주 놓칩니다. 장애가 난 뒤에야 "이 노드만 업데이트가 밀려 있었네"라고 발견하면 이미 늦을 수 있죠.

이 문제를 겨냥한 도구가 Proxmox Datacenter Manager, 줄여서 PDM입니다. Proxmox는 2026년 5월 28일 Datacenter Manager 1.1을 공개했습니다. 2026년 7월 11일 현재 공식 문서는 7월 2일 자 1.1.6 버전까지 갱신되어 있습니다. 이번 글에서는 PDM 1.1이 여러 홈 서버를 어떻게 묶는지, 어디에 설치해야 하는지, 그리고 아직 맡기면 안 되는 일은 무엇인지 차근차근 살펴보겠습니다.

Proxmox 멀티 노드 관리: PVE 클러스터와 PDM은 역할이 다릅니다

PDM을 처음 보면 여러 서버를 하나의 거대한 PVE 클러스터로 합치는 제품처럼 느껴질 수 있습니다. 실제 역할은 다릅니다. 공식 소개 문서는 서로 떨어진 위치의 독립 PVE 노드와 클러스터, PBS 인스턴스를 PDM에 리모트(remote)로 등록한다고 설명합니다. PDM은 이 리모트들의 노드, QEMU 가상 머신, LXC 컨테이너, 스토리지, 백업 데이터스토어를 통합해 보여주는 상위 관리 제어면입니다.

비유하자면 PVE 클러스터가 같은 건물 안에서 함께 움직이는 설비라면, PDM은 여러 건물의 상황판을 모아 놓은 관제실에 가깝습니다. 기존 PVE와 PBS는 PDM에 종속되지 않습니다. PDM이 잠시 꺼져도 각 리모트의 VM과 컨테이너는 계속 실행되고, 원래 PVE 또는 PBS 웹 화면에 직접 접속해 관리할 수 있습니다. 공식 문서가 PDM을 느슨하게 결합된 구조라고 표현하는 이유입니다.

홈랩에서 PDM이 빛나는 구성

PDM은 반드시 수십 대 규모의 데이터센터에서만 필요한 도구가 아닙니다. 다음처럼 독립 관리 대상이 두세 개만 되어도 운영 동선이 짧아집니다.

관리망의 PDM
  |-- 집: 단일 Proxmox VE 노드
  |-- 원격지: 독립 Proxmox VE 노드 또는 클러스터
  `-- 백업망: Proxmox Backup Server

이 구성에서는 PVE 클러스터를 억지로 광역망까지 늘리지 않아도 됩니다. PDM 대시보드에서 각 리모트의 상태와 부하, 스토리지 사용량, 최근 작업을 확인하고, 필요한 순간에는 원래 관리 화면으로 바로 이동할 수 있습니다. 서버마다 UI를 찾아다니던 방식에서 "먼저 PDM을 보고, 깊은 설정만 원격 UI에서 처리하는 방식"으로 운영 습관이 바뀌는 셈입니다.

다만 PDM은 백업 서버도, 고가용성 클러스터도 아닙니다. PDM에 원격 노드를 등록했다고 해서 서비스가 자동으로 이중화되거나, 장애 난 VM이 다른 집의 서버에서 자동 부팅되는 것은 아닙니다. 이 경계를 먼저 이해해야 PDM의 장점을 과장 없이 활용할 수 있습니다.

PDM 1.1 핵심 기능: QEMU와 LXC를 한 목록에서 다룹니다

PDM 1.1에서 홈 서버 운영자가 가장 자주 쓰게 될 화면은 Guests입니다. 공식 게스트 관리 문서에 따르면 연결된 모든 PVE 리모트의 QEMU VM과 LXC 컨테이너를 하나의 표 또는 리모트별 트리로 볼 수 있습니다. 이름, ID, 상태, 노드, 태그뿐 아니라 CPU·메모리 사용량과 가동 시간도 함께 나타납니다.

검색도 단순한 이름 찾기에 그치지 않습니다. 예를 들어 tag:prod status:running을 입력하면 운영 태그가 붙은 실행 중 게스트만 추릴 수 있고, remote:parents type:lxc처럼 특정 원격지의 LXC만 볼 수도 있습니다. 노드가 몇 대 되지 않더라도 "그 컨테이너를 어디에 띄웠더라?"라는 질문에 바로 답할 수 있다는 점이 꽤 편합니다.

전원과 스냅샷 관리가 중앙 화면으로 들어왔습니다

게스트 목록에서는 상태에 따라 시작, 정상 종료, 정지, 재개 같은 기본 동작을 실행할 수 있습니다. 일시 정지되거나 suspend 상태인 QEMU VM에는 Resume 동작도 제공됩니다. 더 복잡한 설정이 필요하면 해당 게스트의 PVE UI를 새 탭으로 열 수 있어 중앙 관리와 개별 관리 사이를 자연스럽게 오갈 수 있습니다.

스냅샷도 QEMU와 LXC 모두 중앙에서 관리합니다. 부모·자식 관계를 트리로 확인하고, 새 스냅샷 생성, 설명 수정, 롤백, 삭제를 수행할 수 있습니다. 다만 스냅샷을 백업과 혼동해서는 안 됩니다. 스토리지나 호스트 자체가 고장 나면 같은 장치에 있는 스냅샷도 함께 잃을 수 있습니다. 중요한 게스트는 PBS나 별도 백업 도구로 복구 가능한 사본을 유지해야 합니다.

2026년 PDM 1.1에서 달라진 운영 경험

통합 게스트 관리는 PDM 1.1의 큰 변화지만 전부는 아닙니다. 이번 버전은 Debian 13.5 Trixie, Linux 커널 7.0, ZFS 2.4.2를 기반으로 하며, 여러 노드를 반복 배치하고 관찰하는 기능도 확장했습니다.

자동 설치와 중앙 Ceph 모니터링

자동 설치 공식 문서를 보면 PDM에서 answer 구성을 만들고, 새 Proxmox 제품 설치가 이 값을 가져가도록 ISO를 준비할 수 있습니다. 대상 하드웨어 조건에 따라 서로 다른 구성을 매칭하고, MiniJinja 템플릿과 순번을 이용해 호스트명이나 IP 주소를 생성하며, 설치 진행 상황도 PDM에서 추적합니다. 설치 전용 인증 토큰은 일반 API 토큰과 분리되어 있습니다.

이 기능은 미니 PC 한 대를 가끔 추가하는 사람에게는 다소 무거워 보일 수 있습니다. 하지만 같은 규칙으로 테스트 노드를 여러 번 재설치하거나, 작은 지점 서버를 반복 배치한다면 수기 설정에서 생기는 차이를 크게 줄여줍니다. 매번 설치 화면에서 호스트명과 네트워크를 입력하는 대신, 검토 가능한 구성으로 반복하는 방식입니다.

Ceph를 사용하는 여러 PVE 리모트가 있다면 PDM 1.1에서 상태, 용량, 성능과 monitor, manager, OSD, pool, CephFS, 주요 flag를 한 패널에서 확인할 수 있습니다. 여기에 리모트 위치를 보여주는 지도, CPU·메모리·스토리지 게이지, PDM 호스트 자체의 RRD 지표도 추가됐습니다. 다만 Ceph 화면은 현재 읽기 중심의 통합 모니터링으로 보는 편이 정확합니다. 세부 변경 작업은 각 리모트의 전용 UI가 여전히 필요합니다.

홈 서버 통합 관리 구성: 작게 설치하고 연결은 좁게 엽니다

공식 설치 문서는 평가용 최소 사양으로 x86-64 CPU 1코어 이상, RAM 1GiB, 10GB를 넘는 디스크 공간을 제시합니다. 운영 권장 사양은 2코어 이상, RAM 4GiB, 40GB 이상의 저장 공간입니다. 최소 수치는 어디까지나 평가 기준이므로, 장기간 메트릭과 작업 정보를 모을 환경이라면 여유를 두는 편이 낫습니다.

공식 설치 경로는 전용 ISO 또는 표준 Debian 위의 Proxmox 패키지입니다. Docker 이미지는 공식 설치 방법으로 안내되지 않습니다. 홈랩에서는 작은 전용 VM에 ISO로 설치하거나 Debian LXC에 패키지를 설치하는 구성이 현실적입니다. Proxmox 공식 포럼의 커뮤니티 답변도 PVE 호스트에 PDM 패키지를 직접 섞기보다, 장애 시 다른 호스트로 옮길 수 있는 VM 또는 Debian LXC를 권합니다. 설치 후 웹 UI는 https://호스트:8443에서 접근합니다.

여기서 중요한 질문이 하나 생깁니다. "관리 대상인 PVE 위에 PDM VM을 올려도 괜찮을까요?" 소규모 홈랩이라면 가능합니다. PDM VM이 있는 호스트가 꺼지면 중앙 화면은 잠시 사라지지만, 관리 대상 게스트의 실행 자체는 PDM에 의존하지 않기 때문입니다. 다만 원격 PVE가 하나 더 있다면 PDM VM의 백업을 보관하고, 필요할 때 그쪽에서 복원할 절차까지 적어두는 편이 좋습니다.

API 토큰과 인증서 지문을 가볍게 보면 안 됩니다

PDM은 PVE와 PBS를 리모트로 추가할 때 API를 통해 상태를 읽고 작업을 실행합니다. 계정 비밀번호를 넓게 공유하기보다 용도별 API 토큰을 만들고, 필요한 리소스에 필요한 권한만 부여하는 방식이 적합합니다. PDM 자체 권한만 있다고 모든 작업이 성공하는 것도 아닙니다. 게스트 동작은 대상 리모트의 권한 검사를 다시 거치므로, 조회 담당자와 전원·스냅샷·마이그레이션 담당자의 역할을 나눌 수 있습니다.

인증서 검증도 빼놓으면 안 됩니다. 공개적으로 신뢰되는 인증서라면 시스템 인증서 저장소로 검증하고, 기본 자체 서명 인증서를 쓰면 등록할 때 승인한 지문을 고정합니다. 이후 원격 인증서가 교체되어 지문이 달라지면 연결이 실패합니다. PDM 1.1은 이때 인증서를 다시 탐색하고 새 지문을 확인해 re-pin하는 UI와 CLI 절차를 제공합니다. 오류를 없애려고 검증을 꺼버리기보다, 새 지문이 실제 원격 서버의 것인지 확인하는 과정이 필요합니다.

관리 API를 인터넷에 그대로 노출하는 구성도 피하는 것이 좋습니다. 집과 원격지 사이에 사이트 간 VPN이나 신뢰할 수 있는 메시 VPN을 두고, PDM이 필요한 관리 주소에만 접근하도록 방화벽 범위를 좁혀보세요. 관제실 열쇠를 현관문 밖에 걸어두지 않는 것과 같은 원칙입니다.

크로스 클러스터 마이그레이션은 사전 매핑이 핵심입니다

PDM은 같은 클러스터 안의 노드 이동뿐 아니라 서로 다른 PVE 리모트 사이의 VM과 LXC 마이그레이션도 제공합니다. 서로 독립된 홈 서버 사이에서 작업 위치를 바꾸거나, 한 노드를 정비하기 전에 게스트를 옮길 때 유용합니다. 그렇다고 목적지만 누르면 모든 환경에서 자동으로 무중단 이동이 완성되는 것은 아닙니다.

공식 명령 구문에는 크로스 클러스터 이동 시 원본과 대상의 스토리지 및 네트워크 브리지를 매핑하는 map-storage, map-bridge가 필수 항목으로 나옵니다. 대상 VMID, 대역폭 제한, 온라인 이동 여부도 선택할 수 있습니다. 두 서버에서 같은 vmbr0라는 이름을 써도 실제 VLAN과 라우팅이 다르면 부팅 후 통신이 끊길 수 있고, 디렉터리 스토리지에서 ZFS로 옮기는 것처럼 저장 방식이 달라지면 게스트 유형과 마운트 구성을 더 꼼꼼히 확인해야 합니다.

작은 테스트 VM부터 네 단계로 검증합니다

실서비스를 옮기기 전에는 다음 순서가 안전합니다.

1. 데이터가 거의 없는 테스트 VM으로 대상 스토리지와 브리지 매핑을 확인합니다.
2. 오프라인 마이그레이션 후 부팅, 네트워크, 디스크, 애플리케이션 상태를 검사합니다.
3. PBS 백업과 복원 절차를 실제로 시험하고 원본 삭제 옵션은 끈 상태로 반복합니다.
4. WAN 대역폭과 서비스 허용 중단 시간을 계산한 뒤 온라인 이동 여부를 결정합니다.

특히 원격지 사이에서는 메모리 상태와 로컬 디스크를 전송하는 동안 네트워크 지연과 대역폭이 결과를 좌우합니다. "라이브 마이그레이션 지원"이라는 문구를 "어떤 회선에서도 중단이 전혀 없음"으로 읽으면 곤란합니다. PDM은 이동 작업을 한곳에서 조율해주지만, 물리적인 전송 시간과 목적지 환경까지 없애주지는 않습니다.

현재 기능과 로드맵: PDM 1.1이 아직 대신하지 않는 것

PDM 1.1의 공식 로드맵은 중앙 게스트 관리를 첫 번째 단계라고 분명히 설명합니다. 현재 제공되는 것은 통합 목록, 검색, 기본 전원 동작, 스냅샷, 마이그레이션 같은 자주 쓰는 기능입니다. 게스트의 세밀한 하드웨어 구성이나 복잡한 스토리지·네트워크 설정은 원래 PVE UI에서 처리해야 합니다.

앞으로 검토하거나 개발할 항목과 현재 기능도 구분해야 합니다. 여러 게스트에 대한 일괄 동작, 백업 작업과 마지막 실행 상태의 통합 화면, 스냅샷을 넘어선 기본 게스트 구성, 더 깊은 PBS 데이터스토어·보존 정책 관리, 통합 알림, PDM 자체의 active-standby 구조는 로드맵에 있습니다. 지금 당장 사용할 수 있는 완성 기능처럼 계획하면 안 됩니다.

오프사이트 게스트 복제 역시 로드맵에서 수동 복구를 위한 사본이며 HA가 아니라고 명시합니다. PDM이 두 집의 서버를 보여준다고 해서 사이트 장애를 자동 감지하고 서비스를 넘겨주는 것은 아닙니다. 자동 장애 조치가 목표라면 PVE 클러스터와 네트워크, 스토리지, 쿼럼을 별도로 설계해야 하고, 재난 복구가 목표라면 PBS 백업과 정기 복원 테스트가 먼저입니다.

PDM 자체가 중단됐을 때 하위 리모트는 계속 동작하지만, 중앙 가시성과 제어는 복구할 때까지 사용할 수 없습니다. 즉 서비스 실행의 단일 장애점은 아니지만 관리 화면의 가용성 문제는 남습니다. 홈랩에서는 PDM 설정과 VM을 백업하고, 각 PVE·PBS 주소와 비상 접속 방법을 별도로 기록해두는 정도가 비용과 효과의 균형이 좋습니다.

Proxmox Datacenter Manager 1.1 공식 참고 자료

• Proxmox Datacenter Manager 1.1 발표
• Proxmox Datacenter Manager 1.1.6 공식 문서
• PDM 리모트와 인증서 연결 안내
• PDM 게스트 및 스냅샷 관리 안내
• PDM 1.1 릴리스 기록과 향후 로드맵

결론: 서버 대수보다 관리 동선을 기준으로 도입하세요

PVE 한 대만 운용하고 있고 관리 화면을 여는 일이 전혀 번거롭지 않다면 PDM을 서둘러 추가할 이유는 없습니다. 관리 도구도 결국 업데이트하고 백업해야 할 또 하나의 시스템이니까요. 반대로 독립 PVE가 두 대 이상이거나 PBS를 별도로 운영하고, 여러 위치의 상태와 작업 로그를 한 번에 보고 싶다면 PDM 1.1은 분명한 시간을 아껴줍니다.

처음부터 마이그레이션과 자동 설치를 모두 켜기보다 작은 관리 VM 또는 LXC에 PDM을 설치하고, 조회 전용으로 리모트를 연결해보세요. 통합 목록과 업데이트 화면이 익숙해지면 스냅샷 권한을 추가하고, 마지막에 테스트 VM으로 크로스 클러스터 마이그레이션을 검증하는 순서가 좋습니다. 권한과 기능을 한 단계씩 넓히면 무엇이 편해졌고 어디에서 위험이 늘었는지 쉽게 파악할 수 있습니다.

좋은 홈 서버 관리는 장비를 많이 모으는 일이 아니라, 문제가 생겼을 때 어느 화면을 보고 어떤 순서로 움직일지 정해두는 일에 가깝습니다. PDM은 그 출발점을 한 화면으로 모아주는 도구입니다. 관제실은 생겼지만 백업 창고와 비상 발전기까지 저절로 생긴 것은 아니라는 점만 기억한다면, 흩어진 홈랩을 훨씬 차분하게 운영할 수 있을 것입니다.