13년차의 서버실

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

[태그:] Proxmox 가상화

  • [홈랩] Proxmox에 Home Assistant OS 구축: 안정적인 홈랩 베스트 프랙티스

    [홈랩] Proxmox에 Home Assistant OS 구축: 안정적인 홈랩 베스트 프랙티스

    [홈랩] Proxmox에 Home Assistant OS 구축: 안정적인 홈랩 베스트 프랙티스

    Proxmox Home Assistant OS 조합을 찾는 분들이 정말 많습니다. 저도 홈랩을 굴리면서 라즈베리 파이, Docker(도커), LXC(리눅스 컨테이너), 그리고 VM(가상머신)까지 이것저것 다 해봤거든요. 결론부터 말씀드리면, 장기적으로 덜 흔들리고 관리가 편한 쪽은 Proxmox 위에 HAOS(Home Assistant OS, 홈 어시스턴트 전용 운영체제)를 올리는 방식이었습니다. 처음엔 “굳이 전용 OS까지?” 싶었는데, Add-on(애드온, 확장 기능), 백업, 복구 흐름이 생각보다 깔끔해서 결국 이쪽으로 정착했네요.

    특히 스마트홈 서버는 한 번 꼬이면 집안 자동화가 줄줄이 멈춥니다. 조명 자동화가 안 되고, 센서 상태가 늦게 올라오고, 외부 접속도 어긋나고요. 그래서 이번 글에서는 제가 실제로 여러 번 구축하고 옮겨보면서 정리한 HAOS Proxmox 구성법과 운영 팁을 한 번에 정리해보겠습니다. 삽질도 좀 했습니다 ㅎㅎ 그래서 더 현실적인 가이드가 될 겁니다.

    Proxmox 가상화 환경 위에 Home Assistant OS가 올라가고, 라우터와 IoT 기기, NAS 백업 저장소가 연결된 전체 구조 예시입니다.

    왜 Proxmox와 Home Assistant OS 조합이 홈랩에 적합할까?

    쉽게 말해 Proxmox VE(프록스목스 가상화 환경)는 하드웨어 위에 여러 서버를 나눠 올리는 기반이고, HAOS는 Home Assistant를 가장 일관된 형태로 운영하기 위한 전용 이미지입니다. 이 둘을 합치면 장점이 꽤 분명합니다.

    • 분리 운영: NAS, 테스트용 리눅스 VM, 스마트홈 서버를 각각 독립적으로 운영하기 좋습니다.
    • 백업 편의성: Proxmox 백업과 Home Assistant 내부 백업을 이중으로 가져갈 수 있습니다.
    • 복구 속도: 장애가 나도 VM 단위로 되살리기 편합니다.
    • 확장성: USB 패스스루(USB passthrough, USB 장치 직접 연결), VLAN(가상 LAN), 별도 스토리지 연결이 수월합니다.

    제가 직접 써보니 Docker 설치형도 분명 가볍고 유연합니다. 근데 스마트홈 서버는 “가볍다”보다 안정적으로 오래 돌아가는가가 더 중요하더라고요. 특히 Zigbee(지그비) 동글이나 백업 복구까지 생각하면 HAOS 쪽이 훨씬 덜 피곤했습니다.

    설치 방식 비교: 어떤 선택이 덜 후회될까?

    방식 장점 주의점 추천 대상
    Home Assistant OS on VM 기능 구성이 완전하고 Add-on 사용이 편함 가상머신 자원 계획 필요 처음 구축하는 분, 안정성 우선
    Home Assistant Container 유연하고 직접 제어 범위가 넓음 Supervisor, Add-on 흐름이 다름 컨테이너 운영 경험이 많은 분
    LXC 기반 설치 자원 효율이 좋을 수 있음 지원 범위와 유지보수 판단이 중요 실험용, 구조를 잘 이해한 분

    여기서 중요한 포인트! 안정적인 홈랩 자동화를 목표라면 VM 기반 HAOS가 제일 덜 헷갈립니다. 결국 오래 버티는 구성이 이기거든요.

    구축 전 체크리스트: 시작 전에 이건 꼭 보세요

    처음엔 설치부터 눌러버리고 싶죠. 저도 그랬습니다. 근데 아래 항목을 먼저 정리해두면 나중에 재설치할 일이 확 줄어듭니다.

    1. 고정 IP 계획: Home Assistant가 받을 IP를 DHCP Reservation(고정 할당)으로 미리 정해두세요.
    2. 스토리지 위치: VM 디스크를 어느 스토리지에 둘지 정합니다. SSD 계열이면 체감이 좋습니다.
    3. 백업 저장소: Proxmox 백업과 Home Assistant 백업을 어디에 둘지 정하세요. 같은 디스크 하나만 믿으면 불안합니다.
    4. USB 장치 여부: Zigbee, Z-Wave 동글을 쓸 계획이면 패스스루 대상 장치를 미리 확인합니다.
    5. 브리지 네트워크: 보통 vmbr0 브리지에 붙이게 되는데, 기존 네트워크 구조와 충돌이 없는지 점검합니다.

    사실 스마트홈 서버는 설치보다 이전과 복구 전략이 더 중요합니다. 저도 처음엔 그냥 빨리 띄우는 데만 집중했었는데, 나중에 SSD 교체할 때 백업 설계가 안 되어 있어서 꽤 번거로웠습니다.

    실전 구축 1: HAOS 이미지를 Proxmox VM으로 올리기

    실전으로 가보겠습니다. 순서는 단순합니다. HAOS 이미지 준비 → Proxmox에 VM 생성 → 디스크 가져오기 → 부팅 흐름입니다.

    1. HAOS 이미지 준비

    Home Assistant OS용 qcow2 이미지를 준비합니다. 파일명은 시점에 따라 다를 수 있으니, 최신 릴리스에서 받았다고 가정하고 예시에서는 변수처럼 표기하겠습니다.

    cd /var/lib/vz/template/iso
    ls
    # 예시: haos_ova-xx.x.qcow2.xz 형태의 파일을 준비한 뒤 압축 해제
    xz -d <HAOS_IMAGE_FILE>.xz
    ls -lh

    파일명이 제각각이라 여기서 많이 헷갈리더라고요. 저도 처음엔 확장자만 보고 OVA(오브이엠에이)랑 QCOW2를 섞어서 봤었습니다. 핵심은 Proxmox에서 가져올 수 있는 디스크 이미지 파일을 준비하는 것입니다.

    2. VM 생성

    예시 VM ID는 300으로 잡아보겠습니다. 이름은 취향대로 정하시면 됩니다.

    qm create 300 \
      --name home-assistant \
      --memory 4096 \
      --cores 2 \
      --net0 virtio,bridge=vmbr0

    메모리와 코어는 환경에 맞게 조정하시면 됩니다. 제가 실제로 써보니 시작은 너무 타이트하게 잡지 않는 게 낫습니다. 나중에 애드온이 늘어나면 생각보다 금방 빡빡해지거든요.

    3. 디스크 이미지 가져오기

    스토리지 이름은 환경마다 다르니 local-lvm, local-zfs, data-store 같은 실제 이름으로 바꿔서 쓰시면 됩니다.

    qm importdisk 300 /var/lib/vz/template/iso/<HAOS_IMAGE_FILE>.qcow2 <TARGET_STORAGE>

    가져오기가 끝나면 Proxmox에서 해당 디스크를 VM에 연결해야 합니다.

    qm set 300 --scsihw virtio-scsi-pci
    qm set 300 --scsi0 <TARGET_STORAGE>:vm-300-disk-0
    qm set 300 --boot order=scsi0
    qm set 300 --serial0 socket --vga serial0

    여기서 serial0 설정은 콘솔 확인할 때 꽤 편합니다. 부팅 로그를 볼 수 있어서 문제 생겼을 때 원인 파악이 빨라지더라고요.

    4. 첫 부팅

    qm start 300
    qm status 300

    부팅 후에는 네트워크에서 Home Assistant가 IP를 받아야 합니다. 보통 웹 브라우저에서 http://<HA_IP>:8123으로 접속하거나, mDNS(멀티캐스트 DNS)가 되는 환경이면 http://homeassistant.local:8123 형태로 접근할 수 있습니다.

    HAOS Proxmox 가상머신 설정 화면 예시

    Proxmox UI에서 VM 하드웨어 항목, 디스크 연결, 부팅 순서를 확인하는 장면을 넣으면 초보자도 흐름을 따라가기 편합니다.

    실전 구축 2: 안정적으로 굴리기 위한 Proxmox 설정 팁

    설치만 끝났다고 끝이 아닙니다. Proxmox 가상화 환경에서 Home Assistant를 오래 안정적으로 돌리려면 몇 가지 운영 포인트를 잡아두는 게 좋습니다.

    가상 하드웨어는 단순하게

    • 네트워크 어댑터는 보통 virtio로 시작하면 무난합니다.
    • 디스크 버스는 SCSI 계열로 맞추면 관리가 편한 경우가 많습니다.
    • 무리한 CPU 타입 튜닝은 초기에 굳이 안 건드려도 됩니다.

    처음엔 저도 성능 욕심 나서 이것저것 최적화하려고 했는데, 스마트홈 서버는 극한 튜닝보다 예측 가능한 구성이 더 중요했습니다.

    백업은 두 겹으로

    이건 진짜 강조하고 싶습니다.

    1. Proxmox VM 백업을 정기적으로 수행합니다.
    2. Home Assistant 내부 백업도 별도로 남깁니다.

    한쪽만 믿으면 애매한 순간이 옵니다. VM 자체를 통째로 되돌릴 때와, Home Assistant 설정만 빠르게 복원할 때가 다르거든요.

    스냅샷은 업그레이드 직전에

    모든 스냅샷이 만능은 아니지만, 주요 변경 전에 하나 찍어두면 심리적으로도 훨씬 편합니다. 특히 통합(Integration, 연동 기능)이나 애드온 추가 전에는요.

    qm snapshot 300 pre-update
    qm listsnapshot 300

    물론 스냅샷을 장기 보관 전략으로 쓰는 건 다릅니다. 운영 백업과 스냅샷은 역할이 다르다고 보시면 됩니다.

    ⚠️ 트러블슈팅: 제가 실제로 자주 부딪힌 문제들

    여기서는 진짜 많이 묻는 문제 위주로 정리해보겠습니다. 저도 처음엔 이게 뭔가 싶었는데, 패턴을 알고 나면 금방 풀립니다.

    1. 부팅은 되는데 웹 접속이 안 됩니다

    • 브리지(vmbr0) 연결이 맞는지 확인합니다.
    • DHCP에서 IP를 받았는지 라우터에서 확인합니다.
    • 초기 부팅 직후에는 준비 시간이 조금 필요할 수 있습니다.

    특히 첫 부팅 직후에는 바로 안 뜨는 경우가 있습니다. 괜히 중간에 강제 재부팅하지 말고 조금 기다려보세요. 저도 성격 급해서 몇 번 더 꼬이게 만든 적이 있습니다 ㅎㅎ

    2. USB 동글이 안 잡힙니다

    Zigbee 동글을 붙일 때 자주 나옵니다. 이 경우는 Proxmox에서 해당 USB 장치를 VM으로 패스스루해야 합니다. 장치가 바뀔 수 있으니 물리 포트 변경 후 다시 확인하는 습관이 필요합니다.

    • 호스트에서 USB 장치 식별이 되는지 먼저 확인
    • VM 하드웨어 항목에 USB 장치 추가
    • 재부팅 후 Home Assistant에서 장치 인식 여부 확인

    3. 업데이트 후 뭔가 이상합니다

    이럴 때는 무조건 “다시 만지기”보다 최근 변경 사항부터 되짚는 게 먼저입니다. 통합 추가, 애드온 설치, 네트워크 변경, 스토리지 변경 순으로 보시면 됩니다. 가능하면 업데이트 전 백업이나 스냅샷에서 비교해보세요.

    4. 리소스는 충분한데 체감이 느립니다

    이건 Home Assistant 자체 문제라기보다 호스트 스토리지, 다른 VM의 IO(입출력), 백업 시간대 겹침 때문에 생길 때가 많습니다. 홈랩 자동화 환경에서는 백업 작업이 한밤중에 몰리면서 응답이 늦어지는 경우도 있더라고요.

    Proxmox Home Assistant OS USB 패스스루와 브리지 네트워크 구성

    Zigbee 동글 USB 패스스루 흐름과 vmbr0 브리지 연결 구조를 시각적으로 보여주면 트러블슈팅 이해가 훨씬 쉬워집니다.

    검증과 결과: 구축이 잘 끝났는지 어떻게 확인할까?

    구축 후에는 “켜진다”만 확인하면 반쪽입니다. 저는 아래 순서로 점검합니다.

    1. 웹 접속 확인: 8123 포트로 접속이 안정적으로 되는지
    2. 재부팅 테스트: Proxmox 호스트 재부팅 후 VM이 정상 복구되는지
    3. 백업 복원 흐름 확인: 최소한 백업 파일 생성까지는 검증
    4. 주요 통합 확인: 센서, 스위치, 알림, 자동화가 정상 동작하는지

    실제로 써보니까, 여기서 제일 중요한 건 재부팅 후 정상 복구였습니다. 평소엔 멀쩡해도 정전이나 장비 교체 뒤에 문제가 터지는 경우가 있거든요. 그래서 저는 구축 직후 일부러 한 번 껐다 켜봅니다. 좀 귀찮아도 이게 나중에 진짜 편합니다.

    automation:
      - alias: "HA Start Notification"
        trigger:
          platform: homeassistant
          event: start
        action:
          - service: persistent_notification.create
            data:
              title: "Home Assistant"
              message: "Home Assistant가 정상적으로 시작되었습니다."
        mode: single

    이런 식으로 시작 알림을 하나 걸어두면 재부팅 후 상태 확인이 편합니다. 작은 팁인데 꽤 유용합니다.

    Proxmox Home Assistant OS 구축 후 대시보드 결과 화면

    센서 상태와 자동화 실행 이력이 정상적으로 보이는 Home Assistant 대시보드 예시입니다.

    운영하면서 느낀 베스트 프랙티스 정리

    • 처음부터 완벽하게 꾸미려 하지 않기: 우선 기본 자동화부터 안정화하세요.
    • 백업 경로 분리: 호스트와 게스트 내부 백업을 분리하면 복구 선택지가 늘어납니다.
    • USB 장치는 문서화: 어떤 동글이 어느 포트에 연결됐는지 메모해두면 좋습니다.
    • 업데이트는 한 번에 많이 하지 않기: 여러 요소를 동시에 바꾸면 문제 원인 추적이 어려워집니다.
    • 테스트용 자동화와 실사용 자동화 분리: 실험하다가 집안 전체 동작이 흔들리는 걸 줄일 수 있습니다.

    저도 예전엔 설정을 한 번에 몰아서 바꾸다가, 뭐가 문제인지 못 찾아서 결국 원복했던 적이 많았습니다. 지금은 작게 바꾸고 바로 검증하는 쪽으로 완전히 습관이 바뀌었네요.

    자주 묻는 질문 FAQ

    Q1. 스마트홈 서버는 꼭 Proxmox 위에서 돌려야 하나요?

    아닙니다. 다만 여러 서비스를 함께 운영하는 홈랩이라면 Proxmox 같은 하이퍼바이저(Hypervisor, 가상화 기반 플랫폼)가 관리상 편합니다.

    Q2. HAOS Proxmox 구성은 초보자에게 어렵지 않나요?

    처음엔 용어가 낯설 수 있습니다. 근데 설치 흐름 자체는 생각보다 단순합니다. 오히려 장기 운영은 더 편한 편입니다.

    Q3. Docker 대신 HAOS를 고른 이유는 뭔가요?

    제가 직접 운영해보니 Add-on과 백업, 복구 흐름이 한 덩어리로 맞물리는 점이 좋았습니다. 특히 홈랩 자동화처럼 운영 기간이 길어질수록 장점이 더 보였습니다.

    마무리: Proxmox Home Assistant OS는 결국 운영 편의성 싸움입니다

    Proxmox Home Assistant OS 조합은 화려한 기술이라기보다, 오래 운영할수록 진가가 드러나는 방식입니다. 처음엔 VM 만들고 이미지 넣는 과정이 조금 번거롭게 느껴질 수 있습니다. 근데 한 번 안정화해두면 장애 대응, 백업, 이전 작업이 훨씬 수월해집니다. 저는 결국 “관리 가능한 복잡도”가 제일 중요하다고 느꼈습니다.

    혹시 지금 라즈베리 파이에서 옮길지 고민 중이시라면, 이번에는 단순 설치보다 복구 가능한 구조를 목표로 잡아보세요. 다음 글에서는 Proxmox 백업 전략이나 리버스 프록시(Reverse Proxy, 역방향 프록시), 외부 접속 구성도 이어서 다뤄볼 예정입니다. 이전 글에서 다룬 홈랩 네트워크 분리나 VLAN 구성과도 같이 보면 더 이해가 잘 되실 겁니다.

    설치 전 체크리스트, 운영 팁, 백업 전략을 한눈에 정리한 요약 인포그래픽 자리입니다.

  • [Proxmox] LXC 컨테이너 활용 가이드: VM보다 가볍게 서비스 배포하기

    VM보다 가볍게, LXC 컨테이너로 홈서버 바꾼 이야기

    솔직히 말씀드리면, 저도 처음엔 Proxmox에서 뭘 돌리든 그냥 VM(가상 머신)만 썼거든요. 익숙하기도 했고, “VM이면 다 되잖아” 하는 안일한 생각도 있었고요. 근데 홈랩 서버에 서비스가 하나둘 늘어나다 보니까 문제가 생기기 시작했습니다. RAM이 부족해지고, 부팅 시간도 길어지고, 작은 서비스 하나 띄우는데 2GB 메모리를 쓰는 게 너무 아까운 거예요.

    그때 제대로 파고들기 시작한 게 바로 Proxmox LXC 컨테이너였습니다. 처음엔 “이게 Docker랑 뭐가 다르지?” 싶었는데, 실제로 써보니까 완전히 다른 매력이 있더라고요. 오늘은 13년간 인프라 엔지니어로 일하면서 직접 삽질해가며 터득한 Proxmox LXC 컨테이너 활용법을 공유해드리려 합니다.

    Proxmox VE 환경에서 LXC 컨테이너와 VM이 함께 운영되는 구조 — 같은 호스트에서 자원 효율성 차이가 확연합니다.

    LXC 컨테이너란? VM과 뭐가 다른가요?

    개념부터 짚고 넘어가겠습니다. 헷갈리는 분들이 많으시더라고요.

    LXC(Linux Containers, 리눅스 컨테이너)는 쉽게 말해서, 커널은 호스트와 공유하면서 독립된 사용자 공간(User Space)을 가지는 가상화 방식입니다. VM처럼 하드웨어를 통째로 에뮬레이션하지 않아요. 그래서 훨씬 가볍습니다.

    구분 VM (가상 머신) LXC 컨테이너 Docker
    커널 공유 ❌ 별도 커널 ✅ 호스트 커널 공유 ✅ 호스트 커널 공유
    격리 수준 매우 높음 높음 중간
    부팅 속도 느림 (수십 초) 빠름 (수 초) 매우 빠름 (즉시)
    메모리 오버헤드 높음 낮음 매우 낮음
    전체 OS 환경 ✅ 완전한 OS ✅ 완전한 OS 환경 ❌ 앱 중심
    systemd 사용 ✅ ✅ ❌ (기본적으로)

    LXC의 포지션이 보이시죠? VM의 완전한 OS 환경은 유지하면서, 자원 사용량은 훨씬 적은 중간 지점이에요. 실제로 제 홈랩에서 Nginx 서버 기준으로 VM은 약 512MB~1GB RAM을 먹는데, LXC 컨테이너는 50~100MB 수준에서 돌더라고요. 이 차이가 쌓이면 정말 엄청납니다.

    Proxmox에서 LXC 컨테이너 생성하기 — 단계별 가이드

    자, 이제 실전으로 들어가겠습니다. Proxmox VE(가상화 환경)에서 LXC 컨테이너를 생성하는 방법인데요. GUI와 CLI 두 가지 방법 모두 알려드릴게요.

    1단계: CT 템플릿(Container Template) 다운로드

    LXC 컨테이너를 만들려면 먼저 기반이 되는 OS 템플릿이 필요합니다. Proxmox에서는 이걸 CT 템플릿이라고 부르고요. GUI에서는 스토리지 → Templates 메뉴에서 바로 다운로드할 수 있어요.

    CLI에서는 이렇게 합니다:

    # 사용 가능한 템플릿 목록 확인
    pveam update
    pveam available --section system
    
    # Ubuntu 22.04 템플릿 다운로드 (local 스토리지에)
    pveam download local ubuntu-22.04-standard_22.04-1_amd64.tar.zst

    2단계: LXC 컨테이너 생성

    GUI에서는 우측 상단 “Create CT” 버튼 클릭 후 마법사를 따라가시면 됩니다. CLI로는 이렇게요:

    # pct create [VMID] [템플릿 경로] [옵션들]
    pct create 200 local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst \
      --hostname my-nginx \
      --memory 512 \
      --swap 512 \
      --cores 2 \
      --net0 name=eth0,bridge=vmbr0,ip=192.168.1.200/24,gw=192.168.1.1 \
      --storage local-lvm \
      --rootfs local-lvm:8 \
      --password YourSecurePassword \
      --unprivileged 1
    
    # 생성된 컨테이너 시작
    pct start 200
    
    # 컨테이너 상태 확인
    pct status 200

    여기서 --unprivileged 1 옵션이 정말 중요합니다. 비특권 컨테이너(Unprivileged Container)로 만드는 건데, 보안상 훨씬 안전해요. 특별한 이유가 없으면 항상 이 옵션을 켜두시길 권장합니다.

    3단계: 컨테이너 접속 및 초기 설정

    # 컨테이너 콘솔 접속
    pct enter 200
    
    # 또는 exec으로 명령어 실행
    pct exec 200 -- bash -c "apt update && apt upgrade -y"

    접속하면 완전한 Ubuntu 환경이 펼쳐집니다. 일반 서버처럼 쓰시면 돼요.

    Proxmox GUI의 LXC 컨테이너 생성 마법사 — 네트워크, 스토리지, 리소스를 단계별로 설정합니다.

    실전 활용 — 자주 쓰는 서비스 배포 예시

    개념만 알면 재미없죠. 제가 실제로 홈랩에서 LXC 컨테이너로 돌리고 있는 서비스 패턴을 공유해드릴게요.

    Nginx 리버스 프록시 컨테이너

    # 컨테이너 안에서
    apt update && apt install -y nginx
    
    # Nginx 설정
    cat > /etc/nginx/sites-available/myapp << 'EOF'
    server {
        listen 80;
        server_name myapp.local;
    
        location / {
            proxy_pass http://192.168.1.100:3000;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
    EOF
    
    ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
    nginx -t && systemctl reload nginx

    컨테이너 설정 파일로 관리하기

    Proxmox LXC 컨테이너는 /etc/pve/lxc/[VMID].conf 파일로 설정이 관리됩니다. 이걸 알면 나중에 설정 백업이나 복제가 훨씬 편해져요.

    # 컨테이너 200번의 설정 파일 확인
    cat /etc/pve/lxc/200.conf
    # 일반적인 LXC 컨테이너 설정 파일 예시
    arch: amd64
    cores: 2
    hostname: my-nginx
    memory: 512
    net0: name=eth0,bridge=vmbr0,gw=192.168.1.1,hwaddr=AA:BB:CC:DD:EE:FF,ip=192.168.1.200/24,type=veth
    ostype: ubuntu
    rootfs: local-lvm:vm-200-disk-0,size=8G
    swap: 512
    unprivileged: 1
    
    # 자동 시작 설정 (서버 재부팅 시 자동으로 컨테이너 시작)
    onboot: 1
    startup: order=1,up=30

    onboot: 1과 startup 옵션은 꼭 설정해두세요. 서버 재부팅 후에 컨테이너가 자동으로 올라오게 됩니다. 처음에 이거 몰라서 재부팅할 때마다 수동으로 시작했었는데... 정말 삽질이었죠 ㅎㅎ

    호스트 디렉토리 마운트 (Bind Mount)

    컨테이너에서 호스트의 특정 디렉토리를 공유해서 쓰고 싶을 때 바인드 마운트(Bind Mount)를 씁니다. 예를 들어 미디어 파일이 호스트에 있는데 컨테이너 안의 Jellyfin에서 접근해야 할 때요.

    # 컨테이너가 중지된 상태에서 마운트 추가
    pct set 200 -mp0 /mnt/data/media,mp=/media,ro=0
    
    # 또는 설정 파일 직접 편집
    # /etc/pve/lxc/200.conf에 아래 줄 추가
    # mp0: /mnt/data/media,mp=/media

    ⚠️ 주의: 비특권 컨테이너(Unprivileged)에서 바인드 마운트 시 UID/GID 매핑 문제가 생길 수 있습니다. 이 부분은 뒤에서 트러블슈팅으로 다룰게요.

    ⚠️ 주의사항과 삽질 기록 — 진짜 겪은 문제들

    이 섹션이 사실 제일 중요할 수 있어요. 공식 문서에는 잘 안 나오는 것들이거든요.

    문제 1: 비특권 컨테이너에서 파일 권한 오류

    비특권 컨테이너는 보안을 위해 UID를 매핑합니다. 컨테이너 안의 root(UID 0)가 호스트에서는 UID 100000으로 보이는 식이에요. 그래서 호스트 디렉토리를 마운트하면 권한 문제가 생깁니다.

    해결 방법:

    # 호스트에서 해당 디렉토리의 소유자를 컨테이너 UID로 변경
    # 컨테이너 안의 UID 1000 사용자 → 호스트에서는 101000
    chown -R 101000:101000 /mnt/data/media
    
    # 또는 chmod로 모든 사용자 접근 허용 (보안 주의)
    chmod -R 777 /mnt/data/media

    문제 2: 특권 기능이 필요한 서비스 (Docker-in-LXC)

    LXC 컨테이너 안에서 Docker를 돌리고 싶을 때가 있거든요. 이게 되긴 합니다만, 설정이 필요합니다.

    # /etc/pve/lxc/200.conf에 추가해야 할 내용
    # (컨테이너 중지 후 편집)
    features: keyctl=1,nesting=1

    이 경우엔 특권 컨테이너(Privileged Container)로 만들거나, nesting 기능을 활성화해야 해요. 저도 처음에 이것 때문에 한참 헤맸습니다. Docker가 계속 실패하는데 이유를 몰라서요.

    문제 3: 컨테이너 네트워크가 안 잡힐 때

    # 컨테이너 안에서 네트워크 확인
    ip addr show
    ip route show
    
    # DNS 확인
    cat /etc/resolv.conf
    
    # DNS가 없다면 추가
    echo "nameserver 8.8.8.8" >> /etc/resolv.conf
    
    # 또는 Proxmox 호스트에서 컨테이너 네트워크 재설정
    pct set 200 --net0 name=eth0,bridge=vmbr0,ip=192.168.1.200/24,gw=192.168.1.1

    문제 4: 컨테이너 스냅샷이 안 될 때

    스냅샷 기능을 쓰려면 스토리지가 스냅샷을 지원해야 합니다. local-lvm(LVM-Thin)이나 ZFS를 쓰면 되고, 일반 ext4 디렉토리 스토리지는 스냅샷이 안 돼요. 이것도 처음에 몰라서 삽질했습니다.

    # 스냅샷 생성
    pct snapshot 200 snap-before-update --description "업데이트 전 백업"
    
    # 스냅샷 목록 확인
    pct listsnapshot 200
    
    # 스냅샷으로 롤백
    pct rollback 200 snap-before-update

    💡 팁: 서비스 업데이트나 큰 변경 전에 스냅샷 찍는 습관을 들이세요. 저는 이게 몇 번이나 저를 살렸는지 모릅니다.

    LXC 컨테이너 관리 꿀팁 모음

    일상적으로 자주 쓰는 관리 명령어들을 정리해드릴게요.

    # 전체 컨테이너 목록 확인
    pct list
    
    # 컨테이너 리소스 사용량 실시간 확인
    pct monitor 200
    
    # 컨테이너 복제 (Clone)
    pct clone 200 201 --hostname my-nginx-clone --full
    
    # 컨테이너 백업
    vzbackup 200 --storage local --mode snapshot
    
    # 컨테이너 중지 및 삭제
    pct stop 200
    pct destroy 200
    
    # 실행 중인 컨테이너에 리소스 핫 변경 (재시작 불필요)
    pct set 200 --memory 1024
    pct set 200 --cores 4

    특히 리소스 핫 변경은 정말 편한 기능이에요. VM은 보통 재시작해야 메모리 변경이 되는데, LXC는 실행 중에도 바로 적용됩니다. 이거 처음 알았을 때 "아 이래서 LXC 쓰는구나" 했던 기억이 나네요.

    여러 LXC 컨테이너가 동시에 운영되는 Proxmox 환경 — 각 컨테이너의 CPU, 메모리 사용량을 실시간으로 확인할 수 있습니다.

    ✅ 결과 확인 — 실제로 얼마나 가벼워졌나?

    제 홈랩 기준으로 비교해드릴게요. 같은 Nginx + 간단한 웹 앱 기준입니다.

    항목 Ubuntu VM Ubuntu LXC 컨테이너
    부팅 시간 약 30~40초 약 3~5초
    유휴 메모리 사용 약 400~600MB 약 50~100MB
    디스크 사용 (OS 기본) 약 3~5GB 약 300~500MB
    스냅샷 생성 속도 느림 빠름
    systemd 지원 ✅ ✅

    이 차이 덕분에 저는 기존에 VM 5개로 돌리던 서비스를 LXC 컨테이너 12개로 확장했는데도 오히려 전체 메모리 사용량이 줄었습니다. 🎉 같은 하드웨어에서 더 많은 서비스를 돌릴 수 있게 된 거죠.

    경량 서비스 배포 측면에서 LXC 컨테이너는 정말 강력한 선택지입니다. Prometheus, Grafana, Gitea, Nextcloud 같은 서비스들 모두 LXC에서 잘 돌아가거든요.

    자주 묻는 질문 (FAQ)

    Q. LXC 컨테이너와 Docker 중 뭘 써야 하나요?
    A. 서비스 성격에 따라 다릅니다. 완전한 OS 환경이 필요하거나 systemd를 써야 하면 LXC, 앱 하나만 가볍게 격리할 거면 Docker가 적합해요. 저는 둘 다 쓰는데, LXC 안에 Docker를 넣기도 합니다.

    Q. Windows를 LXC 컨테이너로 돌릴 수 있나요?
    A. 안 됩니다. LXC는 Linux 커널 기반이라 Linux 배포판만 지원합니다. Windows는 반드시 VM으로 돌려야 해요.

    Q. LXC 컨테이너도 GPU 패스스루가 되나요?
    A. 됩니다! VM의 PCIe 패스스루보다 설정이 간단한 편이에요. 관련 내용은 다음 글에서 다룰 예정입니다.

    LXC 컨테이너와 VM의 특성 비교 요약 — 서비스 유형에 따른 최적 선택 가이드.

    마무리 — 언제 LXC를 쓰고 언제 VM을 써야 할까?

    13년간 인프라 일 하면서 내린 결론을 드리자면, 이렇게 판단합니다:

    • ✅ LXC 컨테이너 추천: 웹 서버, 데이터베이스, 모니터링 도구, 파일 서버, 홈 자동화 서버처럼 Linux 기반 서비스 단순 배포
    • ✅ VM 추천: Windows 환경, 커널 수준 격리가 필요한 경우, 다른 하이퍼바이저나 OS를 테스트할 때, 강한 보안 격리가 필요한 프로덕션 환경

    Proxmox의 진짜 장점은 이 두 가지를 같은 플랫폼에서 자유롭게 섞어 쓸 수 있다는 거예요. 저는 중요한 서비스는 VM에, 나머지 경량 서비스들은 모두 LXC 컨테이너로 돌리는 하이브리드 방식을 쓰고 있습니다.

    처음 LXC를 접하면 낯설 수 있는데, 한 번 익숙해지면 정말 못 돌아가요. 이거 진짜더라고요. 홈랩 운영하시는 분들이라면 꼭 한번 도전해보시길 권합니다!

    다음 글에서는 Proxmox LXC 컨테이너에서 GPU 패스스루 설정하는 방법을 다뤄볼 예정입니다. 궁금한 점은 댓글로 남겨주시면 답변드리겠습니다. 🎉

  • [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로만 관리하는 방식을 권장합니다.