메뉴 닫기
  • Home
  • Proxmox VE 9.1 정식 업데이트 (스포 : 컨테이너 OCI 지원!)
    •

Proxmox VE 9.1 정식 업데이트 (스포 : 컨테이너 OCI 지원!)

김 병학 0 댓글

Proxmox

지난 2025년 10월 20일 Proxmox VE의 9.1 업데이트가 진행되었습니다.

이미 Proxmox VE 9.0 beta 업데이트는 지난 8월에 업데이트가 되었습니다만, 한두가지를 제외하고는 아직은 활용하기 이르다고 생각해 업데이트를 하지 않았는데요.

이번 9.1 업데이트에서는 개인적으로 조금 기다렸던 내용들이 업데이트되어서, 9.0과 9.1 에 대한 업데이트 리뷰를 진행하고자 합니다.

..시작하기 전에

내용을 시작하기전에 알아두어야 할 점은, ProxmoxVE 9 은 Debian13 에서 지원됩니다. 아직은 Debian12 의 EOL 이 남아있기에 업데이트가 부담스러운 분들은 내년 6월에 Debian12 의 EOL이 만료되니 그때 고민해보셔도 좋을듯합니다. 아래 내용 참고하세요

버전 코드이름 EOL LTS
12 Bookworm  2026-06-10 2028-06-30
13 Trixie 2028-08-09 2030-06-30

출처 : https://www.debian.org/releases/

 

업데이트 방법

업데이트 방법은 프록스목스 도큐먼트에서도 자세히 설명되어있어서, 간략하게만 작성하도록 하겠습니다.

출처 : https://pve.proxmox.com/wiki/Upgrade_from_8_to_9

프록스목스에 내당되어있는 체크리스트 프로그램으로 시스템 점검 진행
업데이트 전/도중/후에 발생할 수 있는 에러에대한 힌트와 경고를 제공합니다.

pve8to9 --full

최소 Proxmox 8.4.1 부터 9.x 버전으로의 업데이트를 지원합니다. 혹시 이하의 버전이면 아래 명령어로 최신 버전으로 업데이트합니다. 데비안12 에서 실행했다면, 8.4.14로 업데이될것입니다.

apt update
apt dist-upgrade
pveversion # 현재 버전확인

데비안13 레포지토리로 변경을 진행합니다.

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list

Proxmox 와 Ceph 의 레포지토리를 변경합니다.

# PVE 라이센스를 구독중일 경우
cat > /etc/apt/sources.list.d/pve-enterprise.sources << EOF
Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

cat > /etc/apt/sources.list.d/ceph.sources << EOF
Types: deb
URIs: https://enterprise.proxmox.com/debian/ceph-squid
Suites: trixie
Components: enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

# PVE 라이센스를 구독하지 않고 사용하는경우는 
cat > /etc/apt/sources.list.d/proxmox.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF 

cat > /etc/apt/sources.list.d/ceph.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/ceph-squid
Suites: trixie
Components: no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

 

모든 레포지토리 설정이 완료되었으면, 패키지 dist upgrade 진행시 pve 커널도 함께 업데이트됩니다.

주의해야할점은 SSH 가 도중에 끊길수도 있으니, 반드시 서버에 콘솔을 붙여서 작업하거나, tmux/screen 같은 프로그램을 병행해서 업데이트 진행해야합니다.

저는 tmux 를 사용했습니다.

apt update
apt dist-upgrade

업데이트를 완료하면, 재시작을 하지않아도 좌상단에 업데이트된 PVE 버전정보가 확인됩니다.

 

주요 변경점

v9.0 Highlights

1. 기존 스냅샷 저장방식인 Thin LVM 외의 Thick LVM 지원

