13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[카테고리:] proxmox

  • [Proxmox] Proxmox 네트워크 설정: 브릿지, VLAN, 본딩 완벽 가이드

    [Proxmox] Proxmox 네트워크 설정: 브릿지, VLAN, 본딩 완벽 가이드

    안녕하세요, 13년차의 서버실 주인장입니다. 홈랩을 운영하면서 다양한 가상화 환경을 구축하고 테스트해보곤 하는데요. 그중에서도 Proxmox VE(Virtual Environment)는 제가 가장 즐겨 사용하는 하이퍼바이저(Hypervisor) 중 하나입니다.

    Proxmox VE는 뛰어난 성능과 유연성으로 많은 서버실 엔지니어들의 사랑을 받고 있죠. 하지만 Proxmox VE를 처음 접하는 분들이 가장 어려워하는 부분이 바로 네트워크 설정이 아닐까 싶습니다. 브릿지(Bridge)는 또 뭐고, VLAN(Virtual Local Area Network)은 어떻게 적용하며, 본딩(Bonding)은 왜 필요한지… 저도 처음엔 이게 뭔가 싶어서 꽤 삽질했었거든요. ㅎㅎ

    오늘은 제가 지난 13년간 인프라 엔지니어로서 쌓아온 경험과 홈랩에서 직접 Proxmox VE를 만지면서 얻은 노하우를 바탕으로, Proxmox 네트워크 설정의 핵심인 브릿지, VLAN, 본딩을 완벽하게 마스터할 수 있는 가이드를 준비했습니다. 이 글을 통해 여러분의 Proxmox VE 환경이 더욱 안정적이고 효율적으로 변모할 수 있기를 바랍니다!

    Proxmox VE 네트워크의 핵심 구성 요소들을 한눈에 볼 수 있는 다이어그램입니다. 브릿지, VLAN, 본딩이 물리 네트워크와 어떻게 연결되는지 시각적으로 보여줍니다.

    Proxmox 네트워크 설정, 왜 이렇게 복잡해 보일까요? (브릿지, VLAN, 본딩 개념 이해)

    본격적인 설정에 앞서, 우리가 다룰 세 가지 핵심 개념을 먼저 명확히 이해하고 넘어가는 것이 중요합니다. 이 개념들을 잘 알아두면 나중에 트러블슈팅할 때도 훨씬 수월할 거예요.

    1. 브릿지(Bridge): 가상 스위치의 시작

    Proxmox VE에서 브릿지(Bridge)는 물리 네트워크 인터페이스와 가상 머신(VM) 및 컨테이너(LXC)를 연결해주는 가상의 스위치(Switch) 역할을 합니다. 쉽게 말해, 물리 서버 안에 소프트웨어적으로 스위치를 하나 더 만들어서 여러 가상 머신들이 그 스위치에 연결되도록 하는 거죠.

    • vmbr0: Proxmox VE를 설치하면 기본적으로 생성되는 브릿지입니다. 보통 물리 이더넷 카드(예: eno1)와 연결되어 외부 네트워크와 통신하는 역할을 합니다.
    • 역할: 여러 가상 머신들이 하나의 물리 네트워크 인터페이스를 공유하며, 마치 같은 물리 스위치에 연결된 것처럼 서로 통신할 수 있게 해줍니다.

    2. VLAN(Virtual Local Area Network): 네트워크 분리의 마법

    VLAN(Virtual Local Area Network, 가상 근거리 통신망)은 하나의 물리 네트워크 스위치를 여러 개의 논리적인 네트워크로 분리하는 기술입니다. 보안, 성능, 관리 효율성 등 여러 이유로 네트워크를 분리하고 싶을 때 사용하죠. Proxmox VE에서는 가상 머신이나 컨테이너에 특정 VLAN ID를 할당하여 해당 VLAN에 속한 네트워크 트래픽만 주고받도록 설정할 수 있습니다.

    • 태깅(Tagging): 이더넷 프레임에 VLAN ID를 추가하여 어떤 VLAN에 속하는 트래픽인지 식별합니다. IEEE 802.1Q 표준을 따릅니다.
    • 활용: 웹 서버용 VLAN, DB 서버용 VLAN, 관리용 VLAN 등 용도에 따라 네트워크를 분리하여 보안을 강화하고 트래픽 혼잡을 줄일 수 있습니다.

    3. 본딩(Bonding) 또는 티밍(Teaming): 안정성과 성능 두 마리 토끼

    본딩(Bonding)은 여러 개의 물리 네트워크 인터페이스를 하나의 논리적인 인터페이스로 묶는 기술입니다. 윈도우 서버에서는 티밍(Teaming)이라고도 부르죠. 이 기술을 사용하면 두 가지 주요 이점을 얻을 수 있습니다.

    • 고가용성(High Availability, HA): 하나의 물리 NIC(Network Interface Card)에 장애가 발생하더라도 다른 NIC를 통해 네트워크 연결이 유지됩니다. (Failover)
    • 성능 향상: 여러 NIC의 대역폭을 합쳐 더 높은 처리량을 얻을 수 있습니다. (Load Balancing)

    본딩 모드에는 Active-Backup, LACP(Link Aggregation Control Protocol) 등 여러 가지가 있는데, 이 부분은 실전 가이드에서 자세히 다뤄볼게요. 저도 처음엔 아무 모드나 쓰면 되는 줄 알았는데, 스위치 설정과 연동이 안 돼서 한참 헤매던 기억이 있네요. 😅

    Proxmox 네트워크 설정 실전 가이드: 한 단계씩 따라 해봐요!

    이제 개념을 알았으니 직접 Proxmox VE에 네트워크 설정을 해볼 시간입니다. 저는 주로 CLI(Command Line Interface)를 선호하지만, Proxmox 웹 UI(User Interface)도 함께 보여드리면서 설명해 드릴게요. 여러분의 환경에 맞춰 선택하시면 됩니다.

    1단계: 네트워크 인터페이스 확인

    가장 먼저 현재 Proxmox 서버에 어떤 물리 네트워크 인터페이스가 있는지 확인해야 합니다. SSH로 Proxmox 서버에 접속하여 다음 명령어를 입력해 보세요.

    ip a
    

    보통 eno1, enpXsY, eth0 등과 같은 이름으로 표시될 겁니다. 제 홈랩 서버에는 eno1과 eno2 두 개의 기가비트 이더넷 포트가 있네요. 여러분의 서버에 맞는 인터페이스 이름을 확인해 두세요.

    2단계: 브릿지(Bridge) 설정하기

    기본적으로 Proxmox는 vmbr0이라는 브릿지를 하나 가지고 있습니다. 여기에 추가로 브릿지를 생성하거나, 기존 브릿지에 물리 NIC를 연결해볼게요.

    웹 UI를 이용한 설정

    1. Proxmox 웹 UI에 접속합니다. (https://[Proxmox_IP]:8006)
    2. 왼쪽 메뉴에서 Datacenter -> [노드 이름] -> System -> Network로 이동합니다.
    3. ‘Create’ -> ‘Linux Bridge’를 선택합니다.
    4. 설정 창에서 다음을 입력합니다:

      • Name: vmbr1 (새로운 브릿지 이름. vmbr0은 기본이니 vmbr1부터 시작하는 게 좋습니다.)
      • IPv4/CIDR: 비워둠 (브릿지에 직접 IP를 할당하지 않고, 가상 머신에서 IP를 받도록 할 경우) 또는 192.168.100.1/24 (브릿지에 IP를 할당하여 호스트에서 직접 해당 네트워크에 접근할 경우)
      • Bridge ports: eno2 (브릿지에 연결할 물리 네트워크 인터페이스 이름. 여러 개라면 공백으로 구분)
      • VLAN aware: ✅ 체크 (VLAN 기능을 사용할 예정이라면 반드시 체크해야 합니다!)
    5. ‘Create’ 버튼을 클릭하고, 상단의 ‘Apply Configuration’을 클릭하여 변경 사항을 적용합니다.

    CLI를 이용한 설정

    /etc/network/interfaces 파일을 직접 편집하여 설정할 수 있습니다. 저는 이 방법이 더 익숙하더라고요.

    sudo nano /etc/network/interfaces
    

    파일 내용은 대략 다음과 같을 겁니다. 기존 vmbr0 설정 아래에 vmbr1을 추가해볼게요.

    auto lo
    iface lo inet loopback
    
    iface eno1 inet manual
    # Proxmox 관리용 브릿지 (기본)
    auto vmbr0
    iface vmbr0 inet static
        address 192.168.1.10/24
        gateway 192.168.1.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes # VLAN 사용 시 필수!
        #bridge-vids 20-30 # 특정 VLAN ID 범위 허용 (옵션)
    
    iface eno2 inet manual
    # 추가적인 브릿지 (데이터용 또는 VLAN 분리용)
    auto vmbr1
    iface vmbr1 inet manual # vmbr1 자체에는 IP를 할당하지 않고, VM이 직접 IP를 가져가도록
        bridge-ports eno2
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes # VLAN 사용 시 필수!
        #bridge-vids 100-200 # 특정 VLAN ID 범위 허용 (옵션)
    

    변경 후에는 네트워크 서비스를 재시작해야 하지만, Proxmox는 시스템 재부팅을 권장합니다. 특히 중요한 서버라면 Proxmox 웹 UI에서 ‘Apply Configuration’ 버튼을 누르거나, reboot 명령어를 사용하는 것이 가장 안전합니다.

    Proxmox 웹 UI에서 브릿지, VLAN, 본딩 설정을 마치고 ‘Apply Configuration’을 누르기 전의 화면입니다. 설정된 내용들을 한눈에 확인할 수 있습니다.

    3단계: VLAN(Virtual Local Area Network) 설정하기

    이제 vmbr1에 VLAN-aware 옵션을 활성화했으니, 이 브릿지를 사용하는 가상 머신에 VLAN ID를 할당해볼게요.

    가상 머신에 VLAN ID 할당 (웹 UI)

    1. 네트워크 설정을 적용할 가상 머신(VM) 또는 컨테이너(LXC)를 선택합니다.
    2. ‘Hardware’ 탭으로 이동합니다.
    3. 네트워크 장치(예: Network Device (net0))를 더블클릭합니다.
    4. 설정 창에서 다음을 확인/입력합니다:

      • Bridge: vmbr1 (앞서 생성한 VLAN-aware 브릿지)
      • VLAN Tag: 100 (할당하고 싶은 VLAN ID)
    5. ‘OK’를 클릭하고 VM을 재시작합니다.

    이렇게 설정하면 해당 VM은 vmbr1 브릿지를 통해 물리 NIC eno2로 나가되, 트래픽에 VLAN ID 100이 태깅되어 나갑니다. 물론, 이 VLAN 100을 인식하고 라우팅해줄 상위 네트워크 스위치도 그에 맞게 설정되어 있어야겠죠!

    4단계: 본딩(Bonding) 설정으로 안정성 확보하기

    여러 개의 물리 NIC를 묶어 본딩을 구성해볼게요. 저는 eno1과 eno2를 묶어 bond0을 만들고, 이 bond0을 vmbr0에 연결하여 Proxmox 관리 네트워크의 안정성을 높여보겠습니다.

    CLI를 이용한 본딩 설정

    sudo nano /etc/network/interfaces
    

    기존 eno1, eno2, vmbr0 설정을 수정하고 bond0을 추가합니다.

    auto lo
    iface lo inet loopback
    
    # 물리 NIC들은 manual로 설정하고 bond0에 포함시킵니다.
    iface eno1 inet manual
    iface eno2 inet manual
    
    # bond0 인터페이스 설정
    auto bond0
    iface bond0 inet manual
        bond-slaves eno1 eno2
        bond-miimon 100
        bond-mode active-backup # 가장 일반적이고 안정적인 모드 (Failover)
        # bond-mode 802.3ad # LACP (스위치에서 Link Aggregation 설정 필수)
        # bond-xmit-hash-policy layer2+3 # LACP 사용 시 권장
        
    # vmbr0 브릿지를 bond0에 연결합니다.
    auto vmbr0
    iface vmbr0 inet static
        address 192.168.1.10/24
        gateway 192.168.1.1
        bridge-ports bond0 # 물리 NIC 대신 bond0을 연결
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
    

    여기서 bond-mode가 중요한데요. 저는 주로 active-backup 모드를 사용합니다. 하나의 NIC가 Active로 작동하고, 다른 NIC는 Passive로 대기하다가 Active NIC에 문제가 생기면 자동으로 Passive NIC가 Active로 전환되는 방식이죠. 스위치 설정 변경 없이 Proxmox 서버 단독으로 구성할 수 있어 홈랩 환경에서 매우 편리합니다.

    만약 더 높은 성능을 원하고 스위치에서 LACP(Link Aggregation Control Protocol)를 지원한다면, 802.3ad 모드를 사용하고 스위치에서도 해당 포트들을 LACP 그룹으로 묶어줘야 합니다. 이 경우 bond-xmit-hash-policy 설정도 중요하구요. 이 부분에서 스위치 설정과 Proxmox 본딩 모드가 일치하지 않아 통신이 안 되는 삽질을 꽤 많이 했었습니다. ⚠️

    설정 변경 후에는 마찬가지로 Proxmox 웹 UI에서 ‘Apply Configuration’을 누르거나, 서버를 재부팅하여 변경 사항을 적용합니다.

    ⚠️ 삽질 대잔치! Proxmox 네트워크 설정 시 제가 겪었던 문제들

    네트워크 설정은 한 글자만 틀려도 통신이 안 되는 경우가 많아서 정말 골치 아프죠. 저도 수많은 삽질을 통해 깨달은 것들이 많습니다. 여러분은 저 같은 실수를 겪지 않으시길 바라며, 몇 가지 주의사항과 트러블슈팅 팁을 공유합니다.

    1. 잘못된 IP 설정으로 관리 인터페이스 접근 불가

    Proxmox 웹 UI에 접속하는 IP 주소(보통 vmbr0에 할당된 IP)를 잘못 설정하거나, 네트워크 서비스를 재시작했는데 IP가 적용이 안 되는 경우가 있습니다. 이럴 땐 정말 등골이 오싹해지죠. 😱

    • 해결책: 물리 서버에 직접 모니터와 키보드를 연결하여 콘솔에 접속합니다. ip a 명령어로 현재 IP 주소를 확인하고, /etc/network/interfaces 파일을 다시 확인하여 수정합니다. 변경 후에는 systemctl restart networking 명령어를 시도하거나, 안전하게 reboot 합니다.

    2. VLAN 태그 누락 또는 오설정

    분명 VLAN ID를 넣었는데 가상 머신에서 통신이 안 된다면 다음을 확인해 보세요.

    • Proxmox 브릿지에 bridge-vlan-aware yes 설정이 되어 있는지? 이 옵션이 없으면 VLAN 태그를 무시합니다.
    • 가상 머신 네트워크 설정에 VLAN Tag가 정확히 입력되었는지?
    • 물리 스위치 포트 설정: Proxmox 서버가 연결된 스위치 포트가 트렁크(Trunk) 모드로 설정되어 있고, 필요한 VLAN ID들이 모두 허용(Permit)되어 있는지 확인해야 합니다. 제가 초보 때 가장 많이 놓쳤던 부분입니다. 스위치 설정과 Proxmox 설정이 일치해야만 VLAN이 정상 작동합니다.

    3. 본딩 모드 선택의 중요성

    본딩 모드(bond-mode)를 잘못 선택하면 성능 저하는 물론, 아예 통신이 안 될 수도 있습니다.

    • active-backup: 가장 안전한 모드. 스위치 설정이 필요 없습니다. 단순 이중화 목적이라면 이 모드를 추천합니다.
    • 802.3ad (LACP): 성능 향상과 이중화를 동시에 얻을 수 있지만, 반드시 스위치에서도 해당 포트들을 LACP 그룹으로 묶어줘야 합니다. 스위치 설정이 없다면 통신이 안 되거나 불안정해질 수 있습니다. 스위치 매뉴얼을 꼼꼼히 확인하세요.

    4. 스위치 설정과의 연동

    가장 중요하면서도 간과하기 쉬운 부분입니다. Proxmox 서버의 네트워크 설정은 단독으로 작동하는 것이 아니라, 연결된 물리 스위치와 유기적으로 연동되어야 합니다. 특히 VLAN이나 LACP 본딩을 사용할 때는 스위치의 포트 설정(Access/Trunk 모드, 허용 VLAN, LACP 그룹)이 Proxmox 설정과 정확히 일치하는지 반드시 확인해야 합니다. 저는 이 부분 때문에 밤을 새워가며 삽질했던 경험이 정말 많습니다. 😅

    설정 완료! 제대로 작동하는지 확인해볼까요?

    모든 설정을 마치셨다면, 이제 정상적으로 작동하는지 확인해볼 차례입니다. “드디어 됐다!” 하는 희열을 느낄 수 있는 순간이죠. 🎉

    1. Proxmox 웹 UI 확인: Datacenter -> [노드 이름] -> System -> Network 탭에서 설정한 브릿지, 본딩 인터페이스가 정상적으로 올라와 있는지 확인합니다. 상태가 ‘active’여야 합니다.
    2. 가상 머신 통신 테스트: VLAN을 할당한 가상 머신에서 해당 VLAN의 게이트웨이나 다른 서버로 ping 테스트를 해봅니다.
    3. 본딩 Failover 테스트 (Active-Backup 모드): 본딩된 물리 NIC 중 하나를 케이블에서 뽑아봅니다. 잠시 후에도 Proxmox 서버가 네트워크에 연결되어 있고, 가상 머신 통신도 정상이라면 본딩이 잘 작동하는 것입니다. 물론 테스트 후에는 다시 케이블을 연결해야겠죠! 💡

    Proxmox 가상 머신에 VLAN을 설정하고, 해당 VLAN 네트워크 내에서 성공적으로 핑 테스트를 수행한 결과 화면입니다. 네트워크가 정상적으로 작동함을 보여줍니다.

    13년차 서버실의 마무리: Proxmox 네트워크 설정, 이제 두렵지 않아요!

    오늘은 Proxmox VE의 핵심인 브릿지, VLAN, 본딩에 대해 깊이 있게 다뤄봤습니다. 개념부터 실전 설정, 그리고 제가 직접 겪었던 삽질 경험과 해결책까지 솔직하게 공유해 드렸는데요.

    처음에는 복잡하게 느껴질 수 있지만, 몇 번 직접 해보고 트러블슈팅을 겪다 보면 금방 익숙해지실 겁니다. 특히 네트워크는 이론만으로는 부족하고, 직접 만져보고 겪어봐야 진짜 내 것이 되더라고요.

    Proxmox VE의 네트워크 설정은 여러분의 가상화 환경을 더욱 유연하고 안정적으로 만들어줄 것입니다. 이 글이 Proxmox VE를 사용하시는 모든 분들께 좋은 멘토가 되었으면 좋겠습니다. 다음번에는 Proxmox VE의 스토리지 설정이나 고가용성 클러스터 구축에 대한 경험담도 풀어볼까 합니다. 기대해 주세요!

    Proxmox 네트워크의 브릿지, VLAN, 본딩 개념과 주요 특징, 설정 팁을 요약하여 시각적으로 보여주는 인포그래픽입니다.

  • [Proxmox] Proxmox GPU 패스스루 완벽 가이드: 가상머신에서 그래픽카드 활용하기

    [Proxmox] Proxmox GPU 패스스루 완벽 가이드: 가상머신에서 그래픽카드 활용하기

    Proxmox GPU 패스스루 완벽 가이드: 가상머신에서 그래픽카드 활용하기

    안녕하세요, 13년차 서버실 지킴이 ’13년차의 서버실’입니다. 오늘은 많은 분들이 홈랩에서 꿈꾸는 로망 중 하나인 Proxmox GPU 패스스루에 대한 이야기를 해볼까 합니다. 하나의 강력한 서버로 여러 가상머신(VM)을 돌리면서, 특정 가상머신에 고성능 그래픽카드(GPU)를 통째로 할당해주는 기술이죠. 저도 처음엔 ‘이게 가능하다고?’ 싶었는데, 실제로 해보니 그 활용도가 무궁무진하더라고요. 게이밍 VM부터 AI/딥러닝 워크스테이션, 그리고 미디어 트랜스코딩 서버까지, 여러분의 상상력을 현실로 만들어줄 마법 같은 기술입니다. 저도 수많은 삽질 끝에 성공했고, 그 과정에서 얻은 소중한 경험과 팁들을 오늘 이 자리에서 아낌없이 풀어놓으려 합니다.

    혹시 여러분도 저처럼 비싼 장비 여러 대를 들이지 않고, 하나의 서버로 모든 것을 해결하고 싶은 꿈을 꾸고 계신가요? 그렇다면 이 글이 여러분의 길잡이가 되어줄 겁니다. 제가 직접 해보니 얻는 게 정말 많더라고요. 그럼, 함께 Proxmox GPU 패스스루의 세계로 떠나볼까요?

    Proxmox VE 환경에서 호스트 서버에 설치된 GPU가 가상머신으로 직접 연결되는 개념을 시각적으로 보여주는 다이어그램입니다.

    2. Proxmox GPU 패스스루, 대체 뭘까요? (개념 설명)

    Proxmox GPU 패스스루(GPU Passthrough)는 말 그대로 호스트 시스템(Proxmox VE)에 장착된 물리적인 그래픽카드를 특정 가상머신에 ‘통째로’ 넘겨주는 기술을 의미합니다. 보통 가상머신은 에뮬레이션된 가상 그래픽 장치를 사용하기 때문에 성능이 제한적이죠. 하지만 패스스루를 사용하면 가상머신이 마치 물리적인 컴퓨터에 그래픽카드가 직접 꽂혀있는 것처럼 GPU의 모든 성능을 활용할 수 있게 됩니다.

    이 기술의 핵심에는 IOMMU (Input/Output Memory Management Unit)라는 하드웨어 기능이 있습니다. IOMMU는 가상머신이 물리적인 장치에 직접 접근할 수 있도록 메모리 주소를 매핑해주는 역할을 해요. 그리고 리눅스 커널의 VFIO (Virtual Function I/O) 드라이버가 이 IOMMU 기능을 활용해서 PCI 장치(GPU 포함)를 가상머신으로 패스스루할 수 있도록 도와줍니다. 쉽게 말해, Proxmox VE 호스트가 GPU에 대한 통제권을 내려놓고, 그 통제권을 특정 가상머신에게 완전히 이양하는 것이라고 보시면 됩니다. 그래서 **Proxmox VE 그래픽카드**를 가상머신에서 완벽하게 활용할 수 있게 되는 거죠. 저도 처음엔 개념이 좀 어려웠는데, 직접 해보면서 ‘아, 이게 이런 원리로 돌아가는구나!’ 하고 깨달았어요.

    3. 실전 구현: Proxmox에서 GPU 패스스루 설정하기

    자, 이제 이론은 충분합니다. 저와 함께 실제로 Proxmox VE에 **가상머신 GPU** 패스스루를 설정해보는 시간을 가져볼까요? 제가 직접 해본 가장 안정적인 방법들을 단계별로 알려드릴게요. 저도 이 과정에서 수많은 시행착오를 겪었거든요. 하나하나 따라오시면 분명 성공하실 수 있을 겁니다! 💡

    1. BIOS/UEFI 설정 확인 및 활성화

      가장 먼저 할 일은 서버의 BIOS/UEFI에서 IOMMU 기능을 활성화하는 것입니다. AMD 시스템에서는 AMD-Vi, Intel 시스템에서는 Intel VT-d라는 이름으로 되어있을 거예요. 이 옵션이 꺼져있으면 GPU 패스스루는 아예 불가능합니다. 저도 처음에 이거 확인 안 했다가 시간 좀 날렸습니다. ⚠️

    2. Proxmox VE 호스트 설정: IOMMU 활성화 및 VFIO 모듈 로드

      Proxmox VE 호스트에서 IOMMU 기능을 커널에 알려주고, VFIO 모듈을 미리 로드해야 합니다. SSH로 접속해서 다음 명령어를 입력하세요.

      # GRUB 설정 파일 수정
      # Intel CPU의 경우
      sudo nano /etc/default/grub
      # GRUB_CMDLINE_LINUX_DEFAULT="quiet" 부분을 찾아 다음과 같이 수정합니다.
      # GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"
      
      # AMD CPU의 경우
      # GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"
      
      # 수정 후 GRUB 업데이트
      sudo update-grub
      
      # VFIO 모듈 로드 설정
      sudo nano /etc/modules
      # 다음 내용을 추가합니다.
      vfio
      vfio_iommu_type1
      vfio_pci
      vfio_virqfd
      
      # blacklist nouveau 드라이버 (NVIDIA GPU 사용 시 필수)
      sudo nano /etc/modprobe.d/blacklist.conf
      # 다음 내용을 추가합니다.
      blacklist nouveau
      options nouveau modeset=0
      
      # GPU 사운드 카드 드라이버 blacklist (HDMI/DisplayPort 오디오 사용 시 충돌 방지)
      sudo nano /etc/modprobe.d/pve-blacklist.conf
      # 다음 내용을 추가합니다.
      blacklist snd_hda_intel
      blacklist snd_hda_codec_hdmi
      blacklist i915 # Intel 내장 그래픽 사용 시 필요
      
      # 초기 램디스크(initramfs) 업데이트 (매우 중요!)
      sudo update-initramfs -u -a
      
      # 재부팅
      sudo reboot

      재부팅 후 `dmesg | grep -i iommu` 명령으로 IOMMU가 성공적으로 활성화되었는지 확인하세요. `DMAR: IOMMU enabled` 같은 메시지가 보이면 성공입니다. 👍

    3. GPU PCI ID 확인 및 VFIO에 바인딩

      이제 여러분의 GPU PCI ID를 확인하고, 이 ID를 VFIO 드라이버에 할당해야 합니다.

      # GPU PCI ID 확인 (VGA compatible controller와 Audio device 부분을 잘 보세요)
      # 예시: 01:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] (rev a1)
      #       01:00.1 Audio device: NVIDIA Corporation GP107GL High Definition Audio Controller (rev a1)
      sudo lspci -nnk | grep -i vga -A3
      sudo lspci -nnk | grep -i audio -A3
      
      # 위에 나온 벤더:디바이스 ID를 기록합니다. (예: 10de:1c8c, 10de:0fb9)
      
      # VFIO에 바인딩할 PCI ID 설정
      sudo nano /etc/modprobe.d/vfio.conf
      # 다음 내용을 추가합니다. (여러분의 PCI ID로 변경하세요!)
      options vfio-pci ids=10de:1c8c,10de:0fb9 disable_vga=1

      다시 `sudo update-initramfs -u -a` 명령으로 초기 램디스크를 업데이트하고, 재부팅합니다. 재부팅 후 `lspci -nnk | grep -i vga -A3` 명령으로 GPU가 `Kernel driver in use: vfio-pci`로 바인딩되었는지 확인하세요. 이게 제일 중요합니다! ✅

    4. 가상머신(VM) 설정

      이제 Proxmox VE 웹 인터페이스에서 GPU를 패스스루할 가상머신을 선택하고, 하드웨어 설정에 들어갑니다. 저도 이 화면에서 얼마나 많은 시도를 했는지 몰라요. ㅎㅎ

      1. 가상머신을 생성하거나 선택합니다. (Windows VM이 일반적입니다)
      2. 하드웨어 탭에서 Add > PCI Device를 클릭합니다.
      3. 이전에 확인했던 GPU의 PCI 장치(VGA compatible controller와 Audio device)를 각각 추가합니다.
      4. 옵션에서 Primary GPU, All Functions, PCI-Express(가능하다면)를 선택합니다.
      5. RomBar를 체크 해제하고, Advanced > PCI-Express를 활성화하는 것이 좋습니다.

    Proxmox VE 웹 인터페이스에서 가상머신의 ‘하드웨어’ 탭에서 ‘PCI Device’를 추가하는 과정과 설정 옵션들을 보여주는 스크린샷입니다.

    4. ⚠️ 삽질 대잔치! Proxmox GPU 패스스루 트러블슈팅 노하우

    솔직히 Proxmox GPU 패스스루는 한 번에 성공하기 쉽지 않습니다. 저도 수많은 밤을 새워가며 삽질 좀 했습니다. 특히 **Proxmox VE 그래픽카드**를 패스스루할 때 발생하는 몇 가지 고질적인 문제들이 있어요. 제가 겪었던 대표적인 문제들과 해결책을 공유해 드릴게요.

    • IOMMU 그룹 문제

      가장 흔한 문제입니다. GPU와 다른 장치들이 같은 IOMMU 그룹에 묶여 있으면, GPU만 단독으로 패스스루할 수 없습니다. `for d in /sys/kernel/iommu_groups/*/devices/*; do n=${d##*/}; dev=$(lspci -nns $n); echo “IOMMU Group ${d%/devices/*##*/}”; echo ” $dev”; done` 명령으로 IOMMU 그룹을 확인해 보세요. 만약 GPU와 다른 장치가 같은 그룹에 있다면, BIOS/UEFI에서 PCI-E 슬롯별 IOMMU 분리가 가능한지 확인하거나, ACS Override 패치를 적용하는 방법도 있지만, 이는 커널을 수정해야 하는 고급 과정이라 초보자에게는 권장하지 않습니다. 저는 이 문제 때문에 메인보드까지 바꿀 뻔했습니다. 😭

    • NVIDIA Error 43

      Windows 가상머신에서 NVIDIA 드라이버를 설치했을 때 ‘코드 43’ 오류가 발생하는 경우가 많습니다. NVIDIA가 가상화 환경에서의 GPU 사용을 제한하려는 조치 때문인데요. 이 문제는 VM 설정에 `args: -cpu host,kvm=off,hv_vendor_id=null`을 추가하거나, 그래픽카드 펌웨어(ROM) 파일을 추출하여 `vga: all,romfile=/path/to/gpu_rom.bin` 옵션을 사용하는 방법으로 해결할 수 있습니다. 저는 `args` 옵션으로 해결했어요. 이거 하나 해결하고 얼마나 기뻤는지 모릅니다! 🎉

      # VM 설정 파일 수정 (VMID를 여러분의 VMID로 변경하세요)
      sudo nano /etc/pve/qemu-server/YOUR_VMID.conf
      # 맨 아래에 다음 줄을 추가합니다.
      args: -cpu host,kvm=off,hv_vendor_id=null
    • HDMI/DisplayPort 오디오 문제

      GPU 패스스루 후 HDMI나 DisplayPort를 통한 오디오 출력이 안 되는 경우가 있습니다. 이는 GPU의 오디오 컨트롤러가 제대로 패스스루되지 않았거나, 호스트의 사운드 드라이버와 충돌하기 때문인데요. 앞서 `pve-blacklist.conf`에 `snd_hda_intel` 등을 blacklist 하는 것으로 대부분 해결됩니다. 저도 이 때문에 한참을 헤맸는데, 간단한 설정으로 해결될 때의 쾌감이란! 😆

    • VM 부팅 시 블랙 스크린

      VM 부팅 시 화면이 아예 안 나오는 경우가 있습니다. 이는 주로 `vga` 옵션 설정 문제입니다. VM 설정에서 `Display`를 `none`으로 설정하고, `vga` 옵션에서 `all` 대신 `qxl` 또는 `virtio`를 시도해보세요. 그리고 패스스루한 GPU를 `Primary GPU`로 설정하는 것도 잊지 마세요.

    5. 드디어 성공! Proxmox 게이밍 VM (검증 및 결과)

    이 모든 삽질과 노력을 거쳐 드디어 **Proxmox 게이밍 VM**이 제 기능을 하는 순간을 맞이했습니다! 가상머신에 Windows를 설치하고, GPU 드라이버를 설치한 다음 장치 관리자를 열어보세요. 여러분의 물리적인 그래픽카드가 ‘디스플레이 어댑터’ 목록에 제대로 인식되어 있다면 성공입니다! ✅

    저는 Windows 10 VM에 NVIDIA RTX 3070을 패스스루해서 게임을 돌려봤는데, 놀랍게도 물리적인 PC에서 돌리는 것과 거의 차이 없는 성능을 보여주더라고요. 벤치마크 점수도 만족스러웠고요. 3DMark 같은 툴로 테스트해봐도 점수가 잘 나옵니다. 이 감동은 직접 경험해보셔야 알 수 있습니다. 드디어 하나의 서버로 게임도 하고, 서버도 돌리는 진정한 홈랩을 구축한 거죠! 😎

    Windows 가상머신 내부의 장치 관리자 화면으로, 패스스루된 NVIDIA 그래픽카드가 ‘디스플레이 어댑터’ 목록에 오류 없이 정상적으로 인식된 상태를 보여줍니다.

    6. Proxmox GPU 패스스루, 그래서 뭐가 좋을까요? (장단점)

    이렇게 힘들게 Proxmox GPU 패스스루를 설정했는데, 과연 어떤 장점과 단점이 있을까요? 제가 직접 경험해본 바를 바탕으로 정리해봤습니다.

    장점 (Pros) 단점 (Cons)
    고성능 그래픽 작업 가능: 가상머신에서 게임, 딥러닝, 영상 편집 등 GPU 자원이 필요한 작업을 원활하게 수행할 수 있습니다. 복잡한 설정 과정: 초기 설정이 매우 복잡하고, 트러블슈팅에 많은 시간과 지식이 필요합니다.
    하드웨어 통합 및 비용 절감: 여러 대의 물리적인 PC 대신 하나의 강력한 서버로 다양한 용도의 VM을 운영할 수 있어 공간과 비용을 절약할 수 있습니다. 호환성 문제: 모든 메인보드, CPU, GPU 조합이 완벽하게 호환되는 것은 아닙니다. 특히 IOMMU 그룹 문제가 발생하기 쉽습니다.
    유연한 자원 할당: 필요에 따라 GPU를 다른 VM으로 할당 변경하거나, 여러 GPU를 각각 다른 VM에 할당할 수 있습니다. 호스트 자원 제약: GPU 패스스루를 사용하면 호스트 시스템은 해당 GPU를 사용할 수 없으며, 호스트의 그래픽 출력이 제한될 수 있습니다.
    운영체제 독립성: Windows, Linux 등 원하는 운영체제에 GPU를 할당하여 사용할 수 있습니다. 전력 소모 및 발열 증가: 고성능 GPU를 사용하면 서버의 전력 소모와 발열이 크게 증가할 수 있습니다.

    Proxmox GPU 패스스루의 주요 장점(고성능 작업, 비용 절감, 유연성)과 단점(복잡한 설정, 호환성 문제, 자원 제약)을 시각적으로 요약한 인포그래픽입니다.

    7. 마무리하며: 다음 도전은 무엇일까요?

    오늘은 Proxmox VE에서 **Proxmox GPU 패스스루**를 통해 가상머신에서 그래픽카드를 활용하는 방법을 자세히 알아봤습니다. 쉽지 않은 과정이었지만, 한번 성공하고 나면 그 만족감은 정말 크실 겁니다. 저도 이 과정을 통해 하드웨어와 가상화 기술에 대한 이해를 한층 더 깊게 할 수 있었어요. 사실 이게 바로 홈랩의 매력이 아닐까 싶습니다. 직접 삽질하고 성공하면서 배우는 것들이 정말 많거든요.

    여러분도 이 가이드를 통해 성공적으로 **가상머신 GPU**를 설정하고, 꿈에 그리던 **Proxmox 게이밍 VM**이나 딥러닝 워크스테이션을 구축하시길 바랍니다. 혹시 더 궁금한 점이나 막히는 부분이 있다면 언제든지 댓글로 질문해주세요. 제가 아는 한에서 최대한 도와드리겠습니다.

    다음번에는 Proxmox에서 USB 패스스루를 통해 로컬 저장 장치나 보안 동글을 가상머신에 연결하는 방법에 대해서도 다뤄볼 예정입니다. 계속해서 ’13년차의 서버실’에 많은 관심 부탁드립니다! 감사합니다. 👋

  • [Proxmox] Proxmox VE 8.2 업그레이드 완벽 가이드 — 안전한 업데이트 방법

    [Proxmox] Proxmox VE 8.2 업그레이드 완벽 가이드 — 안전한 업데이트 방법

    안녕하세요, 13년차의 서버실 운영자입니다. 오늘은 홈랩이나 작은 서버실에서 사용하고 계실 Proxmox VE(Virtual Environment), 그중에서도 최신 버전인 Proxmox VE 8.2 업그레이드 과정과 업데이트에 대한 이야기를 나눠볼까 합니다.

    저는 13년 넘게 인프라 엔지니어로 일하면서 수많은 서버를 만져봤는데, 제 손으로 직접 구축하고 운영하는 홈랩만큼 애착 가는 곳은 없더라고요. Proxmox VE는 그런 저의 홈랩 운영에 있어 정말 빠질 수 없는 핵심 솔루션입니다. 그런데 새로운 버전이 나올 때마다 ‘업데이트를 해야 하나 말아야 하나’, ‘혹시 문제가 생기면 어쩌지?’ 하는 고민, 다들 한 번쯤 해보셨을 거예요. 특히 저처럼 여러 VM과 컨테이너(LXC)가 돌아가는 환경이라면 더욱 그렇죠.

    저도 Proxmox 버전 업그레이드하다가 몇 번 삽질했거든요. 네트워크 설정이 꼬이거나, 특정 VM이 부팅이 안 되는 경우도 있었고요. 하지만 그 모든 경험들이 지금의 저를 만들었다고 생각합니다. 그래서 오늘은 제가 직접 Proxmox VE 8.2로 업그레이드하면서 겪었던 과정과, 어떻게 하면 좀 더 안전하고 확실하게 시스템을 Proxmox 업그레이드할 수 있는지 그 노하우를 자세히 알려드릴게요. 자, 그럼 Proxmox VE 8.x 계열의 최신 버전을 향한 여정, 함께 떠나볼까요? 🎉

    Proxmox VE 8.2 업데이트를 위한 아키텍처 다이어그램. 현재 시스템 상태와 업데이트 후 예상되는 시스템 변경 사항을 시각적으로 보여줍니다.

    Proxmox VE 8.2, 뭐가 달라졌을까요? (핵심 개념 파악)

    본격적인 Proxmox VE 8.2 업그레이드 전에, 이번 버전의 핵심 변화를 짚고 넘어가야 합니다. Proxmox VE 8.x 버전은 기반 운영체제(Underlying OS)로 Debian 12 “Bookworm”을 사용하고 있거든요. 이전 7.x 버전이 Debian 11 “Bullseye” 기반이었던 것을 생각하면, 내부적으로 정말 많은 변화가 있었다는 걸 짐작할 수 있죠. 커널 버전도 Linux Kernel 6.8로 업그레이드되면서, 최신 하드웨어 지원과 성능 개선이 이루어졌습니다.

    쉽게 말해, Proxmox VE는 가상화 플랫폼이기 때문에 그 아래서 돌아가는 운영체제의 안정성과 최신 기술 지원이 정말 중요합니다. Debian 12로의 전환은 더 나은 보안, 개선된 패키지 관리, 그리고 최신 드라이버 지원을 의미하죠. 물론 UI나 기능적으로도 소소한 개선점들이 있지만, 가장 큰 변화는 바로 이 기반 OS의 업그레이드라고 보시면 됩니다.

    이런 변화들은 기존 시스템에서 Proxmox 업그레이드를 진행할 때 몇 가지 주의할 점이 생긴다는 뜻이기도 합니다. 특히 서드파티 저장소(Third-party repository)를 추가해서 사용하고 계셨다면 더더욱 신경 써야 합니다. 저도 예전에 그래픽 카드 패스스루(PCI Passthrough) 관련 드라이버 때문에 고생했던 기억이 나네요. 😅

    본격적인 Proxmox VE 8.2 업그레이드 과정 (단계별 가이드)

    이제 실전입니다. Proxmox VE 8.2 업그레이드를 위한 단계별 가이드를 시작해볼게요. 제가 직접 해보니 몇 가지 중요한 사전 작업과 순서가 있더라고요. 하나씩 따라오시면 무리 없이 진행하실 수 있을 겁니다. 💡

    1. 사전 준비 및 백업 (가장 중요! ⚠️)

    업그레이드 전에는 무조건 백업이 필수입니다. “설마 문제가 생기겠어?”라고 생각하다가 크게 후회하는 경우가 많거든요. 저도 예전에 백업 없이 진행했다가 밤새 복구한다고 씨름했습니다. 여러분은 저 같은 삽질은 하지 마세요! 모든 VM과 LXC를 백업하고, 가능하다면 Proxmox 설정 파일까지 백업해두세요.

    • VM/LXC 백업: Proxmox 웹 UI에서 각 VM/LXC를 선택 후 ‘Backup’ 메뉴를 이용합니다. 외부 스토리지에 저장하는 것을 권장합니다.
    • Proxmox 설정 백업: 핵심 설정 파일들을 수동으로 백업해두는 것도 좋습니다.
    
    # SSH로 Proxmox 호스트에 접속
    # /etc/pve 디렉토리 전체를 압축하여 백업
    tar -cvzf /root/pve-config-backup-$(date +%F).tar.gz /etc/pve
    # 네트워크 설정 백업 (필요시)
    cp /etc/network/interfaces /root/interfaces-backup-$(date +%F)
    # 다른 중요한 설정 파일들도 백업 (예: /etc/fstab, /etc/default/grub)
    

    그리고 또 중요한 것이, 현재 시스템의 모든 패키지를 최신 상태로 업데이트하는 겁니다. 깨끗한 상태에서 업그레이드를 시작해야 충돌을 줄일 수 있거든요.

    
    apt update
    apt full-upgrade -y
    apt autoremove -y
    

    업데이트 후에는 재부팅(Reboot)을 꼭 한 번 해주세요. 최신 커널이나 드라이버가 적용되지 않을 수 있거든요.

    
    reboot
    

    2. Proxmox 저장소 변경

    Proxmox VE 8.x는 Debian 12 기반이기 때문에, 기존 7.x(Debian 11)용 저장소(Repository) 설정이 맞지 않습니다. 이 부분을 꼭 바꿔줘야 해요. 특히 Enterprise 저장소를 사용하지 않는 홈랩 사용자라면, `pve-no-subscription` 저장소로 변경하는 게 중요합니다.

    
    # 기존 enterprise 저장소 주석 처리 (있다면)
    sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list
    
    # no-subscription 저장소 추가 또는 확인
    echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list
    
    # Ceph 저장소를 사용 중이라면 (선택 사항)
    # Ceph Quincy는 Debian 11용, Ceph Reef는 Debian 12용입니다.
    # 만약 Ceph Reef로 업그레이드할 예정이라면 Ceph Reef 저장소를 추가해야 합니다.
    # echo "deb http://download.proxmox.com/debian/ceph-reef bookworm no-subscription" > /etc/apt/sources.list.d/ceph.list
    # 기존 Ceph Quincy 저장소 주석 처리
    # sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/ceph.list
    

    그리고 Debian 자체 저장소도 `bullseye`에서 `bookworm`으로 변경해야 합니다.

    
    # /etc/apt/sources.list 파일 수정
    sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
    

    💡 팁: `nano`나 `vi` 에디터에 익숙하시다면 직접 파일을 열어서 수정하는 것도 방법입니다. 저는 `sed` 명령어를 즐겨 쓰는데, 초보자분들은 에디터가 더 편할 수도 있어요. 💻

    Proxmox VE 웹 UI의 ‘Updates’ 섹션에서 현재 버전과 사용 가능한 업데이트를 확인하는 화면입니다. 업데이트 진행 전후 버전을 비교할 때 유용합니다.

    3. Debian 및 Proxmox VE 업그레이드

    이제 본격적으로 Proxmox VE 8.2 업그레이드를 진행할 차례입니다. 저장소를 변경했으니, 다시 패키지 목록을 업데이트하고 전체 업그레이드를 실행하면 됩니다.

    
    apt update
    apt dist-upgrade -y
    

    이 명령은 Debian 12로의 시스템 업그레이드와 Proxmox VE 8.x 패키지들을 한 번에 처리합니다. 시간이 꽤 걸릴 수 있으니 기다려주세요. 중간에 설정 파일 관련 질문이 나올 수 있는데, 일반적으로는 “N” 또는 “keep the local version currently installed”를 선택해서 기존 설정을 유지하는 것이 안전합니다. 새로운 설정 파일을 적용해야 하는 특별한 경우가 아니라면 말이죠.

    4. 불필요한 패키지 정리 및 재부팅

    업그레이드가 완료되면, 더 이상 필요 없는 이전 버전의 패키지들을 정리해주는 것이 좋습니다. 그리고 반드시 재부팅을 해야 모든 변경 사항이 적용되고 새로운 커널로 부팅됩니다.

    
    apt autoremove -y
    reboot
    

    재부팅 후에는 시스템이 제대로 부팅되는지, Proxmox VE 서비스들이 정상적으로 작동하는지 확인해야 합니다. 이때 가장 심장이 쫄깃하죠. 😬

    ⚠️ 트러블슈팅: 제가 겪었던 문제들 (그리고 해결법)

    업그레이드가 항상 순조롭게만 진행되면 얼마나 좋을까요? 저도 몇 번 Proxmox 업그레이드하다가 예상치 못한 문제에 부딪혔습니다. 여러분도 겪을 수 있는 몇 가지 일반적인 문제와 그 해결법을 공유합니다.

    • “Unable to locate package proxmox-ve” 오류: 이 오류는 대부분 저장소 설정이 잘못되었을 때 발생합니다. `/etc/apt/sources.list.d/pve-no-subscription.list` 파일의 내용이 정확한지, 그리고 `bookworm`으로 제대로 설정되었는지 다시 확인해보세요.
    • 네트워크 인터페이스 문제: 업그레이드 후 네트워크 연결이 안 되는 경우가 있습니다. `/etc/network/interfaces` 파일을 백업해둔 것을 참고하여 수동으로 재설정하거나, 기존 설정이 새로운 커널/드라이버와 충돌하는지 확인해야 합니다. 저 같은 경우는 브릿지(Bridge) 설정이 꼬여서 한참 헤맸거든요. 😫
    • VM/LXC 부팅 문제: 특정 VM이나 LXC가 부팅되지 않을 수 있습니다. 특히 LXC의 경우, 컨테이너 템플릿(Container Template)이 구 버전인 경우 문제가 생길 수 있습니다. 새로운 템플릿으로 다시 만들거나, 컨테이너 설정을 조정해야 할 수도 있어요.
    • GRUB 부트로더 문제: 드물게 부트로더(GRUB bootloader) 설정이 꼬여서 부팅이 안 되는 경우가 있습니다. 이럴 때는 Live CD/USB로 부팅하여 GRUB을 재설치해야 합니다. (이건 정말 최후의 수단입니다!)

    문제 발생 시 가장 먼저 해야 할 일은 로그(Log) 확인입니다. `/var/log/apt/term.log`나 `journalctl -xe` 명령으로 어떤 오류가 발생했는지 자세히 살펴보세요. 대부분의 답은 로그 안에 있습니다. 🕵️‍♂️

    Proxmox VE 8.2로 성공적으로 업데이트된 후의 웹 UI 대시보드 화면입니다. 시스템 정보에 8.2 버전과 Debian 12가 표시되어 있습니다.

    Proxmox VE 8.2 업그레이드 결과 확인 ✅

    재부팅 후, 이제 시스템이 Proxmox VE 8.2로 성공적으로 업그레이드되었는지 확인해봅시다. 웹 UI에 접속하면 대시보드(Dashboard)에서 시스템 정보를 확인할 수 있을 거예요.

    • Proxmox VE 버전 확인: 웹 UI 좌측 상단 또는 ‘Summary’ 패널에서 ‘PVE Manager’ 버전을 확인합니다. 8.2.x와 같이 표시되어야 합니다.
    • Debian 버전 확인: SSH로 접속하여 다음 명령으로 확인할 수 있습니다.
    
    cat /etc/debian_version
    # 12.x (bookworm) 과 같이 표시되어야 합니다.
    
    # 커널 버전 확인
    uname -r
    # 6.8.x 와 같이 표시되어야 합니다.
    

    모든 것이 정상적으로 표시된다면, 여러분의 Proxmox 업그레이드는 성공적으로 완료된 겁니다! 🎉 이제 최신 버전의 Proxmox VE가 제공하는 향상된 성능과 안정성을 만끽하시면 됩니다.

    저는 업그레이드 후에 모든 VM과 LXC를 하나씩 켜보면서 제대로 작동하는지 꼼꼼히 확인했습니다. 특히 네트워크 설정이나 저장소 연결 같은 부분이 중요하죠. 다행히 이번에는 큰 문제 없이 잘 마무리되어서 정말 뿌듯했네요! 😊

    Proxmox VE 7.x와 8.x 버전의 주요 기능, 기반 OS, 커널 버전 등을 비교하는 표입니다. 업그레이드의 이점을 한눈에 보여줍니다.

    마무리하며: 13년차 엔지니어의 한마디

    오늘은 Proxmox VE 8.2 업그레이드 과정에 대해 제가 겪었던 경험과 함께 자세히 설명해드렸습니다. 사실 서버 관리라는 게 언제나 예측 불가능한 변수들이 존재해서, 이렇게 가이드를 드려도 막상 현장에서는 또 다른 문제가 터질 때가 많아요. 저도 수십 번 겪어본 일이라 공감합니다.

    하지만 중요한 건, 문제가 생겼을 때 당황하지 않고 차근차근 해결해나가는 능력이라고 생각해요. 백업을 철저히 하고, 공식 문서나 커뮤니티의 도움을 받는 것이 중요하죠. 그리고 가장 중요한 건, “내가 이 시스템을 이해하고 있다”는 자신감입니다. 저도 처음엔 Proxmox가 마냥 어렵게만 느껴졌는데, 하나하나 삽질해가면서 배우다 보니 이제는 제 손안의 작은 데이터센터처럼 느껴지더라고요. 😎

    이번 Proxmox VE 8.2 업그레이드 가이드가 여러분의 홈랩이나 서버실 운영에 조금이나마 도움이 되었으면 좋겠습니다. 다음번에는 Proxmox VE 8.2에서 새롭게 추가된 기능들을 활용하는 방법에 대해서도 한번 다뤄볼 생각입니다. 궁금한 점이나 겪었던 삽질 경험이 있으시다면 댓글로 공유해주세요! 그럼 다음 글에서 또 만나요! 👋

  • [Proxmox] Proxmox VE 스토리지 관리: ZFS, LVM, Ceph 비교 및 최적화 가이드

    [Proxmox] Proxmox VE 스토리지 관리: ZFS, LVM, Ceph 비교 및 최적화 가이드

    Proxmox VE 스토리지 관리: ZFS, LVM, Ceph 비교 및 최적화 가이드

    Proxmox VE는 다양한 스토리지 솔루션을 지원합니다. 가상머신 성능과 안정성을 좌우하는 스토리지 선택, 어떻게 해야 할까요?

    Proxmox VE 주요 스토리지 솔루션

    ZFS, LVM, Ceph 각각의 특징과 사용 시나리오를 정리했습니다. 당신의 인프라에 맞는 스토리지를 찾아보세요.

  • [Proxmox] Proxmox GPU 패스스루 완벽 가이드: 가상 머신에서 고성능 그래픽 활용

    Proxmox GPU 패스스루 완벽 가이드: 가상 머신에서 고성능 그래픽 활용

    홈랩을 운영하다 보면 한 번쯤은 이런 생각이 드시죠. “Proxmox에서 가상 머신 하나에 GPU를 통째로 붙여서 쓸 수 없을까?” 저도 처음에 이 생각이 들었을 때, 반신반의하면서 시도했다가 꽤 오래 삽질을 했거든요. 결론부터 말씀드리면 — 됩니다. 그것도 꽤 잘 됩니다.

    Proxmox GPU 패스스루(GPU Passthrough)는 가상화 호스트에 장착된 물리 GPU를 특정 VM(가상 머신)에 직접 할당해서, 마치 그 VM이 GPU를 단독으로 소유한 것처럼 쓸 수 있게 해주는 기술입니다. 머신러닝 학습 환경 구성, 게임 VM, 렌더링 워크스테이션 등 다양한 용도로 활용할 수 있어서, 인프라 엔지니어로서 이 기능은 정말 게임 체인저였어요.

    이 글에서는 제가 직접 수십 번의 시도 끝에 정리한 Proxmox GPU 패스스루 설정 전 과정을 단계별로 공유해 드릴게요. NVIDIA와 AMD 양쪽 다 다뤄보겠습니다.

    ▲ Proxmox 호스트에서 GPU 패스스루가 이루어지는 전체 아키텍처. 물리 GPU가 IOMMU를 통해 VM에 직접 연결되는 구조를 보여줍니다.

    1. GPU 패스스루가 뭔지 먼저 이해하고 가요

    쉽게 말해서, 일반적인 가상화에서는 VM들이 가상화된(에뮬레이션된) 하드웨어를 씁니다. GPU도 마찬가지로 가상의 그래픽 카드를 쓰게 되죠. 근데 이렇게 하면 성능이 많이 깎여요. 특히 GPU 연산 집약적인 작업에서는 더더욱.

    패스스루(Passthrough)는 이 중간 에뮬레이션 레이어를 없애고, 물리 하드웨어를 VM에 직접 넘겨주는 방식이에요. 이걸 가능하게 해주는 핵심 기술이 바로 IOMMU(Input-Output Memory Management Unit)입니다.

    구분 일반 가상 GPU GPU 패스스루
    방식 소프트웨어 에뮬레이션 물리 하드웨어 직접 할당
    성능 물리 대비 크게 저하 물리 성능과 거의 동일
    여러 VM 공유 가능 불가능 (1 GPU = 1 VM)
    드라이버 Proxmox 제공 가상 드라이버 실제 벤더 드라이버 (NVIDIA/AMD)
    주요 용도 일반 데스크톱 환경 머신러닝, 게임, 렌더링

    한 가지 알아두실 점은, GPU 패스스루를 하면 해당 GPU는 그 VM 전용이 됩니다. Proxmox 호스트 자체나 다른 VM은 그 GPU를 쓸 수 없어요. 그래서 보통 홈랩에서는 GPU가 2개이거나, 아니면 iGPU(내장 그래픽)와 dGPU(외장 그래픽)를 분리해서 쓰는 경우가 많습니다.

    2. 사전 조건 확인: 이것부터 체크하세요

    본격적으로 시작하기 전에 몇 가지 반드시 확인해야 할 게 있어요. 여기서 막히면 아무리 설정을 잘 해도 안 됩니다. 제가 처음에 이걸 무시하고 진행했다가 몇 시간을 날렸거든요 😅

    하드웨어 요구사항

    • CPU: Intel VT-d 또는 AMD-Vi(AMD IOMMU) 지원 필수
    • 메인보드: IOMMU 지원 + BIOS/UEFI에서 활성화 가능해야 함
    • GPU: 패스스루할 GPU (NVIDIA, AMD 모두 가능)
    • Proxmox 버전: 7.x 이상 권장 (이 글은 Proxmox VE 7~8 기준)

    BIOS/UEFI 설정 확인

    메인보드 BIOS에 들어가서 다음 항목들을 활성화해야 합니다.

    • Intel 시스템: VT-d (Virtualization Technology for Directed I/O) 활성화
    • AMD 시스템: AMD-Vi 또는 IOMMU 활성화
    • 가능하다면 Above 4G Decoding도 활성화 권장

    💡 팁: BIOS 설정 후 Proxmox에서 IOMMU가 제대로 인식됐는지 확인하는 방법은 아래에서 알려드릴게요.

    3. Proxmox 호스트 설정: GRUB부터 손봐야 해요

    자, 이제 실제 설정 들어갑니다. Proxmox 호스트에 SSH로 접속하거나 콘솔을 열어주세요.

    3-1. GRUB 부트 파라미터 수정

    먼저 GRUB 설정 파일을 열어야 합니다.

    nano /etc/default/grub

    파일 안에서 GRUB_CMDLINE_LINUX_DEFAULT 항목을 찾아서 수정합니다.

    Intel CPU인 경우:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

    AMD CPU인 경우:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"

    여기서 iommu=pt는 passthrough 모드를 뜻하는데, 이걸 넣어주면 IOMMU를 사용하지 않는 디바이스들의 성능 저하를 방지해줍니다. 꼭 같이 넣어주세요.

    수정 후 GRUB을 업데이트합니다.

    update-grub

    3-2. 필요한 커널 모듈 로드

    /etc/modules 파일에 VFIO 관련 모듈을 추가해줍니다. VFIO(Virtual Function I/O)는 리눅스에서 디바이스 패스스루를 담당하는 프레임워크예요.

    nano /etc/modules

    아래 내용을 파일 끝에 추가합니다.

    vfio
    vfio_iommu_type1
    vfio_pci
    vfio_virqfd

    3-3. GPU 드라이버 블랙리스트 처리

    이 부분이 정말 중요합니다. 호스트 OS가 패스스루할 GPU를 먼저 가져가버리면 VM에 넘겨줄 수가 없거든요. 그래서 호스트에서 해당 GPU 드라이버를 블랙리스트(blacklist) 처리해서 로드되지 않도록 해야 해요.

    NVIDIA GPU 블랙리스트:

    echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
    echo "blacklist nvidia" >> /etc/modprobe.d/blacklist.conf
    echo "blacklist nvidiafb" >> /etc/modprobe.d/blacklist.conf

    AMD GPU 블랙리스트:

    echo "blacklist radeon" >> /etc/modprobe.d/blacklist.conf
    echo "blacklist amdgpu" >> /etc/modprobe.d/blacklist.conf

    3-4. VFIO가 GPU를 먼저 가져가도록 설정

    먼저 패스스루할 GPU의 PCI ID를 확인합니다.

    lspci -nn | grep -i nvidia
    # 또는 AMD의 경우
    lspci -nn | grep -i amd

    출력 결과에서 GPU와 관련된 항목들의 ID를 메모해두세요. 보통 이런 형식으로 나옵니다.

    01:00.0 VGA compatible controller [0300]: NVIDIA Corporation ... [10de:2204]
    01:00.1 Audio device [0403]: NVIDIA Corporation ... [10de:1aef]

    여기서 대괄호 안의 10de:2204, 10de:1aef 같은 숫자가 바로 Vendor ID:Device ID입니다. 이걸 VFIO 설정에 넣어줍니다.

    echo "options vfio-pci ids=10de:2204,10de:1aef" >> /etc/modprobe.d/vfio.conf

    ⚠️ 중요: 위 ID는 예시입니다. 반드시 본인 시스템에서 lspci -nn으로 확인한 실제 ID를 사용하세요!

    모든 설정을 적용하고 재부팅합니다.

    update-initramfs -u -k all
    reboot

    3-5. IOMMU 활성화 확인

    재부팅 후 IOMMU가 제대로 활성화됐는지 확인해봅시다.

    dmesg | grep -e DMAR -e IOMMU

    출력에 IOMMU enabled 또는 Intel-IOMMU: enabled 같은 문구가 보이면 성공입니다. 🎉

    VFIO가 GPU를 제대로 가져갔는지도 확인해봅시다.

    lspci -nnk | grep -A3 "VGA\|3D\|Display"
    # 출력에서 'Kernel driver in use: vfio-pci' 가 보이면 성공

    ▲ Proxmox 웹 UI의 VM 하드웨어 설정에서 PCI 디바이스(GPU)를 추가하는 과정. Add > PCI Device 메뉴에서 패스스루할 GPU를 선택합니다.

    4. VM에 GPU 연결하기: Proxmox 웹 UI 설정

    호스트 설정이 끝났으면 이제 VM에 GPU를 붙여줄 차례입니다. Proxmox 웹 UI에서 진행할 수 있어요.

    1. Proxmox 웹 UI에서 패스스루할 VM을 선택합니다.
    2. VM이 꺼진 상태에서 Hardware(하드웨어) 탭으로 이동합니다.
    3. Add > PCI Device를 클릭합니다.
    4. 드롭다운에서 패스스루할 GPU를 선택합니다.
    5. 다음 옵션들을 설정합니다:
    • All Functions: 체크 — GPU와 연결된 오디오 장치 등 모든 기능 함께 패스스루
    • ROM-Bar: 체크 — GPU ROM 접근 허용
    • PCI-Express: 체크 — PCIe 방식으로 연결 (성능상 유리)
    • Primary GPU: 체크 — VM의 주 GPU로 설정 (디스플레이 출력 필요시)

    CLI로 직접 VM 설정을 수정하고 싶다면 아래처럼 할 수도 있습니다.

    # VM ID가 100이고, GPU가 PCI 01:00.0에 있는 경우
    qm set 100 -hostpci0 01:00.0,allfunctions=1,pcie=1,rombar=1,x-vga=1

    VM 설정 파일 직접 확인

    cat /etc/pve/qemu-server/100.conf

    설정 파일에 아래와 같은 내용이 들어가 있으면 정상입니다.

    hostpci0: 0000:01:00,allfunctions=1,pcie=1,rombar=1,x-vga=1
    machine: q35
    bios: ovmf

    💡 중요한 포인트: GPU 패스스루에는 OVMF(UEFI 펌웨어)와 q35 머신 타입이 필수입니다. 구형 SeaBIOS나 i440fx 머신 타입에서는 동작하지 않는 경우가 많아요. VM 생성 시 처음부터 이 설정으로 만드는 게 나중에 편합니다.

    5. VM 내부 드라이버 설치

    VM을 부팅하면 이제 GPU가 인식될 겁니다. 여기서부터는 VM 안에서 작업합니다.

    Windows VM의 경우

    Windows VM에서 GPU 패스스루를 쓰는 가장 흔한 케이스죠. 부팅 후 장치 관리자를 열어보면 GPU가 인식은 되지만 드라이버가 없는 상태일 거예요.

    1. NVIDIA 또는 AMD 공식 사이트에서 드라이버를 다운로드합니다.
    2. 일반 드라이버 설치하듯 설치하면 됩니다.
    3. 설치 완료 후 재부팅하면 GPU가 정상 동작합니다.

    ⚠️ NVIDIA 드라이버 오류 코드 43 문제: NVIDIA GPU를 Windows VM에 패스스루할 때 오류 코드 43(Code 43)이 발생하는 경우가 있습니다. NVIDIA 드라이버가 가상 환경을 감지하고 동작을 거부하는 거예요. 이럴 때는 VM 설정 파일에 다음을 추가하면 대부분 해결됩니다.

    nano /etc/pve/qemu-server/100.conf
    # 아래 내용 추가
    args: -cpu host,kvm=off
    cpu: host,hidden=1,flags=+pcid

    또는 웹 UI의 Options > CPU에서 추가 CPU 플래그를 설정해도 됩니다. kvm=off는 VM에서 KVM을 쓰고 있다는 걸 드라이버가 감지하지 못하게 숨겨주는 역할을 합니다.

    Linux VM의 경우

    Ubuntu 기준으로 NVIDIA 드라이버를 설치해봅시다.

    # 사용 가능한 드라이버 확인
    ubuntu-drivers devices
    
    # 권장 드라이버 자동 설치
    sudo ubuntu-drivers autoinstall
    
    # 또는 특정 버전 지정 설치
    sudo apt install nvidia-driver-535
    
    # 재부팅 후 확인
    nvidia-smi

    AMD GPU라면 Ubuntu에서는 대부분 자동으로 amdgpu 드라이버가 잡힙니다. 추가 작업 없이도 동작하는 경우가 많아요.

    6. 트러블슈팅: 실제 겪은 문제들

    이 섹션이 가장 실용적일 거예요. 이론대로 안 되는 경우가 정말 많거든요. 제가 직접 겪었던 문제들만 정리했습니다.

    ▲ GPU 패스스루 설정 중 자주 만나는 오류 상황별 트러블슈팅 흐름도. 각 단계에서 확인해야 할 포인트를 정리했습니다.

    문제 1: VM이 부팅 자체가 안 돼요

    OVMF(UEFI) 설정이 제대로 안 됐거나, GPU가 IOMMU 그룹에서 다른 디바이스와 묶여 있는 경우입니다.

    IOMMU 그룹 확인 스크립트를 실행해보세요.

    #!/bin/bash
    for d in /sys/kernel/iommu_groups/*/devices/*; do
      n=${d#*/iommu_groups/*}; n=${n%%/*}
      printf 'IOMMU Group %s ' "$n"
      lspci -nns "${d##*/}"
    done

    GPU가 속한 IOMMU 그룹에 다른 디바이스(예: PCIe 루트 포트)가 함께 있다면, 해당 디바이스들도 전부 같이 패스스루해야 합니다. 이게 안 되면 ACS(Access Control Services) 패치 커널을 사용해야 하는데, 이건 꽤 복잡한 주제라 별도 글에서 다룰 예정입니다.

    문제 2: GPU는 인식되는데 드라이버 설치 후 화면이 안 나와요

    Primary GPU 옵션을 켰는데 Proxmox 기본 디스플레이(VirtIO 또는 Bochs)와 충돌하는 경우입니다. VM 설정에서 Display를 None으로 바꿔보세요.

    qm set 100 -vga none

    이렇게 하면 기본 가상 디스플레이가 비활성화되고 패스스루된 GPU의 출력만 사용하게 됩니다. 물리 모니터를 GPU에 직접 연결하거나, Looking Glass 같은 도구를 활용하면 됩니다.

    문제 3: NVIDIA Code 43 오류

    위에서 언급한 것처럼 kvm=off와 hidden=1 플래그로 해결하세요. 추가로 VM 설정 파일에 아래도 넣어보세요.

    # /etc/pve/qemu-server/100.conf 에 추가
    args: -cpu host,kvm=off
    cpu: host,hidden=1

    문제 4: 재부팅 후 vfio-pci 대신 원래 드라이버가 잡혀요

    update-initramfs를 빠뜨린 경우가 많습니다. 다시 실행해주세요.

    update-initramfs -u -k all
    reboot

    7. 결과 확인: 제대로 동작하는지 검증해봐요

    드라이버 설치까지 완료했다면, 이제 GPU가 정상 동작하는지 확인할 차례입니다.

    Linux VM에서 확인

    # NVIDIA
    nvidia-smi
    
    # 출력 예시
    +-----------------------------------------------------------------------------+
    | NVIDIA-SMI ...        Driver Version: ...       CUDA Version: ...           |
    |-------------------------------+----------------------+----------------------+
    | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
    ...
    
    # AMD
    rocm-smi  # ROCm 설치 후
    # 또는
    glxinfo | grep "OpenGL renderer"

    CUDA가 필요한 환경이라면 간단한 테스트도 해볼 수 있어요.

    import torch
    print(torch.cuda.is_available())  # True 가 나오면 성공!
    print(torch.cuda.get_device_name(0))  # GPU 이름 출력

    드디어 True와 GPU 이름이 출력되는 걸 처음 봤을 때의 그 쾌감… 진짜 잊을 수가 없더라고요. 😄

    Windows VM에서 확인

    • 장치 관리자에서 GPU에 노란 느낌표 없이 정상 표시
    • DirectX 진단 도구(dxdiag)에서 GPU 정보 확인
    • GPU-Z 같은 도구로 실제 물리 GPU 정보 확인

    ▲ GPU 패스스루 성공 후 Linux VM에서의 nvidia-smi 출력과 Windows VM에서의 GPU-Z 결과. 물리 GPU 정보가 그대로 보이는 것을 확인할 수 있습니다.

    8. 정리 및 다음 단계

    여기까지 따라오셨으면 Proxmox GPU 패스스루 기본 설정은 완료입니다! 전체 과정을 한 번 정리해볼게요.

    1. ✅ BIOS에서 VT-d / AMD-Vi 활성화
    2. ✅ GRUB에 IOMMU 파라미터 추가
    3. ✅ VFIO 모듈 로드 설정
    4. ✅ 호스트에서 GPU 드라이버 블랙리스트 처리
    5. ✅ VFIO가 GPU PCI ID 선점하도록 설정
    6. ✅ initramfs 업데이트 후 재부팅
    7. ✅ VM에 PCI 디바이스로 GPU 추가 (q35 + OVMF 필수)
    8. ✅ VM 내부에서 드라이버 설치 및 확인

    처음에는 복잡해 보이지만, 한 번 제대로 이해하고 나면 다음에는 훨씬 빠르게 할 수 있어요. 저도 지금은 새 시스템에 설정하는 데 30분도 안 걸립니다.

    다음에 다룰 주제들

    • 🔜 Looking Glass: 패스스루 GPU 화면을 호스트에서 보는 방법
    • 🔜 vGPU (MIG/SR-IOV): GPU 하나를 여러 VM에 나눠 쓰는 방법
    • 🔜 IOMMU 그룹 분리 (ACS 패치): 같은 그룹 문제 해결하기
    • 🔜 머신러닝 VM 구성 완전 가이드

    궁금하신 점이나 안 되는 부분이 있으면 댓글로 남겨주세요. 제가 직접 겪은 문제라면 같이 해결해 드릴 수 있을 것 같습니다. 그리고 혹시 이 글이 도움이 됐다면, 비슷한 삽질을 하고 있을 동료 엔지니어에게 공유해주시면 감사하겠습니다! 🙏


    자주 묻는 질문 (FAQ)

    Q. Proxmox GPU 패스스루에 특별한 GPU 모델이 필요한가요?

    아니요. 대부분의 NVIDIA GeForce, Quadro, AMD Radeon, Radeon Pro 등 PCIe GPU는 패스스루가 가능합니다. 단, 호스트 시스템이 IOMMU를 지원해야 합니다.

    Q. 패스스루한 GPU를 호스트와 VM이 동시에 쓸 수 있나요?

    기본 패스스루로는 불가능합니다. 패스스루된 GPU는 해당 VM 전용이 됩니다. 여러 VM이 GPU를 나눠 쓰려면 NVIDIA vGPU(엔터프라이즈 라이선스 필요) 또는 AMD SR-IOV 지원 GPU가 필요합니다.

    Q. VM이 꺼진 후 GPU를 다른 VM에 줄 수 있나요?

    네, 가능합니다. 한 VM을 종료하고 설정에서 GPU를 제거한 뒤, 다른 VM 설정에 추가하면 됩니다. 동시에 두 VM이 쓰는 건 안 되지만, 순차적으로는 얼마든지 가능합니다.

    Q. Proxmox 호스트 자체 콘솔이 까맣게 되는데 정상인가요?

    GPU를 블랙리스트 처리하면 호스트가 그 GPU로 화면 출력을 못 하게 됩니다. 만약 그 GPU가 유일한 그래픽이라면 호스트 화면은 안 나올 수 있어요. iGPU나 별도 GPU를 호스트용으로 쓰거나, SSH/웹 UI로만 관리하는 방식을 권장합니다.

  • [Proxmox] LXC 컨테이너 심화 활용: Docker 연동 및 성능 최적화 (Proxmox VE 9.1)

    [Proxmox] LXC 컨테이너 심화 활용: Docker 연동 및 성능 최적화 (Proxmox VE 9.1)

    LXC 컨테이너 심화 활용: Docker 연동 및 성능 최적화 (Proxmox VE 9.1)

    안녕하세요, 13년차 인프라 엔지니어 ’13년차의 서버실’ 블로그 주인장입니다. 오늘도 홈랩에서 밤샘 삽질 끝에 얻어낸 귀한 경험 하나를 공유해드리려고 해요. 💡

    홈랩을 운영하거나 소규모 서버를 돌리시는 분들이라면 Proxmox VE (Virtual Environment)의 매력에 빠져 계실 텐데요. 특히 LXC (Linux Containers)는 가벼운 오버헤드로 높은 성능을 내주기 때문에 저도 애용하고 있습니다. 여기에 Docker까지 연동하면 어떨까요? 효율은 물론이고 관리 유연성까지 챙길 수 있거든요.

    오늘은 Proxmox VE 9.1 환경에서 LXC 컨테이너 안에 Docker를 설치하고, 실제 서비스를 운영하면서 겪었던 삽질과 함께 성능 최적화 팁까지 아낌없이 풀어보겠습니다. LXC와 Docker 연동에 어려움을 겪으셨다면, 이 글이 든든한 가이드가 될 거예요!

    Proxmox VE 호스트에서 LXC 컨테이너와 Docker가 연동되는 아키텍처 다이어그램

    LXC와 Docker, 그리고 그들의 시너지

    먼저 LXC와 Docker가 뭔지 간단하게 짚고 넘어갈게요. 이미 잘 아시는 분들도 계시겠지만, 핵심만 콕 짚어드리겠습니다.

    • LXC (Linux Containers, 리눅스 컨테이너): 리눅스 커널의 컨테이너 기술을 활용한 OS 수준의 가상화예요. 쉽게 말해, 별도의 커널 없이 호스트의 커널을 공유하면서도 독립적인 운영체제 환경을 만들어주는 거죠. 가상 머신(VM)보다 훨씬 가볍고 빠르고, 부팅 시간도 거의 없어서 자원 소모가 정말 적어요.
    • Docker (도커): 애플리케이션 수준의 컨테이너 기술입니다. 특정 애플리케이션과 그에 필요한 모든 종속성(라이브러리, 설정 파일 등)을 하나의 이미지(Image)로 묶어서 어디서든 동일하게 실행되도록 해줘요. 개발 환경과 운영 환경의 불일치 문제를 한 번에 해결하는 거죠.

    그럼 이 둘을 왜 같이 쓸까요? 직접 써본 결과 이런 장점들이 정말 크더라고요.

    특징 LXC + Docker 연동의 장점 기존 방식 대비
    자원 효율성 LXC는 VM보다 오버헤드가 적어서, 그 위에 Docker를 올리면 VM 내 Docker보다 훨씬 적은 자원으로 많은 서비스를 돌릴 수 있어요. VM 내 Docker: 커널 이중화로 자원 낭비
    베어메탈 Docker: 호스트 OS 오염 우려
    격리성 LXC 컨테이너가 OS 수준의 격리를 제공하고, 그 안에 Docker가 또 한 번 애플리케이션 격리를 제공하니 보안성과 안정성이 정말 높아져요. 베어메탈 Docker: 호스트 OS와 Docker 컨테이너 간 완전한 격리가 어려움
    관리 용이성 Proxmox VE의 강력한 LXC 관리 기능(스냅샷, 마이그레이션 등)과 Docker의 애플리케이션 배포/관리 기능을 동시에 누릴 수 있어요. 각각의 장점을 한 번에!

    Proxmox VE 9.1 버전에서는 LXC 컨테이너 기능이 더욱 안정화되고 사용성이 개선되었기 때문에, Docker 연동할 때 시너지가 정말 커져요.

    Proxmox VE 9.1 환경에서 LXC 컨테이너 생성 및 Docker 연동 실전 가이드

    자, 이제 직접 해볼 시간입니다. 제가 홈랩에서 실제로 진행했던 과정을 그대로 따라하시면 돼요. 😎

    1. LXC 컨테이너 기본 생성

    먼저 Proxmox VE 웹 UI에 접속해서 LXC 컨테이너를 생성합니다. OS 템플릿은 Ubuntu 22.04 LTS (Jammy Jellyfish)를 추천할게요. 가장 안정적이고 Docker 지원도 정말 잘 되거든요.

    1. Proxmox VE 웹 UI (https://<Proxmox_IP>:8006) 에 접속합니다.
    2. Datacenter -> pve -> Local (pve) -> CT Templates -> Templates에서 원하는 Ubuntu 템플릿을 다운로드해요.
    3. pve 노드에서 CT 생성 버튼을 클릭합니다.
    4. 일반 설정: Hostname, Password 등을 설정하세요.
    5. 템플릿 설정: 다운로드한 Ubuntu 22.04 LTS 템플릿을 선택해요.
    6. 디스크 설정: 최소 8GB 이상으로 설정해주세요. Docker 이미지를 많이 올릴 계획이라면 더 크게 잡는 게 좋습니다.
    7. CPU 설정: 코어는 1개 이상, CPU units (CPU 유닛)은 기본값(1024)으로 둬도 되지만, 고성능이 필요하면 더 높게 설정할 수 있어요.
    8. 메모리 설정: 최소 512MB 이상을 권장합니다. Docker 앱에 따라 달라지니 유연하게 설정하세요.
    9. 네트워크 설정: Bridge (브리지) 모드로 설정하여 호스트와 동일한 네트워크 대역을 사용하도록 하세요.
    10. 마지막으로 확인을 눌러 LXC 컨테이너를 생성합니다.

    ⚠️ 중요 포인트: 비특권 컨테이너(Unprivileged Container) 설정!

    Docker를 LXC 컨테이너 안에서 안전하게 사용하려면 비특권 컨테이너로 만드는 게 좋아요. 보안상 훨씬 유리하거든요. 하지만 비특권 컨테이너에서 Docker가 제대로 동작하려면 몇 가지 추가 설정이 필요해요.

    1. 컨테이너 생성 후, Proxmox VE 웹 UI에서 해당 LXC 컨테이너를 선택하세요.
    2. 옵션 탭으로 이동합니다.
    3. Features (기능) 항목을 찾아서 편집을 클릭하세요.
    4. 여기서 Nesting (중첩)과 FUSE (파일 시스템 인 유저스페이스)를 활성화하고 확인을 눌러요.

    이 두 가지 옵션이 Docker의 스토리지 드라이버(특히 overlay2)가 LXC 내부에서 정상적으로 작동하도록 하는 핵심이에요. 제가 이걸 몰라서 며칠 밤낮을 삽질했던 기억이 생생하네요… 😅

    Proxmox VE 웹 UI에서 LXC 컨테이너 생성 시 Nesting 및 FUSE 기능을 활성화하는 화면

    2. Docker 설치 및 설정

    LXC 컨테이너가 준비되었다면, 이제 컨테이너에 접속해서 Docker를 설치해봅시다. Proxmox 웹 UI에서 해당 LXC 컨테이너를 선택하고 콘솔 탭으로 이동하면 바로 접속돼요.

    \n# LXC 컨테이너 내부에서 실행
    
    # 패키지 목록 업데이트 및 필요한 도구 설치
    sudo apt update
    sudo apt install -y apt-transport-https ca-certificates curl gnupg lsb-release
    
    # Docker 공식 GPG 키 추가
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
    
    # Docker Stable 저장소 추가
    echo \
      "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
      $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
    
    # Docker 엔진 설치
    sudo apt update
    sudo apt install -y docker-ce docker-ce-cli containerd.io
    
    # Docker 서비스 시작 및 부팅 시 자동 시작 설정
    sudo systemctl start docker
    sudo systemctl enable docker
    
    # 현재 사용자에게 Docker 그룹 권한 추가 (선택 사항, sudo 없이 docker 명령어 사용 가능)
    sudo usermod -aG docker $USER
    
    # 변경 사항 적용을 위해 재로그인 또는 새 쉘 시작
    # exit 후 다시 접속하거나, su - $USER 명령으로 적용
    
    # Docker 설치 확인
    docker run hello-world
    

    docker run hello-world 명령을 실행했을 때 성공 메시지가 나온다면 🎉 Docker 설치가 완벽하게 된 거예요!

    3. 비특권(Unprivileged) 컨테이너의 Docker 이슈 해결 (추가 팁)

    위에서 Nesting과 FUSE를 활성화했지만, 간혹 비특권 컨테이너에서 Docker를 사용할 때 권한 문제나 스토리지 관련 이슈가 발생할 수 있어요. 특히 subuid, subgid 매핑이 제대로 안 되어있을 때 그렇습니다. 제가 겪었던 문제 중 하나였죠.

    만약 Docker 컨테이너 실행 시 권한 관련 오류가 발생한다면, Proxmox 호스트에서 다음 설정을 확인해보세요.

    1. Proxmox 호스트에 SSH로 접속합니다.
    2. /etc/subuid와 /etc/subgid 파일에 LXC 컨테이너의 UID/GID 범위가 매핑되어 있는지 확인하세요. 보통 LXC 생성 시 자동으로 추가돼요.
    3. 만약 특정 Docker 컨테이너가 호스트의 특정 디렉토리에 접근해야 하는데 권한 문제가 있다면, /etc/pve/lxc/<VMID>.conf 파일에 다음 라인을 추가하세요. (예시: 100은 컨테이너 ID)
      echo 'lxc.apparmor.profile: unconfined'
      echo 'lxc.mount.auto: cgroup:rw'
      

      이 설정은 컨테이너의 보안 프로파일을 완화하고 cgroup 마운트를 허용하여 Docker가 더 자유롭게 동작하도록 해요. 하지만 보안상 약간 취약해질 수 있으니 신중하게 사용하세요.

    4. 또 다른 방법으로는 Docker root directory를 변경하여 /var/lib/docker 대신 /mnt/data/docker처럼 별도의 마운트 경로를 사용하는 거예요. /etc/docker/daemon.json 파일을 생성(또는 편집)하고 다음 내용을 추가하세요.
      {
        "data-root": "/mnt/data/docker",
        "storage-driver": "overlay2"
      }
      

      그 후 Docker 서비스를 재시작해요: sudo systemctl restart docker. 이 방법은 특히 ZFS 같은 파일 시스템을 사용하는 Proxmox 호스트에서 LXC에 더 안정적인 Docker 스토리지 환경을 제공할 때 정말 유용해요.

    성능 최적화를 위한 팁과 트러블슈팅 ⚠️

    LXC 컨테이너에 Docker를 올리면 기본적으로 성능이 좋지만, 몇 가지 설정을 통해 더 극대화할 수 있어요.

    1. 컨테이너 자원 관리 (CPU, RAM)

    • CPU Core (CPU 코어) 할당: Proxmox VE 웹 UI에서 LXC 컨테이너의 CPU 코어를 필요한 만큼 할당하세요. 너무 많이 할당하면 다른 컨테이너나 VM의 자원을 잠식할 수 있으니, 실제 워크로드에 맞춰 조절하는 게 중요해요.
    • CPU Units (CPU 유닛) 조절: 여러 컨테이너가 CPU를 경쟁할 때, 특정 컨테이너에 더 높은 우선순위를 주고 싶다면 CPU units 값을 높게 설정해요. 기본값 1024가 공평한 분배라면, 2048은 두 배의 우선순위를 갖는 식이죠.
    • Memory (메모리) 및 Swap (스왑): Docker 컨테이너가 사용할 메모리를 충분히 할당해주세요. 스왑은 꼭 필요한 경우가 아니라면 비활성화하거나 최소한으로 설정하는 게 성능에 좋아요. 스왑이 너무 많이 발생하면 I/O 병목 현상이 생기거든요.

    2. I/O 성능 개선 (Storage)

    • SSD 사용: Proxmox VE 호스트의 OS 및 LXC 컨테이너 스토리지는 반드시 SSD (Solid State Drive)를 사용하는 게 좋아요. 특히 Docker는 이미지 다운로드, 레이어 관리 등으로 I/O 작업이 빈번하니 SSD의 이점이 극대화돼요. NVMe SSD라면 더할 나위 없겠죠.
    • LVM-Thin or ZFS: Proxmox에서 LXC 컨테이너를 생성할 때 LVM-Thin이나 ZFS 같은 스토리지를 사용하는 게 좋아요. 스냅샷 기능도 유용하고, 성능도 괜찮거든요. 개인적으로는 ZFS를 선호해요.
    • Bind Mount (바인드 마운트) 활용: Docker 컨테이너가 영구 데이터를 저장해야 한다면, LXC 컨테이너 내부의 디렉토리를 호스트의 물리 디스크에 바인드 마운트하는 게 좋아요. 예를 들어, 호스트에 별도의 데이터 디스크를 마운트하고, 이를 LXC 컨테이너에 다시 마운트한 뒤 Docker 볼륨으로 사용하는 방식이죠.
    \n# Proxmox 호스트에서 LXC 컨테이너 설정 파일 편집
    # /etc/pve/lxc/VMID.conf 에 다음 라인 추가
    lxc.mount.entry: /path/on/host /path/on/lxc none bind,create=dir 0 0
    

    3. 네트워크 설정 최적화

    • Bridge (브리지) 모드: LXC 컨테이너의 네트워크는 기본적으로 브리지 모드를 사용하는 게 가장 일반적이고 성능 저하가 적어요. 호스트의 브리지(vmbr0)에 직접 연결돼서 별도의 NAT 변환 없이 호스트와 동일한 네트워크에서 통신하거든요.
    • MacVLAN (맥브이랜): 특정 Docker 컨테이너에 별도의 물리적 MAC 주소를 할당하여 호스트 네트워크와 동등하게 통신하고 싶다면 MacVLAN을 고려할 수 있어요. 하지만 설정이 조금 복잡하고, 네트워크 장비가 이를 지원해야 해요. 저도 이 부분은 아직 삽질 중이지만, 특정 시나리오에서는 정말 유용할 수 있습니다.

    성능 검증 및 결과 확인 ✅

    모든 설정이 끝났다면, 이제 실제로 Docker 컨테이너를 띄워서 성능을 확인해볼 차례예요. docker stats 명령어로 각 Docker 컨테이너의 자원 사용량을 실시간으로 모니터링할 수 있거든요.

    \n# LXC 컨테이너 내부에서 실행
    docker stats
    

    이 명령어를 실행하면 CPU 사용량, 메모리 사용량, 네트워크 I/O, 블록 I/O 등을 한눈에 볼 수 있어요. 이 외에도 htop이나 glances 같은 도구를 LXC 컨테이너에 설치하여 전체적인 자원 사용량을 확인하는 것도 정말 좋습니다.

    제가 직접 여러 Docker 컨테이너(Nginx, MariaDB, Portainer 등)를 LXC에 올려서 테스트해보니, 확실히 VM에 올렸을 때보다 CPU와 메모리 사용량이 눈에 띄게 줄어드는 거더라고요. 특히 아이들(idle) 상태에서는 거의 자원을 사용하지 않아서 매우 만족스러웠어요. 🎉

    Proxmox LXC 내 Docker 컨테이너의 CPU, 메모리, I/O 성능 모니터링 대시보드

    마무리하며: 13년차 엔지니어의 한마디

    오늘은 Proxmox VE 9.1 환경에서 LXC 컨테이너와 Docker를 연동하고 성능을 최적화하는 방법을 심도 있게 다뤄봤어요. 제가 직접 겪었던 Nesting, FUSE 같은 핵심 삽질 포인트를 해결하는 방법을 공유하면서, 독자분들의 시간을 절약해드리고 싶었거든요. 😅

    이 조합은 가벼운 홈랩부터 소규모 프로덕션 환경까지, 자원을 효율적으로 사용하면서도 높은 유연성을 제공하는 정말 강력한 솔루션이에요. Proxmox의 안정적인 가상화 기반 위에 Docker의 강력한 애플리케이션 관리 능력을 더하는 거죠.

    물론 모든 기술이 그렇듯, 완벽한 솔루션은 없어요. 하지만 LXC와 Docker의 장점을 잘 이해하고 활용한다면, 여러분의 서버실도 더욱 스마트하고 효율적으로 운영될 수 있을 거예요. 다음에는 이 LXC + Docker 환경 위에 Docker Compose (도커 컴포즈)를 활용해서 여러 서비스를 한 번에 배포하는 방법을 다뤄볼까 하는데, 기대해주세요!

    궁금한 점이나 추가로 알고 싶은 내용이 있다면 언제든지 댓글로 남겨주세요. 여러분의 서버실 운영에 조금이나마 도움이 되었으면 좋겠고, 다음 글에서 또 만나요! 👋

    Proxmox LXC와 가상 머신(VM)에서 Docker를 실행할 때의 성능 및 자원 활용 비교 인포그래픽

  • [Proxmox] HA 클러스터 구축 및 트러블슈팅: 고가용성 완벽 가이드

    서버 한 대가 죽어도 서비스는 살아있어야 한다

    새벽 2시에 전화 받아본 적 있으신가요? “서비스가 안 된다”는 그 전화. 저는 인프라 엔지니어 생활 초반에 그 경험을 꽤 많이 했습니다. 물리 서버 한 대가 죽으면서 거기서 돌아가던 VM(가상 머신)들이 전부 같이 꺼져버리는 그 상황. 정말 식은땀 나거든요.

    그때부터 고민하기 시작했습니다. “어떻게 하면 서버 한 대가 죽어도 서비스가 자동으로 다른 서버에서 살아날 수 있을까?” 그 답이 바로 Proxmox HA(High Availability, 고가용성) 클러스터입니다.

    오늘은 제가 홈랩에서 직접 구축하면서 겪은 삽질들과 함께, Proxmox HA 클러스터를 처음부터 끝까지 완벽하게 셋업하는 방법을 공유해 드리려고 합니다. 트러블슈팅 경험도 솔직하게 담았으니 끝까지 읽어보시면 분명 도움이 될 거예요.

    ▲ Proxmox HA 클러스터의 전체 구성 아키텍처 — 3노드 구성과 쿼럼(Quorum), 공유 스토리지의 관계를 보여줍니다.

    Proxmox HA가 뭔지 먼저 제대로 알고 가자

    HA(고가용성)의 핵심 개념

    쉽게 말해서, HA는 “어떤 노드(서버)가 죽어도 거기 있던 VM이나 컨테이너가 다른 노드에서 자동으로 다시 켜지는 것”입니다. 사람이 새벽에 일어나서 수동으로 VM을 다른 서버로 옮기지 않아도 되는 거죠.

    Proxmox VE에서 HA를 구현하려면 크게 세 가지가 필요합니다.

    • 클러스터(Cluster): 여러 Proxmox 노드를 하나로 묶는 것. 최소 3개 노드 권장 (쿼럼 때문에 — 아래에서 설명)
    • 쿼럼(Quorum): 클러스터 내 다수결 투표 시스템. 과반수 노드가 살아있어야 클러스터가 정상 동작
    • 공유 스토리지(Shared Storage): 모든 노드가 같은 VM 디스크에 접근할 수 있어야 함 (Ceph, NFS, iSCSI 등)

    왜 노드가 최소 3개여야 할까?

    이게 처음엔 저도 이해가 안 됐었는데요. 노드 2개로 구성하면 한 노드가 죽었을 때 남은 노드가 “내가 살아있고 상대방이 죽은 건지, 아니면 네트워크가 끊겨서 서로 연결이 안 되는 건지” 판단을 못 합니다. 이걸 스플릿 브레인(Split-Brain) 상황이라고 하는데, 이 경우 양쪽 노드가 서로 자기가 주인이라고 착각해서 데이터 충돌이 생길 수 있거든요.

    3개 노드면 2:1로 다수결이 가능하니까 “이 노드가 죽었다”는 판단을 명확하게 할 수 있습니다. 2노드로 구성할 수는 있지만 그러면 QDevice(외부 쿼럼 장치)가 추가로 필요해요.

    구성 최소 생존 노드 장점 단점
    2노드 2개 (QDevice 필요) 비용 절감 QDevice 추가 필요, 관리 복잡
    3노드 2개 쿼럼 자체 해결, 안정적 서버 3대 필요
    5노드 3개 최고 가용성 비용 높음

    Proxmox HA 클러스터 구축 — 단계별 실전 가이드

    사전 준비 사항

    시작하기 전에 체크해야 할 것들이 있습니다. 저도 처음에 이 부분을 건너뛰었다가 나중에 다 뒤집어엎었던 기억이 있어서요. 꼭 확인하세요.

    • ✅ Proxmox VE가 설치된 서버 최소 3대
    • ✅ 모든 노드에서 시간 동기화(NTP) 설정 완료
    • ✅ 모든 노드 간 네트워크 통신 가능 (핑 테스트)
    • ✅ 각 노드의 호스트명이 고유하고 DNS/hosts 파일에 등록됨
    • ✅ 공유 스토리지 준비 (Ceph, NFS, iSCSI 중 선택)

    Step 1: /etc/hosts 파일 설정

    모든 노드에서 서로를 알아볼 수 있도록 hosts 파일을 설정합니다. DNS가 없는 환경이라면 특히 중요해요.

    # 모든 노드에서 동일하게 설정 (/etc/hosts)
    192.168.1.101  pve-node1  pve-node1.local
    192.168.1.102  pve-node2  pve-node2.local
    192.168.1.103  pve-node3  pve-node3.local

    Step 2: 첫 번째 노드에서 클러스터 생성

    pve-node1에서 클러스터를 만들어 줍니다. 클러스터 이름은 나중에 바꾸기 어려우니 신중하게 정하세요.

    # pve-node1에서 실행
    pvecm create my-ha-cluster
    
    # 생성 확인
    pvecm status

    정상적으로 생성되면 이런 출력이 나옵니다.

    Cluster information
    ------------------
    Name:             my-ha-cluster
    Config Version:   1
    Transport:        knet
    Secauth:          on
    
    Quorum information
    ------------------
    Date:             ...
    Quorum provider:  corosync_votequorum
    Nodes:            1
    Node votes:       1
    Expected votes:   1
    Total votes:      1
    Quorum:           1
    Flags:            Quorate

    Step 3: 나머지 노드를 클러스터에 참가시키기

    pve-node2와 pve-node3에서 각각 실행합니다. 여기서 중요한 점은 기존 노드의 IP를 정확히 입력해야 한다는 거예요.

    # pve-node2에서 실행
    pvecm add 192.168.1.101
    
    # 비밀번호 입력 후 참가 완료
    # pve-node3에서도 동일하게 실행
    pvecm add 192.168.1.101

    참가 후 상태 확인:

    pvecm status
    
    # 출력 예시
    Quorum information
    ------------------
    Nodes:            3
    Expected votes:   3
    Total votes:      3
    Quorum:           2  # 이 숫자가 핵심! 과반수

    Step 4: 공유 스토리지 연결 (NFS 예시)

    Proxmox HA가 동작하려면 VM 디스크가 공유 스토리지에 있어야 합니다. 여기서는 NFS를 예시로 들겠습니다. Ceph를 사용하신다면 별도 구성이 필요한데, 이건 나중에 별도 글로 다룰 예정이에요.

    # 모든 노드에서 NFS 마운트 확인
    showmount -e 192.168.1.200
    
    # Proxmox Web UI에서도 추가 가능하지만 CLI로 하면:
    # /etc/pve/storage.cfg에 추가됨 (클러스터 전체 공유)
    pvesm add nfs shared-storage \
      --server 192.168.1.200 \
      --export /mnt/nfs/proxmox \
      --content images,iso,backup

    ▲ Proxmox Web UI의 HA 관리 화면 — HA 그룹 생성과 리소스 등록 과정을 보여줍니다.

    Step 5: HA 그룹(HA Group) 생성

    HA 그룹은 “이 VM들은 이 노드들에서만 돌아야 해”라는 규칙을 정의합니다. Web UI에서도 가능하지만 CLI가 더 직관적이더라고요.

    # HA 그룹 생성
    ha-manager groupadd production \
      --nodes pve-node1:2,pve-node2:1,pve-node3:1 \
      --restricted 0 \
      --nofailback 0
    
    # 그룹 확인
    ha-manager groupconfig production

    여기서 숫자(2, 1, 1)는 우선순위(Priority)입니다. 숫자가 높을수록 해당 노드를 선호해요. 장애 복구 후 원래 노드로 돌아오는 Failback 기능도 설정 가능합니다.

    Step 6: VM을 HA 리소스로 등록

    이제 특정 VM을 HA 관리 대상으로 등록합니다. VM ID가 100번이라고 가정할게요.

    # VM 100번을 HA 리소스로 추가
    ha-manager add vm:100 \
      --group production \
      --max_restart 3 \
      --max_relocate 3
    
    # 등록된 리소스 확인
    ha-manager status
    # 정상 등록 시 출력 예시
    quorum OK
    master pve-node1 (active, Wed Nov  1 10:00:00 2023)
    
    Active HA resources:
    
      vm:100
               Status: started
               Node: pve-node1
               Managed: 1

    🎉 여기까지 오면 기본 HA 설정은 완료입니다! 이제 테스트를 해볼 차례예요.

    HA 동작 테스트 — 실제로 노드를 죽여보자

    페일오버(Failover) 테스트

    이 부분이 진짜 재미있습니다. 직접 노드를 강제로 다운시켜서 VM이 다른 노드로 이동하는지 확인해 보는 거거든요. 물론 프로덕션에서는 절대 이렇게 하시면 안 되고, 테스트 환경에서만요 ㅎㅎ

    # 방법 1: 노드를 maintenance 모드로 전환 (안전한 방법)
    ha-manager crm-command node-maintenance enable
    
    # 방법 2: pve-node1에서 corosync 서비스 강제 중단 (더 극단적인 테스트)
    systemctl stop corosync
    
    # 다른 노드에서 HA 상태 확인
    ha-manager status
    watch -n 2 ha-manager status  # 2초마다 갱신하며 모니터링

    정상적으로 동작한다면 약 1~2분 내에 VM이 다른 노드에서 기동되는 것을 확인할 수 있습니다. 처음에 드디어 이게 됐을 때 저 혼자 “오오…” 했던 기억이 나네요.

    ⚠️ 트러블슈팅: 제가 직접 겪은 문제들

    문제 1: 클러스터 참가 후 쿼럼이 잡히지 않음

    증상: pvecm status에서 Quorate: No가 표시되고, Web UI에서 “cluster not ready – no quorum” 오류가 나오는 경우입니다.

    원인 대부분은 시간 동기화 문제이거나 방화벽이 포트를 막고 있는 경우였습니다.

    # 시간 동기화 확인
    timedatectl status
    
    # NTP 서비스 재시작
    systemctl restart chrony
    # 또는
    systemctl restart systemd-timesyncd
    
    # Corosync가 사용하는 포트 확인 (UDP 5404, 5405)
    ss -lunp | grep corosync
    
    # 방화벽 규칙 확인 (Proxmox는 기본적으로 iptables 사용)
    iptables -L -n | grep 5404

    문제 2: HA 리소스가 계속 “error” 상태

    이거 저도 한참 고생했습니다. VM이 HA로 등록됐는데 상태가 계속 error로 나오는 경우예요.

    # HA Manager 로그 확인
    journalctl -u pve-ha-lrm -f
    journalctl -u pve-ha-crm -f
    
    # VM 상태 강제 리셋
    ha-manager set vm:100 --state started
    
    # HA 서비스 재시작
    systemctl restart pve-ha-crm
    systemctl restart pve-ha-lrm

    제 경우엔 VM 디스크가 공유 스토리지가 아닌 로컬 스토리지에 있어서 발생한 문제였습니다. HA는 반드시 공유 스토리지에 VM 디스크가 있어야 한다는 걸 다시 한번 강조하고 싶네요.

    문제 3: Fencing(펜싱)이 동작하지 않아 VM 이동이 안 됨

    Fencing이란 죽은 노드가 정말 죽었는지 확인하고, 확실하게 “격리”하는 메커니즘입니다. 이게 없으면 Proxmox HA는 안전을 위해 VM을 다른 노드로 이동시키지 않습니다.

    # Fencing 설정 확인
    cat /etc/pve/datacenter.cfg
    
    # 소프트웨어 watchdog 기반 Fencing 설정 예시
    # datacenter.cfg에 추가
    fencing: watchdog-dbus
    
    # watchdog 상태 확인
    ls /dev/watchdog*
    
    # pve-ha-crm이 watchdog을 사용하는지 확인
    journalctl -u pve-ha-crm | grep watchdog

    💡 팁: 홈랩 환경에서 IPMI 같은 하드웨어 펜싱 장치가 없다면, Proxmox의 소프트웨어 watchdog을 사용할 수 있습니다. 다만 프로덕션 환경에서는 하드웨어 펜싱(IPMI, iLO 등)을 강력히 권장합니다.

    문제 4: 클러스터 노드 중 하나가 “UNKNOWN” 상태

    # 클러스터 노드 상태 확인
    pvecm nodes
    
    # Corosync 링크 상태 확인
    corosync-cfgtool -s
    
    # Corosync 설정 파일 확인
    cat /etc/corosync/corosync.conf
    
    # 문제 노드에서 corosync 재시작
    systemctl restart corosync pve-cluster

    ▲ HA 페일오버 테스트 결과 — 노드 장애 발생 후 VM이 다른 노드로 자동 이동된 것을 확인하는 화면입니다.

    HA 클러스터 운영 시 꼭 알아야 할 설정들

    HA 정책 세부 조정

    # VM의 HA 설정 상세 조회
    ha-manager config vm:100
    
    # max_restart: 같은 노드에서 재시작 시도 횟수
    # max_relocate: 다른 노드로 이동 시도 횟수
    ha-manager set vm:100 --max_restart 3 --max_relocate 2
    
    # 특정 VM을 HA에서 제거 (삭제가 아닌 관리 해제)
    ha-manager remove vm:100

    마이그레이션(Migration) 설정

    HA 환경에서 노드 간 VM 이동 시 네트워크 대역폭 제한도 설정할 수 있습니다. 프로덕션에서는 이게 꽤 중요하더라고요.

    # /etc/pve/datacenter.cfg에서 마이그레이션 설정
    migration: secure
    migration_unsecure: 0
    
    # 또는 CLI로
    pvesh set /cluster/options --migration type=secure

    클러스터 전체 상태 모니터링

    # 전체 클러스터 상태 한눈에 보기
    pvecm status
    ha-manager status
    pct list  # 컨테이너 목록
    qm list   # VM 목록
    
    # 실시간 모니터링
    watch -n 5 'pvecm status && echo "---" && ha-manager status'

    Proxmox HA 구축 완료 — 최종 점검 체크리스트

    설정을 모두 마쳤다면 아래 체크리스트로 최종 확인해 보세요.

    ▲ Proxmox HA 클러스터 구축 완료 체크리스트 — 운영 전 반드시 확인해야 할 항목들을 정리한 요약 인포그래픽입니다.

    ✅ 최종 확인 체크리스트

    1. pvecm status에서 Quorate: Yes 확인
    2. 모든 노드가 Web UI 좌측 트리에 표시됨
    3. 공유 스토리지가 모든 노드에서 접근 가능
    4. HA 그룹이 생성되고 VM이 리소스로 등록됨
    5. ha-manager status에서 VM 상태가 started
    6. Fencing 메커니즘 설정 완료
    7. 실제 페일오버 테스트 완료
    8. NTP 시간 동기화 모든 노드에서 정상

    자주 묻는 질문 (FAQ)

    Q. VM이 HA로 등록되면 항상 공유 스토리지에 있어야 하나요?
    A. 네, 맞습니다. 로컬 스토리지에 있는 VM은 다른 노드로 이동할 수 없기 때문에 HA의 의미가 없습니다. 반드시 공유 스토리지(NFS, Ceph, iSCSI 등)에 VM 디스크를 두어야 합니다.

    Q. Proxmox HA와 일반 Live Migration의 차이는 뭔가요?
    A. Live Migration은 관리자가 수동으로 VM을 다른 노드로 옮기는 것이고, HA Failover는 노드 장애 시 자동으로 VM을 다른 노드에서 재시작하는 것입니다. 라이브 마이그레이션은 무중단이지만, HA 페일오버는 VM이 재시작되는 시간만큼의 다운타임이 발생합니다.

    Q. 2노드 구성으로도 HA를 쓸 수 있나요?
    A. 가능하지만 QDevice(쿼럼 장치)가 추가로 필요합니다. Raspberry Pi 같은 소형 장치에 corosync-qnetd를 설치해서 쿼럼 역할을 맡길 수 있습니다.

    마무리: 서버실에서 배운 것

    Proxmox HA 클러스터를 처음 구축했을 때, 노드 하나를 강제로 죽이고 VM이 다른 노드에서 자동으로 살아나는 걸 보면서 진짜 뿌듯했습니다. 13년 동안 인프라 일하면서 이런 순간들이 있거든요. 기술이 의도한 대로 딱 작동하는 그 순간.

    물론 처음엔 쿼럼 개념도 헷갈리고, 펜싱 설정 때문에 VM이 안 옮겨가서 한참 삽질도 했습니다. 하지만 그 과정을 통해서 HA의 원리를 제대로 이해하게 된 것 같아요.

    핵심을 정리하면:

    • 최소 3노드로 구성해서 쿼럼을 확보하세요
    • VM 디스크는 반드시 공유 스토리지에
    • Fencing 설정을 빠뜨리지 마세요 — 없으면 HA가 안전 때문에 동작을 안 합니다
    • 설정 후 반드시 실제 페일오버 테스트를 해보세요

    다음 글에서는 Proxmox에서 Ceph 분산 스토리지를 구축하는 방법을 다룰 예정입니다. 공유 스토리지로 외부 NAS 없이 Proxmox 노드들 자체로 고가용성 스토리지를 만드는 내용인데요, HA와 함께 쓰면 정말 강력한 홈랩 환경이 만들어집니다. 기대해 주세요!

    질문이나 다른 삽질 경험 있으신 분들은 댓글로 공유해 주세요. 저도 아직 배우는 중이라 같이 이야기 나눠보면 좋을 것 같습니다 😊

  • [Proxmox] Proxmox HA 클러스터: 고가용성 구축 및 장애 복구 전략

    [Proxmox] Proxmox HA 클러스터: 고가용성 구축 및 장애 복구 전략

    13년차 인프라 엔지니어의 Proxmox HA 클러스터 구축 삽질기

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 Proxmox HA 클러스터(High Availability Cluster, 고가용성 클러스터) 구축 경험담을 풀어보려고 합니다. 인프라 엔지니어에게 고가용성(HA)은 마치 공기와도 같죠. 서비스가 멈추지 않고 항상 돌아가도록 하는 것, 그게 바로 저희의 숙명이잖아요?

    저도 처음에는 단순히 서버 한 대에 가상 머신(VM) 몇 개 돌리는 것으로 시작했습니다. 그런데 어느 날 갑자기 서버가 뻗는 경험을 몇 번 하고 나니, ‘아, 이러면 안 되겠다!’ 싶더라고요. 특히 홈랩(Homelab)에서 이것저것 실험하다 보면 예기치 않은 장애가 자주 발생하거든요. 그래서 장애 복구(Disaster Recovery)는 물론이고, 장애 발생 시에도 서비스가 멈추지 않도록 자동으로 복구(Automatic Failover)되는 시스템이 절실해졌습니다. 그때 제 눈에 들어온 것이 바로 Proxmox HA 클러스터였습니다.

    Proxmox VE(Virtual Environment)는 오픈소스 가상화 플랫폼으로, 클러스터(Cluster) 기능을 제공해서 여러 대의 서버를 하나로 묶을 수 있어요. 여기에 HA(High Availability) 기능을 추가하면, 특정 노드(Node)에 문제가 생겨도 그 위에서 돌아가던 가상 머신이나 컨테이너(LXC)가 다른 살아있는 노드로 자동으로 이동해서 계속 서비스를 이어나갈 수 있습니다. 이거 정말 매력적이지 않나요? 덕분에 저도 밤에 편안하게 잘 수 있게 됐습니다. 🥳

    Proxmox HA 클러스터의 기본적인 아키텍처를 보여주는 다이어그램입니다. 여러 노드가 Corosync 네트워크로 연결되어 있고, 공유 스토리지에서 VM 디스크를 사용하며, HA 매니저가 가상 머신들을 관리하는 모습을 나타냅니다.

    Proxmox HA, 그게 뭔데요? (핵심 개념 설명)

    Proxmox HA 클러스터를 이해하기 위해 몇 가지 핵심 개념을 짚고 넘어가야 합니다. 제가 처음 접했을 때 헷갈렸던 부분들이거든요.

    • Proxmox VE (PVE): Debian 기반의 오픈소스 가상화 플랫폼입니다. KVM(Kernel-based Virtual Machine)과 LXC(Linux Containers)를 지원하죠.
    • 클러스터(Cluster): 여러 대의 Proxmox 서버(노드)를 하나의 그룹으로 묶어주는 기능이거든요. 이렇게 하면 중앙 집중식으로 관리할 수 있고, 자원도 공유하며 HA 구성의 기반이 돼요.
    • HA (High Availability, 고가용성): 이게 오늘의 주인공이죠! 클러스터 내의 특정 노드에 하드웨어 장애나 소프트웨어 문제가 발생했을 때, 해당 노드에서 실행 중이던 VM이나 LXC를 자동으로 다른 정상 노드로 옮겨서 서비스 중단을 최소화하는 기능입니다.
    • Corosync (코로싱크): 클러스터 노드들이 서로 통신하게 해주는 핵심 메커니즘이거든요. 클러스터 노드 간의 상태 정보를 주고받고, 노드 실패를 감지하며, 쿼럼(Quorum)을 관리하는 역할을 합니다. 클러스터 노드들이 서로 살아있는지 확인하는 ‘심장 박동(Heartbeat)’ 같은 거죠.
    • 쿼럼(Quorum): 클러스터가 의사결정하는 방식이에요. 스플릿 브레인(Split-Brain) 현상을 방지하기 위해, 클러스터 노드 중 과반수 이상이 정상적으로 통신해야만 클러스터가 정상 작동한다고 판단합니다. 예를 들어 3노드 클러스터에서는 최소 2노드가 살아있어야 쿼럼이 유지됩니다. 💡 팁: 그래서 노드 개수는 3개, 5개처럼 홀수(Odd Number)로 구성하는 것이 일반적입니다.

    쉽게 말해, Proxmox HA는 여러 대의 Proxmox 서버를 끈끈하게 엮어서, 한 대가 쓰러져도 나머지 서버들이 재빨리 그 업무를 이어받아 서비스가 끊기지 않도록 하는 마법 같은 기능이라고 할 수 있습니다. 물론 마법을 부리려면 몇 가지 준비물이 필요하죠!

    실전! Proxmox HA 클러스터 구축 단계별 가이드

    자, 이제 저와 함께 Proxmox HA 클러스터를 직접 구축해봅시다. 제가 홈랩에서 삽질하며 얻은 노하우를 아낌없이 풀어드릴게요!

    1단계: Proxmox VE 노드 준비

    클러스터를 구성하려면 최소 2대 이상의 Proxmox VE가 설치된 서버가 필요합니다. 하지만 위에서 말씀드렸듯이, 안정적인 HA를 위해서는 3대 이상의 노드를 준비하는 것을 강력히 추천합니다. 모든 노드는 동일한 Proxmox VE 버전으로 설치하는 것이 좋습니다.

    • 네트워크 설정: 각 노드에는 안정적인 네트워크 연결이 필수입니다. 가능하면 Corosync 통신을 위한 별도의 네트워크 인터페이스(NIC)를 구성하는 것이 좋습니다.
    • SSH 연결: 각 노드에 SSH로 접근할 수 있는지 미리 확인해주세요.

    2단계: 클러스터 생성 및 노드 추가

    가장 먼저 클러스터를 생성하고, 다른 노드들을 여기에 추가해야 합니다. 저는 주로 CLI(Command Line Interface)를 선호하는데, 웹 UI에서도 가능합니다.

    1. 첫 번째 노드에서 클러스터 생성:
    2. pvecm create <클러스터_이름>
      # 예시: pvecm create my-ha-cluster

      이 명령어를 실행하면 첫 번째 노드가 클러스터의 리더가 됩니다.

    3. 두 번째 노드부터 클러스터에 추가:
    4. 각 추가할 노드에서 다음 명령어를 실행합니다. `<첫_번째_노드_IP>`는 클러스터를 생성한 첫 번째 노드의 IP 주소입니다.

      pvecm add <첫_번째_노드_IP>
      # 예시: pvecm add 192.168.1.100

      이때 첫 번째 노드의 root 비밀번호를 입력하라고 나옵니다. 성공적으로 추가되면 모든 노드가 동일한 클러스터에 속하게 됩니다.

    5. 클러스터 상태 확인:
    6. 어떤 노드에서든 다음 명령어를 실행하여 클러스터 상태를 확인합니다.

      pvecm status

      모든 노드가 ‘Online’ 상태이고, ‘Quorum’이 ‘active’로 표시되면 성공입니다! 🎉

    Proxmox 웹 UI에서 클러스터 노드와 쿼럼 상태를 확인하는 화면

    Proxmox 웹 UI에서 클러스터 노드들의 목록과 상태를 보여주는 화면입니다. 각 노드의 ‘Status’가 ‘online’으로 표시되어 있고, ‘Quorum’이 정상적으로 작동하는 것을 확인할 수 있습니다.

    3단계: 공유 스토리지 설정 (NFS 또는 Ceph)

    HA를 제대로 활용하려면 공유 스토리지(Shared Storage)가 필수입니다. 왜냐하면 노드에 장애가 발생했을 때, 다른 노드에서 장애가 난 VM의 디스크 이미지를 바로 이어서 사용할 수 있어야 하거든요. NFS(Network File System)나 Ceph(분산 스토리지)가 대표적인데요, 저는 홈랩에서 NFS를 많이 썼고, 규모가 커지면 Ceph를 고려해보는 편입니다.

    여기서는 간단하게 NFS 스토리지를 추가하는 방법을 예시로 들어볼게요. (NFS 서버는 별도로 구축되어 있다고 가정합니다.)

    1. Proxmox 웹 UI 접속:
    2. Datacenter -> Storage -> Add -> NFS 선택.

    3. NFS 설정 정보 입력:
      • ID: 스토리지 이름 (예: nfs-share)
      • Server: NFS 서버 IP 주소
      • Export: NFS 서버의 공유 경로 (예: /mnt/nfs_data)
      • Content: Disk image, Container template 등을 선택

      이렇게 설정하면 클러스터의 모든 노드가 이 NFS 스토리지를 공유하게 됩니다. 이제 VM을 생성할 때 이 공유 스토리지를 선택하면 HA 구성 준비가 거의 끝난 겁니다!

    4단계: HA 그룹 및 자원 설정

    이제 어떤 VM이나 LXC를 HA의 보호 아래 둘지 결정하고 설정해야 합니다.

    1. HA 그룹 생성 (선택 사항):
    2. Datacenter -> HA -> Groups 탭에서 HA 그룹을 만들 수 있습니다. 특정 노드에만 VM이 배치되도록 하거나, 특정 순서로 배치되도록 하는 등의 정책을 설정할 수 있어요. 저는 보통 기본 그룹을 사용하지만, 복잡한 환경에서는 유용합니다.

    3. VM/LXC에 HA 정책 적용:
    4. HA를 적용할 VM 또는 LXC를 선택하고, 왼쪽 메뉴에서 HA 탭을 클릭합니다. 여기서 Add 버튼을 눌러 HA 자원으로 추가합니다.

      • Policy (정책):
        • started: 노드가 다운되면 다른 노드에서 자동으로 시작합니다. (가장 일반적)
        • stopped: 노드가 다운되어도 자동으로 시작하지 않습니다.
        • relocatable: 수동으로 다른 노드로 옮길 수 있습니다.

        저는 대부분 started 정책을 사용합니다. 이게 바로 HA의 핵심이거든요!

      웹 UI로도 쉽게 설정할 수 있으며, Datacenter -> HA -> Resources 탭에서 현재 HA 자원들의 상태를 확인할 수 있습니다.

    ⚠️ 삽질 경험담: 쿼럼, 네트워크, 그리고 스플릿 브레인

    제가 Proxmox HA를 구축하면서 가장 많이 겪었던 문제들은 바로 쿼럼, 네트워크, 그리고 스플릿 브레인이었습니다. 독자분들은 저처럼 삽질하지 않으시길 바라며 제 경험을 공유합니다.

    쿼럼(Quorum) 깨짐 문제

    가장 흔한 문제 중 하나입니다. 예를 들어 3노드 클러스터에서 2대가 동시에 다운되면 쿼럼이 깨집니다. 쿼럼이 깨지면 클러스터는 더 이상 의사결정을 할 수 없게 되고, HA 기능도 작동하지 않습니다. VM들이 제자리에 멈춰버리는 거죠. 😱

    • 해결책:
      • 항상 노드 개수를 홀수로 유지하세요. (최소 3개, 이상적으로는 5개)
      • 노드 복구 후 pvecm status로 쿼럼 상태를 확인합니다.
      • 만약 한 노드만 영구적으로 손상되어 제거해야 한다면, pvecm delnode <노드_이름> 명령어를 사용하여 클러스터에서 안전하게 제거해야 합니다.
      • 2노드 클러스터의 경우 QDevice (큐디바이스)를 설정하여 쿼럼 안정성을 높일 수 있습니다. QDevice는 클러스터 외부에 있는 경량 프로세스로, 쿼럼 투표권을 하나 더 제공해서 2노드 클러스터에서 한 노드가 죽어도 쿼럼이 깨지지 않도록 도와줍니다.

    네트워크 이중화의 중요성

    Corosync는 네트워크를 통해 통신합니다. 만약 Corosync 네트워크에 문제가 생기면, 노드들은 서로 통신할 수 없게 되고, 살아있는 노드도 죽은 노드로 오인할 수 있습니다. 제가 실제로 겪었던 일인데, 네트워크 케이블 하나가 불량이라 클러스터가 오락가락했던 적이 있었죠… 하하.

    • 해결책:
      • 가능하다면 Corosync 통신을 위한 별도의 네트워크 인터페이스(NIC)를 구성하거나, 링크 어그리게이션(Link Aggregation, 본딩)을 통해 네트워크 이중화를 구성하는 것이 좋습니다.
      • /etc/pve/corosync.conf 파일을 수정하여 두 개의 링(Ring)을 구성할 수도 있습니다.

    스플릿 브레인(Split-Brain) 방지

    스플릿 브레인은 클러스터가 두 개 이상의 독립적인 그룹으로 나뉘어 서로 자신이 진짜라고 생각하고 동작하는 심각한 상황입니다. 예를 들어, 네트워크 문제로 노드 1과 노드 2, 3이 분리되었을 때, 노드 1이 VM을 시작하고 동시에 노드 2, 3이 또 다른 VM을 시작하려고 시도하면 데이터 손상이 발생할 수 있습니다.

    • 해결책:
      • 쿼럼 규칙이 스플릿 브레인을 방지하는 기본적인 메커니즘이지만, 완벽하지 않을 수 있습니다.
      • STONITH (Shoot The Other Node In The Head) 또는 펜싱(Fencing)이라는 개념이 있습니다. 문제가 생긴 노드의 전원을 강제로 차단하여, 해당 노드가 더 이상 클러스터 자원을 사용하지 못하게 하는 방법입니다. Proxmox 자체적으로는 QDevice를 통해 쿼럼을 강화하거나, 외부 펜싱 장비(예: IPMI를 이용한 전원 제어)를 통합하여 사용할 수 있습니다. 홈랩에서는 복잡할 수 있지만, 프로덕션 환경에서는 필수적인 요소입니다.

    제대로 동작하는지 확인해봐야죠! (장애 복구 검증)

    수고해서 클러스터를 구축했으니, 이제 정말 잘 작동하는지 확인해봐야겠죠? 저는 이 순간이 제일 두근거리더라고요. 제가 직접 해보니 가장 확실한 방법은 강제로 노드를 종료시켜보는 겁니다.

    1. HA가 설정된 VM 또는 LXC 확인:
    2. HA 정책이 ‘started’로 설정된 VM이나 LXC가 특정 노드에서 실행 중인지 확인합니다.

    3. 해당 노드 강제 종료:
    4. 해당 노드의 전원 버튼을 길게 누르거나, SSH로 접속하여 poweroff -f 명령어로 강제 종료합니다. (경고: 운영 중인 중요한 서비스에서는 절대 이렇게 하지 마세요! 테스트 환경에서만 시도해야 합니다.)

    5. HA 동작 확인:
    6. 다른 Proxmox 노드의 웹 UI나 pve-ha-manager status 명령어를 통해 해당 VM/LXC가 자동으로 다른 노드로 마이그레이션(Migration)되어 시작되는지 확인합니다. 몇 초에서 몇 분 정도 걸릴 수 있습니다.

      pve-ha-manager status

      성공적으로 다른 노드에서 VM이 ‘running’ 상태로 바뀌면 드디어 성공입니다! 🎉 이 순간의 쾌감은 이루 말할 수 없죠. 제가 밤새 삽질했던 보람을 느끼는 순간입니다.

    Proxmox HA 장애 복구 후 가상 머신이 다른 노드에서 정상 작동하는 대시보드 화면

    Proxmox 웹 UI 대시보드에서 장애가 발생했던 노드의 VM이 다른 노드로 성공적으로 마이그레이션되어 정상 작동 중인 상태를 보여주는 스크린샷입니다. VM의 ‘Status’가 ‘running’으로 표시됩니다.

    Proxmox HA 클러스터, 현명하게 사용하는 팁

    HA 클러스터를 구축했다고 해서 모든 것이 끝나는 건 아닙니다. 더 안정적이고 효율적으로 사용하기 위한 몇 가지 팁을 드릴게요.

    • 백업 전략 수립: HA는 장애 시 서비스를 유지하는 것이지, 데이터 손실을 막아주지는 않습니다. Proxmox Backup Server (PBS)를 이용하거나, 다른 백업 솔루션을 반드시 함께 운영해야 합니다. 제가 예전에 백업을 소홀히 했다가 피눈물을 흘린 적이 있거든요… 😭
    • 모니터링 시스템 구축: 클러스터의 상태, 각 노드의 자원 사용량, VM의 상태 등을 실시간으로 모니터링해야 합니다. Prometheus + Grafana 조합은 홈랩에서도 충분히 활용할 수 있는 강력한 모니터링 툴입니다.
    • 공유 스토리지의 중요성: HA의 성능과 안정성은 공유 스토리지에 크게 의존합니다. NFS 서버의 성능이 떨어지거나 네트워크 대역폭이 부족하면, VM 마이그레이션 시 병목 현상이 발생할 수 있습니다. Ceph와 같은 분산 스토리지는 더 높은 성능과 안정성을 제공하지만, 그만큼 구축과 관리가 복잡하다는 점을 염두에 두세요.
    • 정기적인 테스트: ‘설마’ 하는 마음으로 테스트를 미루다가 실제 장애가 발생했을 때 제대로 작동하지 않는 경우가 있습니다. 주기적으로 HA 기능을 테스트하여 항상 준비된 상태를 유지해야 합니다.
    Proxmox HA 클러스터의 장점과 단점을 비교한 인포그래픽

    Proxmox HA 클러스터의 주요 장점과 고려해야 할 단점들을 시각적으로 비교 정리한 인포그래픽입니다. 고가용성, 중앙 관리 등의 장점과 복잡성, 공유 스토리지 의존성 등의 단점을 간략하게 보여줍니다.

    마무리하며: 안정적인 인프라의 시작

    오늘은 Proxmox HA 클러스터 구축부터 제가 겪었던 삽질 경험, 그리고 검증 방법까지 자세히 이야기해봤습니다. 처음에는 쿼럼이니 스플릿 브레인이니 하는 개념들이 어렵게 느껴졌지만, 직접 부딪혀보고 해결하는 과정을 통해 정말 많은 것을 배웠습니다.

    Proxmox HA는 홈랩 사용자부터 중소기업 환경까지, 안정적인 인프라를 구축하고자 하는 분들에게 정말 좋은 솔루션이라고 생각합니다. 물론 완벽한 시스템은 없지만, HA를 통해 서비스 중단 시간을 최소화하고, 장애 발생 시에도 빠르게 복구할 수 있는 기반을 마련할 수 있습니다.

    여러분의 소중한 서비스, Proxmox HA 클러스터로 든든하게 지켜보시는 건 어떨까요? 이 글이 여러분의 인프라 구축 여정에 작은 도움이 되었기를 바랍니다. 다음번에는 Proxmox Backup Server나 Ceph 스토리지 구축에 대한 이야기를 들고 오겠습니다. 그때까지 모두 안정적인 서버실 되시길! 감사합니다. 👋

  • [Proxmox] VE 8.2 네트워크 고급 설정: VLAN, 브릿지, nftables 방화벽 완벽 가이드

    홈랩 네트워크, 이대로 괜찮은가요?

    솔직히 말씀드리면, 저도 처음엔 Proxmox VE를 설치하고 그냥 기본 브릿지 하나에 VM 다 때려넣고 썼거든요. “뭐, 집에서 쓰는 건데 보안이 무슨 상관이야” 싶었죠. 근데 어느 날 홈랩에서 돌리던 개발용 컨테이너 하나가 이상한 트래픽을 뿜는 걸 발견했을 때… 그때부터 제대로 네트워크를 나눠야겠다는 생각이 들었습니다.

    Proxmox 네트워크 설정을 제대로 이해하면 VM/컨테이너별로 네트워크를 격리하고, 불필요한 트래픽을 차단하고, 관리 인터페이스를 보호할 수 있어요. 오늘은 Proxmox VE 8.2 기준으로 VLAN 설정, 브릿지 구성, 그리고 nftables 방화벽까지 한 번에 정리해 드릴게요. 꽤 긴 글이 될 것 같지만, 차근차근 따라오시면 충분히 이해하실 수 있을 겁니다.

    ▲ 오늘 구성할 Proxmox 네트워크 전체 구조입니다. VLAN별로 트래픽을 분리하고 nftables로 방화벽 규칙을 적용하는 흐름을 한눈에 볼 수 있어요.

    Proxmox 네트워크 핵심 개념 먼저 짚고 가기

    설정 들어가기 전에 개념을 잡아두는 게 중요해요. 저도 처음엔 브릿지랑 본드(Bond)랑 VLAN이 뭐가 다른지 헷갈려서 삽질을 꽤 했거든요.

    Linux Bridge(리눅스 브릿지)란?

    쉽게 말해, 소프트웨어로 만든 스위치입니다. Proxmox에서 VM이나 컨테이너를 만들면 각각의 가상 NIC(네트워크 인터페이스 카드)가 이 브릿지에 연결되는 구조예요. 물리 스위치의 포트처럼 동작한다고 보시면 됩니다.

    VLAN(Virtual LAN, 가상 로컬 네트워크)이란?

    하나의 물리 네트워크를 논리적으로 분리하는 기술이에요. 예를 들어 관리용 VM, 개발용 VM, IoT 장비를 같은 물리 스위치에 연결해도 VLAN ID로 완전히 다른 네트워크처럼 동작하게 만들 수 있습니다. Proxmox 8.2에서는 VLAN-aware bridge(VLAN 인식 브릿지) 방식을 권장하고 있어요.

    nftables란?

    기존 iptables를 대체하는 리눅스 방화벽 프레임워크입니다. Proxmox VE 7.x 이후부터 내부적으로 nftables를 사용하고 있고, 8.x에서는 더 완성도 있게 통합됐어요. 문법이 처음엔 낯설지만, 익숙해지면 iptables보다 훨씬 직관적이더라고요.

    구성 요소 역할 비고
    Linux Bridge VM/CT 간 L2 연결 (소프트웨어 스위치) vmbr0, vmbr1 등으로 명명
    VLAN 논리적 네트워크 분리 (태그 기반) 802.1Q 표준, ID 1~4094
    Bond 물리 NIC 이중화 / 대역폭 확장 active-backup, LACP 등
    nftables 호스트 및 VM 트래픽 방화벽 iptables 대체, Proxmox 통합

    Proxmox VLAN 설정: VLAN-aware Bridge 구성하기

    이제 본격적으로 설정을 시작해 볼게요. 제가 실제로 운영 중인 홈랩 구성을 기반으로 설명드리겠습니다.

    시나리오 설명

    • VLAN 10: 관리 네트워크 (Proxmox 관리 인터페이스, 네트워크 장비)
    • VLAN 20: 서버 네트워크 (웹서버, DB 등 서비스 VM)
    • VLAN 30: 개발/테스트 네트워크 (개발 VM, 컨테이너)
    • VLAN 99: IoT/비신뢰 네트워크 (외부 접근 허용 최소화)

    1단계: /etc/network/interfaces 설정

    Proxmox의 네트워크 설정은 /etc/network/interfaces 파일로 관리됩니다. GUI에서도 설정할 수 있지만, 파일을 직접 편집하는 게 더 정확하고 빠르더라고요.

    # 기존 설정 백업 먼저!
    cp /etc/network/interfaces /etc/network/interfaces.bak
    
    # 편집
    nano /etc/network/interfaces

    아래 내용으로 설정합니다. 물리 NIC 이름은 환경마다 다를 수 있으니 ip link show로 먼저 확인하세요.

    auto lo
    iface lo inet loopback
    
    # 물리 NIC (업스트림 스위치와 연결되는 트렁크 포트)
    auto enp3s0
    iface enp3s0 inet manual
    
    # VLAN-aware Bridge (VLAN 인식 브릿지)
    auto vmbr0
    iface vmbr0 inet static
        address 192.168.10.100/24      # VLAN 10 (관리망) IP
        gateway 192.168.10.1
        bridge-ports enp3s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes          # 핵심! VLAN 인식 활성화
        bridge-vids 2-4094             # 허용할 VLAN ID 범위
    
    # VLAN 인터페이스 (호스트가 각 VLAN에 직접 접근할 때 필요)
    auto vmbr0.20
    iface vmbr0.20 inet static
        address 192.168.20.1/24
    
    auto vmbr0.30
    iface vmbr0.30 inet static
        address 192.168.30.1/24
    
    auto vmbr0.99
    iface vmbr0.99 inet static
        address 192.168.99.1/24

    ⚠️ 중요! bridge-vlan-aware yes를 설정하면 기존에 VLAN 없이 연결된 VM들이 통신이 끊길 수 있어요. 반드시 각 VM의 네트워크 설정에서 VLAN 태그를 지정해 줘야 합니다.

    2단계: 설정 적용

    # 네트워크 재시작 (원격 접속 중이라면 주의!)
    ifreload -a
    
    # 또는 재부팅
    reboot

    💡 팁: 원격으로 작업 중이라면 ifreload -a가 더 안전합니다. 그래도 혹시 모르니 콘솔 접근이 가능한 상태에서 작업하는 걸 강력 추천드려요. 저도 한 번 원격이 끊겨서 IDC까지 달려간 적 있거든요.

    3단계: VM에 VLAN 태그 설정

    VM 설정에서 네트워크 장치를 추가할 때 VLAN Tag를 지정합니다.

    # CLI로 VM 네트워크 설정 변경 (VM ID 101, VLAN 20 할당)
    qm set 101 --net0 virtio,bridge=vmbr0,tag=20
    
    # 컨테이너(LXC)의 경우
    pct set 201 --net0 name=eth0,bridge=vmbr0,tag=30,ip=192.168.30.10/24,gw=192.168.30.1

    ▲ Proxmox GUI에서 VM 네트워크 설정 시 VLAN Tag 항목에 VLAN ID를 입력하면 됩니다. bridge-vlan-aware 설정이 되어 있어야 이 옵션이 동작해요.

    Proxmox 브릿지 고급 설정: 다중 브릿지 구성

    VLAN-aware 브릿지 하나로 대부분 해결되지만, 경우에 따라 브릿지를 여러 개 나누는 게 더 나을 때도 있어요. 예를 들어 완전히 격리된 내부 네트워크(외부 연결 없는 NAT 망)가 필요할 때죠.

    NAT 브릿지 추가 (인터넷 연결 없는 격리망)

    # /etc/network/interfaces에 추가
    auto vmbr1
    iface vmbr1 inet static
        address 10.10.10.1/24
        bridge-ports none              # 물리 NIC 없음 = 완전 격리
        bridge-stp off
        bridge-fd 0
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE

    이렇게 하면 vmbr1에 연결된 VM들은 인터넷은 되지만(NAT를 통해), 외부에서 직접 접근은 불가능한 구조가 됩니다. 개발/테스트 환경에 딱이에요.

    nftables 방화벽 설정: Proxmox 방화벽 제대로 활용하기

    자, 이제 핵심 중의 핵심입니다. Proxmox 방화벽 설정인데요, 사실 Proxmox에는 GUI 기반의 자체 방화벽 기능이 있고, 이게 내부적으로 nftables를 사용해요. 두 가지 방법을 모두 알아두는 게 좋습니다.

    방법 1: Proxmox 내장 방화벽 (GUI/설정 파일)

    Proxmox 방화벽은 세 가지 레벨로 동작합니다.

    1. Datacenter 레벨: 클러스터 전체에 적용되는 공통 규칙 (/etc/pve/firewall/cluster.fw)
    2. Host 레벨: Proxmox 호스트 자체에 적용 (/etc/pve/nodes/[노드명]/host.fw)
    3. VM/CT 레벨: 개별 가상머신/컨테이너에 적용 (/etc/pve/firewall/[VMID].fw)

    Proxmox 방화벽 활성화

    # 방화벽 설정 파일 위치 확인
    ls /etc/pve/firewall/
    
    # 클러스터 방화벽 설정
    cat /etc/pve/firewall/cluster.fw

    GUI에서는 Datacenter → Firewall → Options에서 Enable을 체크하면 됩니다. 호스트별로도 같은 방법으로 활성화할 수 있어요.

    방화벽 규칙 파일 직접 편집

    # /etc/pve/firewall/cluster.fw 예시
    [OPTIONS]
    enable: 1
    policy_in: DROP      # 기본 인바운드 정책: 차단
    policy_out: ACCEPT   # 기본 아웃바운드 정책: 허용
    
    [RULES]
    # Proxmox 웹 GUI 접근 (관리망에서만)
    IN ACCEPT -source 192.168.10.0/24 -p tcp --dport 8006 -log warning
    # SSH 접근 (관리망에서만)
    IN ACCEPT -source 192.168.10.0/24 -p tcp --dport 22 -log warning
    # ICMP (ping) 허용
    IN ACCEPT -p icmp
    # 이미 맺어진 연결 허용
    IN ACCEPT -m conntrack --ctstate RELATED,ESTABLISHED

    방법 2: nftables 직접 설정 (고급 사용자용)

    Proxmox 내장 방화벽으로 커버 안 되는 복잡한 규칙이 필요할 때는 nftables를 직접 건드려야 합니다. 근데 여기서 주의할 점! Proxmox가 자체 방화벽을 관리하기 때문에, 직접 nftables 규칙을 추가하면 충돌이 날 수 있어요.

    그래서 권장하는 방법은 custom nftables 설정 파일을 별도로 만드는 겁니다.

    # /etc/nftables.conf 에 커스텀 규칙 추가
    nano /etc/nftables.conf
    #!/usr/sbin/nft -f
    
    # 기존 규칙 초기화
    flush ruleset
    
    table inet filter {
        # 체인(chain): 패킷 처리 흐름 정의
        chain input {
            type filter hook input priority 0; policy drop;
    
            # 루프백 인터페이스 허용
            iif lo accept
    
            # 이미 맺어진 연결 및 관련 트래픽 허용
            ct state established,related accept
    
            # ICMP 허용 (ping 등)
            ip protocol icmp accept
            ip6 nexthdr icmpv6 accept
    
            # 관리망(VLAN 10)에서 SSH 허용
            iifname "vmbr0.10" tcp dport 22 accept
    
            # 관리망에서 Proxmox 웹 GUI 허용
            iifname "vmbr0.10" tcp dport 8006 accept
    
            # 나머지는 로그 남기고 차단
            log prefix "[nft-drop] " limit rate 5/minute
            drop
        }
    
        chain forward {
            type filter hook forward priority 0; policy drop;
    
            # 이미 맺어진 연결 허용
            ct state established,related accept
    
            # VLAN 20 (서버망) → 인터넷 허용
            iifname "vmbr0.20" oifname "vmbr0" accept
    
            # VLAN 30 (개발망) → 인터넷 허용
            iifname "vmbr0.30" oifname "vmbr0" accept
    
            # VLAN 간 통신 차단 (보안 격리)
            # 개발망 → 서버망 차단
            iifname "vmbr0.30" oifname "vmbr0.20" drop
    
            # IoT망 → 다른 VLAN 차단
            iifname "vmbr0.99" drop
        }
    
        chain output {
            type filter hook output priority 0; policy accept;
        }
    }
    
    # NAT 테이블 (vmbr1 사용 시)
    table ip nat {
        chain postrouting {
            type nat hook postrouting priority 100;
            oifname "vmbr0" masquerade
        }
    }
    # nftables 서비스 활성화 및 시작
    systemctl enable nftables
    systemctl start nftables
    
    # 규칙 적용 확인
    nft list ruleset
    
    # 특정 테이블만 확인
    nft list table inet filter

    ⚠️ 경고: Proxmox 내장 방화벽과 nftables를 동시에 사용하면 규칙이 충돌할 수 있습니다. 둘 중 하나만 선택하거나, Proxmox 방화벽을 비활성화한 후 nftables를 직접 관리하는 방식을 권장합니다. 저는 단순한 환경에서는 Proxmox 내장 방화벽만 쓰고, 복잡한 규칙이 필요할 때는 nftables 직접 설정을 사용하고 있어요.

    ▲ nftables 방화벽 규칙을 적용했을 때 VLAN 간 트래픽 허용/차단 흐름입니다. IoT망(VLAN 99)은 다른 VLAN으로의 접근이 완전히 차단됩니다.

    ⚠️ 트러블슈팅: 실제로 겪은 문제들

    설정하다 보면 분명히 막히는 부분이 생기거든요. 제가 겪은 것들 공유합니다.

    문제 1: VLAN 설정 후 VM 네트워크 먹통

    증상: bridge-vlan-aware 활성화 후 기존 VM들이 네트워크가 안 됨

    원인: VLAN-aware 브릿지에서는 VLAN 태그가 없는 트래픽이 기본적으로 차단됩니다.

    해결: 각 VM 네트워크 설정에 VLAN 태그를 추가하거나, 태그 없이 쓰고 싶다면 bridge-pvid(포트 VLAN ID)를 설정하세요.

    # 특정 브릿지 포트의 PVID 확인
    bridge vlan show
    
    # VM 포트에 PVID 설정 (태그 없는 트래픽을 VLAN 20으로)
    bridge vlan add dev vmbr0 vid 20 pvid untagged

    문제 2: nftables 규칙 적용 후 Proxmox GUI 접근 불가

    증상: nftables 설정 후 8006 포트로 접근이 안 됨

    원인: input 체인의 기본 정책이 drop인데, 8006 포트 허용 규칙이 잘못된 인터페이스에 적용됨

    해결: 인터페이스 이름을 ip link show로 정확히 확인하고, 임시로 모든 8006 트래픽을 허용한 뒤 규칙을 다듬으세요.

    # 임시로 8006 전체 허용 (디버깅용)
    nft add rule inet filter input tcp dport 8006 accept
    
    # 현재 적용된 규칙 확인
    nft list chain inet filter input
    
    # 인터페이스 이름 확인
    ip link show | grep -E "^[0-9]+:"
    bridge vlan show

    문제 3: VM 간 통신이 방화벽 규칙과 무관하게 됨

    증상: forward 체인에서 차단했는데 VM끼리 통신이 됨

    원인: 같은 브릿지 내 VM 간 트래픽은 L2(2계층)에서 바로 처리되어 forward 체인을 거치지 않을 수 있음

    해결: 브릿지에서 nf_call_iptables(또는 nftables)를 활성화해야 합니다.

    # 브릿지 트래픽이 netfilter를 통과하도록 설정
    echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
    echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
    
    # 영구 적용 (/etc/sysctl.conf)
    echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
    echo "net.bridge.bridge-nf-call-ip6tables = 1" >> /etc/sysctl.conf
    sysctl -p

    ✅ 설정 검증: 제대로 됐는지 확인하기

    설정을 다 했으면 검증이 필수입니다. “됐겠지”하고 넘어갔다가 나중에 보안 구멍 발견하면 더 힘들거든요.

    VLAN 설정 검증

    # 브릿지 VLAN 상태 확인
    bridge vlan show
    
    # 예상 출력:
    # port    vlan ids
    # vmbr0    1 PVID Egress Untagged
    #          10
    #          20
    #          30
    #          99
    
    # 각 VLAN 인터페이스 IP 확인
    ip addr show vmbr0.20
    ip addr show vmbr0.30
    
    # VLAN 10 (관리망) VM에서 VLAN 20 (서버망) VM으로 ping 테스트
    # 허용된 경로라면 응답이 와야 함
    ping -c 4 192.168.20.10

    방화벽 규칙 검증

    # 현재 nftables 규칙 전체 출력
    nft list ruleset
    
    # 패킷 카운터 확인 (규칙이 실제로 매칭되는지)
    nft list ruleset | grep -A2 "counter"
    
    # 로그 확인 (차단된 패킷)
    journalctl -f | grep "nft-drop"
    
    # 특정 포트 접근 테스트
    nc -zv 192.168.10.100 8006   # 성공해야 함
    nc -zv 192.168.10.100 22     # 성공해야 함
    nc -zv 192.168.10.100 80     # 차단되어야 함 (규칙 없으면)

    VLAN 간 격리 검증

    # IoT망 VM(192.168.99.x)에서 서버망 VM(192.168.20.x)으로 ping
    # 차단 규칙이 있다면 응답 없어야 함
    ping -c 4 192.168.20.10  # 타임아웃이 나야 정상!
    
    # 개발망 VM에서 서버망으로 접근 시도
    ping -c 4 192.168.20.10  # 마찬가지로 차단되어야 함

    🎉 모든 테스트가 예상대로 동작한다면 설정 완료입니다! 처음 이 구성을 완성했을 때 진짜 뿌듯했거든요. 네트워크가 깔끔하게 정리되는 느낌이랄까요.

    ▲ 설정 완료 후 각 VLAN 간 통신 허용/차단 검증 결과입니다. 초록색은 허용, 빨간색은 차단을 의미하며 설계한 대로 정확히 동작하는 것을 확인할 수 있습니다.

    자주 묻는 질문 (FAQ)

    Q. Proxmox 방화벽과 nftables를 동시에 써도 되나요?

    권장하지 않습니다. Proxmox 내장 방화벽이 활성화되면 자체적으로 nftables 규칙을 생성하는데, 여기에 커스텀 nftables 설정을 추가하면 규칙 순서와 충돌 문제가 생길 수 있어요. 간단한 환경이라면 Proxmox 내장 방화벽만, 복잡한 규칙이 필요하다면 내장 방화벽을 끄고 nftables를 직접 관리하는 것을 추천합니다.

    Q. VLAN 설정 시 업스트림 스위치도 설정해야 하나요?

    네, 반드시 필요합니다. Proxmox와 연결된 스위치 포트는 Trunk 포트로 설정하고, 사용할 VLAN ID들을 허용해야 합니다. 관리형 스위치(Managed Switch)가 없다면 VLAN 기능을 사용하기 어렵습니다.

    Q. VM이 많아지면 방화벽 규칙 관리가 힘들지 않나요?

    맞아요, 그래서 IP set(IP 집합)과 Security Group(보안 그룹) 기능을 활용하는 게 좋습니다. Proxmox 내장 방화벽에서 IP set으로 그룹을 만들어두면 규칙 관리가 훨씬 수월해집니다.

    마무리: 네트워크 분리, 귀찮아도 꼭 해야 합니다

    처음에 이야기했던 것처럼, 저도 처음엔 “홈랩인데 뭘 그렇게까지” 싶었어요. 근데 막상 제대로 구성해 놓고 나니까, 어떤 VM에 문제가 생겨도 다른 VM이나 호스트에 영향이 없으니까 마음이 편하더라고요. 특히 외부에서 접근 가능한 서비스를 운영할 때는 정말 필수입니다.

    오늘 다룬 내용을 정리하면:

    • ✅ VLAN-aware Bridge로 논리적 네트워크 분리
    • ✅ 다중 브릿지로 완전 격리 NAT 망 구성
    • ✅ Proxmox 내장 방화벽 또는 nftables 직접 설정으로 트래픽 제어
    • ✅ VLAN 간 격리 검증으로 설정 완료 확인

    다음에는 Proxmox 클러스터 구성과 고가용성(HA, High Availability) 설정에 대해 다룰 예정이에요. 네트워크 기반이 잘 잡혀 있어야 클러스터도 안정적으로 운영할 수 있거든요. 궁금한 점이나 다른 경험 있으신 분은 댓글로 공유해 주세요!

    💡 다음 단계 제안: 이 설정을 기반으로 SDN(Software Defined Networking) 기능도 탐구해 보세요. Proxmox 8.x에서 SDN 기능이 많이 발전했는데, VXLAN 오버레이 네트워크 같은 더 고급 구성도 가능합니다. 이전 글에서 다룬 Proxmox 기본 설치 가이드와 함께 보시면 더 도움이 될 거예요.

  • [Proxmox] Proxmox VE 설치 후 필수 초기 설정: 8단계 완벽 가이드

    Proxmox VE 설치, 그 다음이 진짜 시작입니다

    Proxmox VE를 처음 설치하고 나서 웹 UI에 접속했을 때 느낌, 기억하시나요? 저는 처음에 “오, 뭔가 있어 보이는데?” 하면서 신나게 로그인했다가… 뭘 해야 할지 몰라서 한참 멍하니 화면만 바라봤었거든요. ㅎㅎ

    사실 Proxmox VE 설치 자체는 그렇게 어렵지 않아요. ISO 받아서 부팅하고, 몇 가지 옵션 선택하면 끝이니까요. 근데 설치 직후 초기 설정을 제대로 안 하면 나중에 진짜 고생합니다. 보안 구멍이 생기거나, 업데이트가 안 되거나, 스토리지 설정이 엉켜서 VM 하나 만들 때마다 삽질하게 되거든요.

    13년 동안 인프라 엔지니어로 일하면서, 그리고 집에서 홈랩을 운영하면서 겪은 경험을 바탕으로 Proxmox VE 설치 후 반드시 해야 할 필수 초기 설정을 정리해봤습니다. 초보자분들도 따라할 수 있도록 최대한 쉽게 설명할게요.

    ▲ Proxmox VE 설치 후 초기 설정 전체 흐름 — 순서대로 따라가면 됩니다


    Proxmox VE가 뭔지 잠깐만요 — 처음 들어보시는 분을 위해

    혹시 Proxmox VE가 처음이신 분도 계실 것 같아서 간단히 설명하고 넘어갈게요.

    Proxmox VE(Virtual Environment)는 오픈소스 기반의 하이퍼바이저(Hypervisor, 가상화 플랫폼)입니다. 쉽게 말해, 컴퓨터 한 대 위에서 여러 개의 가상 컴퓨터(VM)를 돌릴 수 있게 해주는 소프트웨어예요. VMware ESXi와 비슷한 역할을 하는데, 무료에 웹 UI가 꽤 잘 만들어져 있어서 홈랩이나 소규모 인프라에서 많이 씁니다.

    • KVM(Kernel-based Virtual Machine): 완전 가상화 VM을 돌릴 때 사용
    • LXC(Linux Containers): 컨테이너 방식으로 더 가볍게 리눅스 환경 구성
    • Ceph, ZFS: 스토리지 클러스터링 지원
    • 웹 기반 관리 UI: 브라우저로 모든 걸 관리

    자, 이제 본론으로 들어가겠습니다. Proxmox VE 설치는 됐다고 가정하고, 필수 초기 설정을 시작할게요!


    1단계: 무료 리포지토리 설정 — 업데이트 받기

    여기서 많은 분들이 처음에 당황하시는 부분이에요. Proxmox VE를 설치하면 기본적으로 엔터프라이즈 리포지토리(Enterprise Repository)로 설정이 되어 있거든요. 근데 이건 유료 구독을 해야 쓸 수 있어서, 구독 없이 업데이트 시도하면 인증 오류가 떠버립니다.

    홈랩이나 개인 서버에서 쓰신다면 무료 버전인 no-subscription 리포지토리로 바꿔주셔야 해요. 프로덕션 환경에서는 유료 구독을 권장하지만, 개인 용도라면 충분합니다.

    SSH로 Proxmox 서버에 접속하거나, 웹 UI의 Shell을 열어서 아래 명령어를 실행하세요.

    엔터프라이즈 리포지토리 비활성화

    # 엔터프라이즈 리포지토리 파일 비활성화
    echo "# disabled enterprise repo" > /etc/apt/sources.list.d/pve-enterprise.list
    
    # Ceph 엔터프라이즈 리포지토리도 비활성화 (있는 경우)
    echo "# disabled" > /etc/apt/sources.list.d/ceph.list

    무료 리포지토리 추가

    # Proxmox VE no-subscription 리포지토리 추가
    echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list
    
    # 패키지 목록 업데이트 및 시스템 업그레이드
    apt update && apt dist-upgrade -y

    💡 Tip: Proxmox VE 8.x 버전은 Debian 12(Bookworm) 기반입니다. 버전에 따라 코드명이 다르니, 설치된 버전을 먼저 확인하세요. pveversion 명령어로 확인할 수 있어요.

    업데이트가 다 끝나면 재부팅 한 번 해주는 게 좋아요. 커널 업데이트가 포함될 수 있거든요.

    reboot

    2단계: 로그인 화면 구독 알림 제거 (선택사항)

    이건 기능에는 전혀 영향이 없는데, 웹 UI 로그인할 때마다 “유효한 구독이 없습니다”라는 팝업이 뜨거든요. 매번 확인 누르는 게 은근히 귀찮아서 저도 처음 설정할 때 바로 없애버렸습니다.

    # Proxmox VE 8.x 기준
    sed -i.bak "s/data.status.toLowerCase() !== 'active'/false/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
    
    # 웹 서비스 재시작
    systemctl restart pveproxy

    ⚠️ 주의: 이 수정은 Proxmox 업데이트 후에 원복될 수 있어요. 업데이트 후에 다시 팝업이 뜨면 같은 명령어를 다시 실행하면 됩니다.


    3단계: 네트워크 브릿지 확인 및 설정

    가상화 서버 구축에서 네트워크 설정은 정말 중요한 부분이에요. 처음에 이 부분에서 삽질을 꽤 많이 했습니다. VM들이 외부 네트워크와 통신하려면 리눅스 브릿지(Linux Bridge)가 제대로 설정되어 있어야 하거든요.

    Proxmox는 설치 시 기본적으로 vmbr0라는 브릿지를 만들어줘요. 웹 UI에서 확인하는 방법은 이렇습니다:

    1. 웹 UI 좌측 트리에서 서버 노드 선택
    2. System(시스템) → Network(네트워크) 클릭
    3. vmbr0 브릿지와 IP 설정 확인

    설정 파일을 직접 확인하고 싶다면:

    cat /etc/network/interfaces

    정상적인 설정이라면 이런 형태가 나와야 해요:

    auto lo
    iface lo inet loopback
    
    auto eno1
    iface eno1 inet manual
    
    auto vmbr0
    iface vmbr0 inet static
            address 192.168.1.100/24
            gateway 192.168.1.1
            bridge-ports eno1
            bridge-stp off
            bridge-fd 0

    여기서 bridge-ports에 실제 물리 NIC 이름이 잘 들어가 있는지 확인하세요. 서버마다 NIC 이름이 다를 수 있어요 (eth0, eno1, enp3s0 등).

    ▲ Proxmox VE 웹 UI의 네트워크 설정 화면 — vmbr0 브릿지 구성을 확인하세요


    4단계: 스토리지 설정 최적화

    기본 설치 후 스토리지 설정이 좀 아쉬운 부분이 있어요. 특히 local-lvm 파티션 관련해서 처음에 헷갈리는 분들이 많더라고요.

    기본 스토리지 구성 이해하기

    스토리지 이름 타입 용도 저장 위치
    local Directory ISO 이미지, 백업, CT 템플릿 /var/lib/vz
    local-lvm LVM-Thin VM 디스크, CT 볼륨 LVM Thin Pool

    근데 여기서 local 스토리지에 VM 디스크 이미지를 저장하고 싶다면 추가 설정이 필요해요. 기본적으로 local은 VM 디스크(qcow2, raw)를 저장할 수 없도록 제한되어 있거든요.

    웹 UI에서 변경하는 방법:

    1. Datacenter(데이터센터) → Storage(스토리지) 클릭
    2. local 선택 후 Edit(편집)
    3. Content(콘텐츠)에서 Disk image(디스크 이미지) 항목 체크
    4. OK 클릭

    또는 CLI로 직접:

    # local 스토리지에 VM 디스크 이미지 저장 허용
    pvesm set local --content iso,vztmpl,backup,images,rootdir

    ZFS를 사용하는 경우 — 추가 최적화

    설치 시 ZFS를 선택하셨다면, ARC(Adaptive Replacement Cache, ZFS 캐시) 메모리 설정을 해주는 게 좋아요. 기본값으로 두면 ZFS가 RAM을 꽤 많이 잡아먹거든요.

    # ZFS ARC 최대 메모리 제한 (예: 4GB로 제한)
    echo "options zfs zfs_arc_max=4294967296" >> /etc/modprobe.d/zfs.conf
    update-initramfs -u

    5단계: 보안 강화 — 이거 꼭 해주세요 ⚠️

    이 부분이 진짜 중요한데 의외로 그냥 넘어가는 분들이 많아요. 특히 외부에서 접근 가능한 환경이라면 더더욱 신경 써야 합니다.

    SSH 보안 설정

    # SSH 설정 파일 편집
    nano /etc/ssh/sshd_config

    아래 항목들을 확인하고 설정하세요:

    # root 직접 로그인 비활성화 (키 인증만 허용하거나 완전 비활성화)
    PermitRootLogin prohibit-password
    
    # 비밀번호 인증 비활성화 (SSH 키 설정 후 적용)
    # PasswordAuthentication no
    
    # SSH 포트 변경 (기본 22에서 변경 권장)
    Port 2222
    # SSH 서비스 재시작
    systemctl restart sshd

    ⚠️ 경고: SSH 포트를 바꾸거나 비밀번호 인증을 끄기 전에, 반드시 SSH 키 로그인이 정상 동작하는지 먼저 확인하세요. 잘못하면 서버에 접속을 못하게 될 수 있어요. 저도 한 번 이렇게 자폭한 적이 있습니다… ㅎㅎ

    Proxmox 웹 UI 포트 방화벽 설정

    Proxmox는 기본적으로 8006 포트로 웹 UI에 접근합니다. Proxmox 내장 방화벽을 활성화하고 필요한 포트만 열어두세요.

    웹 UI에서 설정하는 방법:

    1. Datacenter(데이터센터) → Firewall(방화벽) → Options(옵션)
    2. Firewall: Yes로 변경
    3. 노드 레벨 방화벽도 동일하게 활성화
    4. 필요한 포트(8006, SSH 포트, 마이그레이션 포트 등) 규칙 추가

    강력한 비밀번호 설정 확인

    # root 비밀번호 변경
    passwd root

    웹 UI에서 별도 사용자를 만들어 root 직접 사용을 줄이는 것도 좋은 방법이에요. Datacenter → Permissions → Users에서 관리자 계정을 별도로 만들 수 있습니다.


    6단계: 시간 동기화 설정 확인

    이거 별거 아닌 것 같아도 나중에 로그 분석하거나 클러스터 구성할 때 시간이 맞지 않으면 진짜 골치 아파요. 꼭 확인하세요.

    # 현재 시간 동기화 상태 확인
    timedatectl status
    
    # systemd-timesyncd 서비스 상태 확인
    systemctl status systemd-timesyncd

    타임존 설정이 잘못되어 있다면:

    # 타임존을 서울로 설정
    timedatectl set-timezone Asia/Seoul
    
    # 동기화 확인
    timedatectl show-timesync --all

    NTP 서버를 커스텀으로 지정하고 싶다면 /etc/systemd/timesyncd.conf를 편집하세요:

    [Time]
    NTP=time.bora.net 0.pool.ntp.org 1.pool.ntp.org
    FallbackNTP=2.pool.ntp.org
    systemctl restart systemd-timesyncd

    7단계: 백업 정책 설정 — 미래의 나를 위해

    “백업은 나중에 해야지” 하다가 VM 날려먹은 경험… 저만 있는 건 아니겠죠? ㅎㅎ Proxmox는 기본적으로 꽤 쓸 만한 백업 기능을 내장하고 있어요. 처음부터 스케줄 잡아두는 걸 강력 추천합니다.

    백업 스케줄 설정 (웹 UI)

    1. Datacenter(데이터센터) → Backup(백업) 클릭
    2. Add(추가) 버튼 클릭
    3. 스케줄, 저장소, 대상 VM, 보존 정책 설정
    4. Create(생성) 클릭

    주요 설정 항목:

    • Storage(저장소): 백업 파일을 저장할 위치
    • Schedule(스케줄): cron 형식으로 지정 (예: 매일 새벽 2시 → 02:00)
    • Mode(모드): Snapshot(스냅샷), Suspend(일시정지), Stop(중지) 중 선택
    • Max Backups(최대 백업 수): 보존할 백업 개수 (스토리지 용량 고려)

    💡 Tip: VM이 중요하다면 Snapshot 모드를 권장해요. 서비스 중단 없이 백업이 가능하거든요. 단, 게스트 OS에 QEMU 에이전트가 설치되어 있어야 완전한 일관성이 보장됩니다.


    8단계: QEMU Guest Agent 설정

    VM을 만들 때 꼭 챙겨야 하는 설정인데, 기본 가이드에서 빠져있는 경우가 많아요. QEMU Guest Agent(게스트 에이전트)는 호스트(Proxmox)와 게스트(VM) 사이의 통신 채널을 제공해줘요.

    이게 있으면:

    • VM의 IP 주소를 Proxmox UI에서 바로 확인 가능
    • 정상적인 셧다운/재시작 명령 전달
    • 백업 시 파일시스템 동기화(freeze/thaw) 지원
    • 메모리 사용량 등 상세 정보 수집

    VM 설정에서 Guest Agent 활성화

    1. VM 선택 → Options(옵션)
    2. QEMU Guest Agent 항목 더블클릭
    3. Enabled(활성화) 체크 → OK

    게스트 OS에 에이전트 설치

    # Ubuntu/Debian 게스트에서
    apt install qemu-guest-agent -y
    systemctl enable qemu-guest-agent
    systemctl start qemu-guest-agent
    # CentOS/RHEL/Rocky Linux 게스트에서
    dnf install qemu-guest-agent -y
    systemctl enable qemu-guest-agent
    systemctl start qemu-guest-agent

    ▲ QEMU Guest Agent가 정상 동작하면 VM의 IP 주소와 상세 정보가 대시보드에 표시됩니다


    ⚠️ 자주 겪는 문제와 해결법

    문제 1: 웹 UI 접속이 안 돼요

    설치 직후 https://서버IP:8006으로 접속이 안 된다면, 브라우저에서 HTTP가 아닌 HTTPS로 접속하고 있는지 확인하세요. Proxmox는 기본적으로 자체 서명 인증서(Self-signed certificate)를 사용하기 때문에 브라우저에서 보안 경고가 뜨는 건 정상이에요. “고급” 클릭 후 “계속 진행”하면 됩니다.

    # pveproxy 서비스 상태 확인
    systemctl status pveproxy
    
    # 서비스 재시작
    systemctl restart pveproxy

    문제 2: apt update 시 인증 오류

    “401 Unauthorized” 오류가 나온다면 엔터프라이즈 리포지토리가 아직 활성화되어 있는 거예요. 1단계로 돌아가서 리포지토리 설정을 다시 확인하세요.

    문제 3: VM 생성 시 스토리지 선택이 안 됨

    VM 디스크를 저장할 스토리지가 보이지 않는다면, 해당 스토리지의 Content(콘텐츠) 설정에 Disk image가 포함되어 있는지 확인하세요. 4단계 스토리지 설정 부분을 다시 참고해주세요.

    문제 4: 네트워크 설정 변경 후 연결이 끊김

    이건 진짜 당황스럽죠… 웹 UI에서 네트워크 설정 변경 시 Apply Configuration(설정 적용) 버튼을 누르기 전에 설정을 꼭 다시 검토하세요. 잘못된 IP나 게이트웨이를 입력하면 연결이 끊길 수 있어요. 이럴 때를 대비해 물리적 접근(KVM 콘솔, IPMI 등)이나 직접 모니터+키보드 연결 방법을 미리 확보해두는 게 좋습니다.


    설정 완료 후 확인 체크리스트 ✅

    모든 설정을 마쳤다면 아래 체크리스트로 한 번 더 확인해보세요.

    ▲ Proxmox VE 초기 설정 완료 체크리스트 — 하나씩 확인해보세요

    • ✅ no-subscription 리포지토리로 변경 완료
    • ✅ apt update && apt dist-upgrade 실행 완료
    • ✅ 네트워크 브릿지(vmbr0) 정상 동작 확인
    • ✅ 스토리지 설정 및 콘텐츠 타입 확인
    • ✅ SSH 보안 설정 완료
    • ✅ 방화벽 기본 규칙 설정
    • ✅ 시간 동기화(NTP) 정상 동작 확인
    • ✅ 백업 스케줄 설정 완료
    • ✅ 테스트 VM 생성 및 QEMU Guest Agent 동작 확인

    마무리: 이제 진짜 가상화 서버 구축의 시작입니다 🎉

    여기까지 따라오셨다면 이제 Proxmox VE 기반의 안정적인 가상화 서버 구축을 위한 기초가 완성된 거예요. 처음에는 설정할 게 많아 보여도, 한 번 제대로 해두면 나중에 진짜 편해집니다.

    저도 처음 홈랩에 Proxmox를 올렸을 때는 이런 가이드가 없어서 여기저기 찾아다니며 조각조각 맞추느라 꽤 오래 걸렸어요. 이 글이 처음 시작하시는 분들께 조금이나마 도움이 됐으면 좋겠네요.

    다음 단계로 추천하는 것들:

    • 🖥️ 첫 번째 VM 만들어보기 (Ubuntu Server, Rocky Linux 등)
    • 📦 LXC 컨테이너로 가벼운 서비스 돌려보기
    • 🔗 Let’s Encrypt 인증서로 웹 UI HTTPS 설정하기
    • 💾 외부 NAS 스토리지 연동 (NFS, SMB)
    • 🔄 Proxmox 클러스터 구성 (서버가 여러 대라면)

    다음 글에서는 Proxmox VE에서 첫 번째 VM 만들기를 다뤄볼 예정이에요. Ubuntu Server를 설치하고 기본 설정까지 하는 과정을 처음부터 끝까지 보여드릴게요. 기대해주세요!

    궁금한 점이나 제가 놓친 부분이 있으면 댓글로 남겨주세요. 같이 삽질하며 배우는 게 제일 재미있으니까요 😄