원문 : VM snapshots on thick-provisioned LVM storages with snapshots as volume chains (technology preview).
번역 : 스냅샷 볼륨으로 사용되는 Thick LVM 스토리지의 지원 ( 테스트 기능)

  • VM snapshots on thick-provisioned LVM storages with snapshots as volume chains (technology preview).
    • A new property on thick-provisioned LVM storages enables support for snapshots as volume chains.
      With this setting, taking a VM snapshot persists the current virtual disk state under the snapshot’s name and starts a new volume based on the snapshot.
      This enables VM snapshots on shared thick-provisioned LVM storages, as they are often used on LUNs provided by a storage box via iSCSI/Fibre Channel.

Thick LVM 은 VM 이 만약 100GB를 요청한다면, LVM 파티션중 100GB를 즉시 할당을 합니다. 사용량이 예측가능한 상황에서는 사용하기 좋지만, 스냅샷처럼 버전관리를 하면서 여러 스냅샷을 증분방식으로 백업한다면, Thick LVM 은 적절하지 않습니다. 그래서 Proxmox에서는 스냅샷 스토리지로 Thin LVM 방식을 고수해왔는데요

Thin LVM 방식은 논리적으로는 큰 용량을 할당해주지만, 실제로는 사용한 만큼만 물리적디스크를 사용한 방식입니다. 따라서 확장가능성이 있고, 논리적볼륨을 공유해야하는 상황에서는 사용하기 좋습니다. 용량 할당방식에서는 Ceph 의 Pool 과 비슷한 개념을 가지고있다고 볼수있습니다.
(Thin LVM은 단일 서버/LUN에서 작동하고 Ceph는 여러 서버에 분산되는 등 실제 작동 방식은 다릅니다..) 

결론적으로는 이제는 Thick LVM 방식에서도 스냅샷을 사용할 수 있게 되었다는 내용입니다.

위 개선점이 유용한점은 기존에 On-premiss 환경에서 스토리지를 Thick LVM 으로 활용중에 Proxmox 로 이관하거나, VMware 에서 사용중인 Thick LVM 파티션을 Proxmox 로 이관할때 원래는 Thin LVM이나 NFS/Ceph 으로 다시 파티셔닝하는 2차 작업이 필요했지만, Proxmox Native 기능으로 지원하게 되었다고 볼 수 있습니다. 물론 아직은 technology preivew로 열어둔 기능이기에 정상적으로 활용하려면 시간이 조금 더 필요할 수 있습니다.

2. HA 구성시 node/resource affininty 룰 추가

  • High-Availability (HA) rules for node and resource affinity
    • HA affinity rules are a new mechanism to control the placement of HA resources, such as HA-enabled VMs and containers, on nodes.
    • Node affinity rules mandate that HA resources should only be placed on particular nodes.
    • Resource affinity rules mandate that a particular set of HA resources should always stay together on the same node or spread out to different nodes.

Affninty 룰을 어디서 추가할 수 있는지 찾아보기 힘들지만 Affinity 룰셋을 자주 사용하는 쿠버네티스를 비교해보면, Affinity 룰의 경우 VM에 “노드 N번 그리고 CPU 가용량 30% 이상” 같은 affinity 룰셋을 넣은상태로 생성하여 VM 이 적재되기 최적화된 노드를 자동으로 선택하게 합니다. 설명으로는 Proxmox 에도 동일한 기능이 추가된것으로 보이는데, Proxmox 의 HA 및 분산배치가 약하다고 생각하던중에 활용하기 좋은 패치가 들어온듯 합니다.

3. SDN의 OpenFabric, OSPF 지원 = Fabric 네트워크 지원

보통 Proxmox에서는 VXLAN이나 Bridge 방식으로 네트워크 인터페이스를 생성한 후에, 각 VM들이 해당 네트워크를 사용하도록 구성하는 방식이었습니다. 이 방식은 간단한 환경에서는 문제없지만, 멀티 노드 클러스터에서 복잡한 네트워크 토폴로지를 구성하려면 상당히 번거로웠습니다.

이번에 추가된 Fabric 네트워크 기능은 기존 VXLAN 오버레이 방식과는 다른 접근입니다. OpenFabric(IS-IS 기반)과 OSPF 같은 라우팅 프로토콜을 사용해서 Proxmox 노드들 간에 자동으로 경로를 학습하고 분산된 라우팅 테이블을 구성합니다.

특히 Ceph 클러스터를 운영하는 환경에서 유용한데요, 기존에는 Ceph Public/Cluster 네트워크를 각 노드마다 수동으로 설정하고 라우팅 테이블을 관리해야 했습니다. 하지만 Fabric을 underlay로 구성하면, 노드들이 자동으로 서로를 발견하고 최적 경로로 통신하게 됩니다. Full-mesh 토폴로지를 수동으로 구성하는 것보다 훨씬 관리가 편해집니다.

실제로 3개 노드로 Ceph 클러스터를 구성할 때, 기존 방식대로라면 각 노드에 Static Route를 설정하거나 별도의 BGP 데몬을 띄워야 했는데, 이제는 Proxmox SDN에서 Fabric을 구성하고 Ceph 네트워크를 해당 Fabric에 바인딩하기만 하면 됩니다. 설정 복잡도가 확실히 줄어든 느낌입니다.

또한 VXLAN VPN의 underlay로도 활용할 수 있다는 점이 흥미롭습니다. 여러 데이터센터에 분산된 Proxmox 클러스터를 운영하는 경우, 각 사이트 간 VPN을 구성하고 그 위에 VXLAN 오버레이를 올리는 구조인데, Fabric을 사용하면 라우팅 설정이 자동화되어서 관리 포인트가 줄어듭니다.

다만 아직은 OpenFabric이나 OSPF 같은 라우팅 프로토콜에 익숙하지 않은 관리자들에게는 진입장벽이 있을 수 있습니다. 특히 문제가 발생했을 때 BGP/OSPF 로그를 분석하고 라우팅 테이블을 디버깅하는 건 여전히 CLI에서 해야 하는 부분이라, 네트워크 전문 지식이 어느 정도 필요합니다.

4. PBS (Proxmox Backup Server) 통합 강화

  • ㅑFabrics for the Software-Defined Networking (SDN) stack.
    • Fabrics are routed networks of interconnected peers.
    • The SDN stack now supports creating OpenFabric and OSPF fabrics of Proxmox VE nodes.
    • Fabrics can be used for a full-mesh Ceph cluster or act as an underlay network for Virtual Private Networks (VPN).

Proxmox Backup Server와의 연동이 더욱 강화되었습니다. 특히 백업 작업 스케줄링과 모니터링 부분에서 체감할 수 있는 개선이 있었습니다.

이전에는 백업이 진행 중일 때 단순히 “Running” 상태만 표시되고 실제 진행률이나 전송 속도를 확인하기 어려웠는데, 이제는 실시간으로 데이터 전송량, 압축률, 예상 완료 시간까지 상세하게 표시됩니다. 특히 대용량 VM을 백업할 때 언제쯤 끝날지 예측할 수 있어서 백업 윈도우 관리가 한결 수월해졌습니다.

백업 실패 시 알림 설정도 더 세밀하게 조정할 수 있게 되었는데요, 기존에는 단순히 이메일 알림만 가능했다면, 이제는 특정 백업 작업별로 다른 알림 채널을 설정할 수 있습니다.

증분 백업 체인 관리 개선도 실용적입니다. PBS는 증분 백업 방식을 사용하는데, 백업 체인이 길어지면 복원 시간이 늘어나고 스토리지 용량도 비효율적으로 사용됩니다. 이번 업데이트에서는 백업 체인의 길이를 자동으로 관리하고, 일정 기준 이상 체인이 길어지면 Full 백업을 다시 수행하거나 경고를 표시해줍니다.

다만 PBS 자체의 리소스 사용량은 여전히 신경써야 할 부분입니다. 특히 동시 백업 작업이 많아지면 PBS 서버의 CPU와 네트워크 대역폭이 병목이 될 수 있어서, 백업 스케줄을 시간대별로 분산하는 건 여전히 필요합니다.

5. qcow2 형식의 vTPM 상태 지원

이번 버전에서는 qcow2 디스크 이미지 형식으로 가상 신뢰 플랫폼 모듈(vTPM)의 상태를 저장하는 기능이 도입되었습니다. 이게 왜 중요한지는 Windows 11 VM을 운영해본 사람이라면 바로 이해할 겁니다.

Windows 11은 기본적으로 TPM 2.0을 요구하는데, Proxmox에서 vTPM을 활성화하면 VM이 TPM 칩을 가지고 있는 것처럼 동작합니다. 문제는 기존에는 vTPM 상태 파일이 raw 형식으로만 저장되어서, NFS나 CIFS 같은 네트워크 스토리지에서 VM 스냅샷을 생성할 수 없었다는 점입니다.

이제는 qcow2 형식으로 vTPM 상태를 저장할 수 있어서, 활성 vTPM이 있더라도 전체 VM 스냅샷이 가능합니다. 특히 NFS 스토리지를 주로 사용하는 환경이라면 이전에는 Windows 11 VM의 스냅샷을 생성하기 위해 vTPM을 일시적으로 비활성화하거나 로컬 스토리지로 옮겨야 했는데, 이제는 그럴 필요가 없어졌습니다.

또한 LVM 스토리지에서 볼륨 체인 방식의 스냅샷도 지원됩니다. v9.0에서 추가된 Thick LVM 스냅샷 기능과 결합하면, vTPM을 사용하는 Windows VM도 일반 VM과 동일하게 스냅샷 관리가 가능해집니다. 오프라인 스냅샷 한정이지만, 그래도 백업이나 버전 관리 측면에서 큰 개선입니다.

BitLocker를 사용하는 보안 VM 환경에서도 유용합니다. BitLocker는 TPM과 긴밀하게 연동되는데, vTPM 상태가 스냅샷에 포함되어서 복원 후에도 BitLocker 키가 정상적으로 작동합니다. 이전에는 스냅샷 복원 후 BitLocker 복구 키를 입력해야 하는 경우가 있었는데, 이제는 그런 문제가 없어졌습니다.

6. 중첩된 가상화의 세분화된 제어

Proxmox VE는 이제 특정 VM에서 중첩 가상화(Nested Virtualization)에 대한 향상된 제어 기능을 제공합니다. 이 기능은 실무에서 의외로 자주 마주치는 시나리오에서 유용합니다.

대표적인 사용 케이스가 VM 안에서 Docker나 Kubernetes를 실행하는 경우입니다. Docker 자체는 완전한 가상화는 아니지만, 일부 컨테이너 런타임이나 WSL2 같은 기술들은 내부적으로 가상화 기능을 사용합니다. 또한 Hyper-V를 활성화한 Windows VM이나, Windows Subsystem for Linux 2 (WSL2)를 사용하는 경우에도 중첩 가상화가 필요합니다.

기존에는 호스트 CPU 타입을 “host” 모드로 설정해서 모든 CPU 플래그를 게스트에 노출하는 방식을 사용했습니다. 문제는 이렇게 하면 VM이 특정 물리 호스트에 종속되어서, 다른 CPU 모델을 가진 노드로 Live Migration이 불가능해진다는 점입니다.

이번 업데이트에서는 개별 vCPU 플래그를 선택적으로 활성화할 수 있습니다. 예를 들어 Intel VT-x나 AMD-V 같은 가상화 확장 기능만 활성화하고, 나머지 CPU 플래그는 표준 프로파일을 유지할 수 있습니다. 이렇게 하면 중첩 가상화가 필요한 VM도 클러스터 내 다른 노드로 마이그레이션이 가능해집니다.

7. 향상된 SDN 상태 보고

버전 9.1에는 웹 인터페이스에서 상세 모니터링 및 보고 기능을 포함하여 향상된 소프트웨어 정의 네트워킹(SDN) 스택이 포함되어 있습니다. 이건 실제로 사용해보면 체감이 확실합니다.

기존에는 SDN으로 VXLAN이나 EVPN을 구성해도, 어떤 VM이 어느 VNet에 연결되어 있는지 확인하려면 각 VM을 일일이 클릭해서 네트워크 설정을 봐야 했습니다. 이제는 GUI에서 로컬 브리지나 VNet을 선택하면, 해당 네트워크에 연결된 모든 게스트가 한눈에 표시됩니다. 특히 클러스터 전체에 100개 이상의 VM이 있는 환경에서 네트워크 토폴로지를 파악하거나 문제를 진단할 때 엄청나게 편해졌습니다.

EVPN 존에서 학습된 IP 및 MAC 주소도 웹 GUI에서 확인할 수 있습니다. 이전에는 ip neigh show나 bridge fdb show 같은 CLI 명령어를 각 노드마다 실행해서 확인해야 했는데, 이제는 클릭 몇 번으로 전체 EVPN 토폴로지의 MAC/IP 학습 상태를 볼 수 있습니다. BGP EVPN으로 멀티 사이트 네트워크를 구성했을 때, 어느 노드가 어떤 MAC 주소를 학습했는지 추적하는게 훨씬 쉬워졌습니다.

패브릭(Fabric)도 리소스 트리에 통합되었습니다. 앞서 언급한 OpenFabric이나 OSPF로 구성한 Fabric 네트워크의 경로(Routes), 네이버(Neighbors), 인터페이스 상태를 GUI에서 직접 확인할 수 있습니다. 예를 들어 OSPF Neighbor가 정상적으로 맺어졌는지, 어떤 경로가 학습되었는지를 웹 인터페이스에서 바로 볼 수 있어서, 라우팅 문제 진단 시간이 확 줄었습니다.

IP-VRF(IP Virtual Routing and Forwarding)와 MAC-VRF 정보도 GUI에 표시됩니다. EVPN을 사용하면 여러 테넌트의 네트워크를 VRF로 분리하는데, 기존에는 각 VRF의 라우팅 테이블이나 MAC 테이블을 확인하려면 CLI에서 ip vrf exec 명령어를 사용해야 했습니다. 이제는 GUI에서 VRF별로 라우팅 정보를 필터링해서 볼 수 있어서, 멀티 테넌트 환경 관리가 훨씬 직관적입니다.

다만 여전히 복잡한 BGP 정책이나 Route Map 설정, FRR(Free Range Routing) 데몬 설정 같은 고급 기능은 CLI를 통해야 합니다. GUI는 모니터링과 기본적인 설정에는 충분하지만, 엔터프라이즈급 네트워크 구성을 하려면 네트워크 지식과 CLI 숙련도가 여전히 필요합니다. 그래도 가시성이 대폭 향상된 건 확실한 개선점입니다.

 

8. OCI 이미지 기반 LXC 컨테이너 지원 

  • LXC containers from OCI images (Technology Preview)
    • Administrators can now pull standard OCI images from registries or upload them manually and use them directly as templates.
    • Support for both full system containers and lean application containers optimized for microservices.

이건 개인적으로 Proxmox VE 9.1에서 가장 기대되는 기능입니다. 드디어 OCI 이미지 기반 LXC 컨테이너 지원 으로 컨테이너 이미지를 네이티브로 사용할 수 있게 되었습니다. 기존에 Proxmox에서 컨테이너를 운영하려면 크게 세 가지 방식이 있었습니다.

8.1 기존 사용 방법

  1. VM 안에 Docker 설치 : 가장 안정적이지만 리소스 낭비가 큽니다. 단순히 nginx 하나 띄우려고 VM 전체를 할당하는 건 비효율적이죠.
  2. LXC에 Docker 설치: 공식적으로 권장하지 않는 방법이고, 실제로 잘 깨지기도 합니다. 특히 Debian 업데이트 이후 네트워킹 문제가 자주 발생했습니다.
  3. 순수 LXC 컨테이너 : 전체 OS를 포함한 시스템 컨테이너 방식이라, Docker처럼 가볍게 앱만 띄우기엔 무겁습니다. 게다가 매번 수동으로 애플리케이션을 설치하고 설정해야 합니다.

실제로 홈랩이나 테스트 환경에서 몇 개의 컨테이너 앱을 돌리려고 할 때마다 고민이었습니다. VM을 띄우자니 리소스 낭비고, LXC에 Docker를 깔자니 불안정했습니다. 순수 LXC를 쓰자니 관리가 번거로웠죠.

이제 Proxmox VE 9.1에서는 OCI 이미지를 직접 LXC로 변환해서 실행할 수 있습니다. Docker Hub, GitHub Container Registry(GHCR), Quay, Harbor 같은 레지스트리에서 이미지를 pull 받아 바로 사용 가능합니다.

웹 UI에서 스토리지 섹션에 가보면 “Pull from OCI Registry”라는 새로운 버튼이 생겼습니다. 여기서 docker.io/nginx:latest 같은 이미지 경로를 입력하면, Proxmox가 자동으로 이미지를 다운로드하고 템플릿으로 저장합니다.

그 다음엔 일반 LXC 컨테이너 생성하듯이 CPU, 메모리, 네트워크를 설정하고 만들면 됩니다.

실제로 nginx OCI 이미지로 컨테이너를 생성해봤는데, 생성 완료 후 바로 브라우저로 접속하니까 nginx가 정상적으로 작동했습니다. Docker를 별도로 설치할 필요 없이 말이죠.
OCI 이미지에 따라 Proxmox는 두 가지 타입의 컨테이너를 생성합니다.

  • Application Container : nginx, redis 같은 단일 애플리케이션 이미지. 최소한의 파일시스템만 포함하고 해당 앱만 실행됩니다.
  • System Container : Ubuntu, Debian 같은 베이스 OS 이미지. 전체 init 시스템과 SSH를 포함한 완전한 시스템 컨테이너.

Application Container가 특히 유용한데, 기존 LXC 템플릿 방식보다 훨씬 가볍고 빠릅니다.
마이크로서비스 아키텍처 환경에서 각 서비스를 독립적인 컨테이너로 띄우기에 적합해 보입니다.

환경 변수 설정도 가능합니다.

컨테이너 생성 후 Options 탭에서 Environment Variables를 key-value 형태로 입력할 수 있어서, 애플리케이션별 설정값등을 주입하여 사용할 수 있습니다.

마운트 포인트 설정도 기존 LXC처럼 GUI에서 추가할 수 있습니다. Docker의 volume mount 개념과 유사하게, 호스트의 특정 디렉토리나 Proxmox 스토리지를 컨테이너 내부 경로에 마운트할 수 있습니다. 실제로 데이터베이스 컨테이너를 운영할 때, 데이터 디렉토리를 별도 마운트 포인트로 분리해서 컨테이너를 재생성해도 데이터가 유지되도록 구성했습니다. 콘솔 접속은 약간 특이한데, Web UI의 Console 탭은 컨테이너의 메인 프로세스 stdout만 보여줍니다. 쉘이 필요하면 Proxmox 호스트에서 pct enter <VMID> 명령어를 사용해야 합니다. 이건 Docker의 docker exec -it 와 비슷한 방식입니다.

 

이상으로 여기까지가 업데이트된 프록스목스9.1.1 리뷰였습니다. 추가적인 기능들도 있지만, 아직 활용하기 어려워보이는것은 제외했습니다.

변경점이 너무 많으니 업데이트해보고서 가지고 놀다가 시간가는 줄 모르겠네요.

 

저는 진행하고있는 프로젝트에 OSPF + Container OCI 를 합쳐서 운영해보려 합니다. L3 장비를 구하기도 힘든데 EVPN 만으로 네트워크 설정을 하자고하니 상세 라우팅을 설정하기 번거로워서 고민이 많았거든요.
또, 이미 옛날에 세팅을 다 해둔 OCI 이미지들을 LXC에 Native 형태로 올릴 수 있으니 기대가 됩니다.

나중에 시간이 된다면 사용해보고 리뷰 올리겠습니다.

 

감사합니다.

답글 남기기

이메일 주소는 공개되지 않습니다.