USB 또는 GPU 패스스루를 사용하는 Docker 호스트에서 Proxmox LXC와 VM 중 무엇이 운영하기 더 쉬울까요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Proxmox LXC vs VM for a Docker Host With USB or GPU Passthrough: Which Is Easier to Operate? - Zima Store Online

Linux 장치 노드를 안전하게 노출할 수 있고, 호스트가 필요한 GPU 또는 USB 드라이버를 관리하며, 낮은 오버헤드나 GPU 공유가 중요하다면 Docker 호스트에 Proxmox LXC 컨테이너를 선택하세요. 게스트가 드라이버 스택을 직접 관리해야 하거나, IOMMU를 통해 PCI 장치를 격리해야 하거나, Docker와 하드웨어 액세스를 Proxmox 호스트와 독립적으로 유지해야 한다면 VM을 선택하세요. USB 직렬 장치는 두 방식 모두에 적합한 경우가 많지만, 전용 GPU 패스스루는 일반적으로 VM이 더 적합합니다.

LXC와 VM을 비교하기 전에 “패스스루” 정의하기

LXC와 KVM은 동일한 방식으로 하드웨어를 워크로드에 전달하지 않습니다. LXC 컨테이너는 Proxmox 커널을 공유하므로 일반적으로 `/dev/dri`, `/dev/ttyUSB0` 또는 `/dev/bus/usb`와 같이 호스트가 생성한 장치 노드에 액세스할 수 있는 권한을 부여받습니다. 하드웨어 감지와 커널 드라이버 로드는 여전히 호스트가 담당합니다.

VM은 자체 커널을 실행합니다. Proxmox는 USB 장치를 에뮬레이션하거나, 선택한 USB 장치 또는 포트를 연결하거나, VFIO 및 IOMMU를 통해 PCI 장치를 할당할 수 있습니다. 그러면 게스트가 자체 드라이버를 로드하고 할당된 하드웨어를 직접 설치된 장치에 가깝게 취급합니다.

현재 ZimaSpace Proxmox NAS 설정 가이드에서는 두 게스트 유형을 모두 소개합니다. 이 글에서는 컨테이너에서 USB 동글, 직렬 어댑터, 미디어 GPU 또는 컴퓨팅 가속기를 사용해야 하는 Docker 호스트로 범위를 좁혀 비교합니다.

판단 기준	Proxmox LXC 내부의 Docker	VM 내부의 Docker
커널	Proxmox 호스트 커널을 공유	독립적인 게스트 커널을 실행
USB 액세스	호스트 장치 노드와 권한을 노출	선택한 USB 장치 또는 포트를 게스트에 연결
GPU 액세스	일반적으로 호스트에 로드된 드라이버와 렌더링 장치를 공유함	VFIO를 통해 전용 PCI 장치를 할당할 수 있음
리소스 오버헤드	더 낮은 메모리 및 스토리지 오버헤드	추가 게스트 OS 메모리 및 디스크
격리	호스트 결합도가 높고 커널 경계를 공유함	더 강력한 드라이버 및 커널 분리
이식성	호환되는 호스트 장치, 드라이버, ID 및 매핑에 따라 달라집니다	게스트 드라이버 상태는 VM과 함께 이동하지만 물리적 PCI 매핑은 호스트에 종속됩니다
GPU 공유	지원되는 경우 여러 컨테이너가 동일한 호스트 렌더링 장치를 사용할 수 있습니다	전체 장치 패스스루는 일반적으로 해당 장치를 하나의 VM에 전용으로 할당합니다
최적의 선택	미디어, 직렬 USB, 공유 Linux GPU 서비스	전용 가속기, 독점 드라이버, 더 강력한 격리, 다양한 게스트 OS 요구 사항

안정적인 Linux 장치 노드처럼 작동하는 USB 장치는 LXC에 적합

USB 시리얼 어댑터, Zigbee 코디네이터, UPS 인터페이스, Coral USB 가속기 및 이와 유사한 장치는 Proxmox가 장치 노드를 노출하고 올바른 소유권을 매핑하면 LXC에서 잘 작동할 수 있습니다. 그러면 LXC 내부의 Docker 컨테이너가 Linux 호스트 환경으로부터 해당 장치를 전달받습니다.

Proxmox LXC 내부의 USB 액세스에 대한 실용적인 설명은 기본 패턴을 보여 줍니다. 컨테이너에 장치를 마운트하는 것만으로는 충분하지 않으며, 컨테이너가 해당 장치에 액세스하도록 허용하는 작업도 필요합니다.

애플리케이션이 지원한다면 `/dev/serial/by-id` 같은 안정적인 경로를 사용하세요. 재부팅이나 재연결 후 버스 번호와 `/dev/ttyUSB0` 할당이 바뀔 수 있습니다. 호스트를 업데이트할 때마다 cgroup, UID, GID 또는 장치 경로를 수동으로 복구해야 한다면 LXC 방식은 불안정해집니다.

USB 소유권을 자체적으로 완결해야 한다면 VM이 더 깔끔합니다

VM은 공급업체 및 제품 ID 또는 물리적 포트를 기준으로 USB 장치를 할당한 다음, 자체 운영 체제 안에서 장치 드라이버를 로드할 수 있습니다. 장치에 공급업체 패키지나 다른 커널 버전이 필요하거나, Proxmox 호스트 라이브러리에 의존하지 않아야 하는 애플리케이션 스택을 사용하는 경우 유용합니다.

VM은 더 명확한 진단 경계를 제공합니다. 게스트에서 USB 장치가 사라지면 관리자는 하이퍼바이저의 연결 상태와 게스트 드라이버를 각각 확인할 수 있습니다. LXC에서는 호스트 드라이버, 장치 노드, 권한, 컨테이너 매핑, Docker 런타임 및 애플리케이션이 하나의 연결 고리에 함께 관여합니다.

단점은 재연결 동작입니다. 일부 USB 장치는 게스트를 재시작하는 동안 초기화되거나, 식별 정보가 바뀌거나, 사라질 수 있습니다. 처음 한 번 정상적으로 연결되었다고 안정적인 작동이 보장된다고 가정하지 말고, 분리, 호스트 재부팅, 게스트 재부팅 및 애플리케이션 복구를 테스트하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

GPU 공유에는 대체로 LXC가 유리합니다

Intel 또는 AMD 렌더링 장치와 지원되는 NVIDIA 워크로드의 경우, LXC는 여러 Linux 서비스에 호스트 GPU 장치 노드를 노출할 수 있습니다. GPU는 Proxmox 호스트 드라이버가 계속 관리하므로, 전체 PCI 장치를 하나의 게스트에 할당하지 않고도 여러 컨테이너에서 하드웨어 트랜스코딩이나 컴퓨팅을 사용할 수 있습니다.

XDA의 최근 Proxmox 예시는 VM 패스스루로 GPU를 전용 할당하는 대신, LXC가 호스트에서 관리하는 GPU를 공유하는 방식을 설명합니다. 드라이버와 권한 요구 사항이 일치한다면 동일한 운영 모델을 Jellyfin, Plex, Frigate 또는 여러 Docker 서비스에도 적용할 수 있습니다.

공유하면 버전 간 결합이 발생합니다. 호스트 커널 드라이버, LXC 내부의 사용자 공간 라이브러리, Docker 런타임 통합, 애플리케이션 패키지가 서로 호환되는 상태를 유지해야 합니다. 따라서 Proxmox 커널이나 드라이버를 업그레이드하면 GPU를 사용하는 모든 컨테이너에 동시에 영향을 줄 수 있습니다.

독점 GPU 패스스루에는 일반적으로 VM이 유리합니다

하나의 워크로드에 개별 GPU의 직접 소유권, 독점 게스트 드라이버, Windows 지원, CUDA 격리, 또는 Proxmox에 설치하지 않아야 하는 커널 스택이 필요하다면 VM이 더 강력한 선택입니다. VFIO 할당은 장치를 호스트에서 분리하고 게스트에 제공합니다.

Proxmox의 PCI 모델은 물리적 PCI 장치를 KVM 게스트에 할당하도록 설계되었습니다. Level1Techs의 Docker 토론에서도 실질적인 차이를 확인할 수 있습니다. VM은 일반적으로 전달된 GPU를 독점적으로 사용합니다. 반면 LXC는 여러 서비스가 호스트 장치 액세스를 공유할 수 있습니다.

GPU가 mediated device 또는 SR-IOV를 지원하면 이 선택이 달라질 수 있지만, 소비자용 GPU와 홈 서버 플랫폼에는 범용적인 공유 경로가 없습니다. 전용 패스스루를 기반으로 설계하기 전에 IOMMU 그룹, 리셋 동작, 펌웨어, 디스플레이 초기화, 그리고 호스트에 해당 GPU가 필요한지 확인하세요.

LXC 내부의 Docker는 중첩된 관리 계층을 추가합니다

LXC는 이미 운영 체제 수준의 격리를 제공하고, Docker는 그 안에 또 다른 컨테이너 런타임을 추가합니다. 효율적일 수 있지만 중첩 네임스페이스, cgroups, 스토리지 드라이버, 기능, 마운트 동작이 추가됩니다. 일부 Docker 기능을 사용하려면 Proxmox 컨테이너에서 중첩 옵션이나 추가 권한이 필요합니다.

VM은 Docker에 일반적인 Linux 호스트를 제공합니다. 게스트가 자체 커널 구성을 관리하므로 Docker 문서, 커널 모듈, 방화벽 동작, 스토리지 드라이버를 더 쉽게 해석할 수 있습니다. 대신 완전한 게스트 OS, 예약 메모리, 가상 디스크 관리, 추가 패치 계층이 필요합니다.

필요한 구성이 권한 있는 컨테이너, 광범위한 장치 권한, 문서화되지 않은 호스트 수정 작업을 강제한다면, 수백 메가바이트를 절약하려고 LXC를 선택하지 마세요. 모든 업그레이드가 VM이라면 게스트 내부에 격리해 둘 예외 사항을 기억하는 데 의존하게 되는 순간, 경량 옵션의 가치가 떨어집니다.

격리와 보안에 따라 성능 우위가 뒤바뀔 수 있습니다

LXC는 호스트 커널을 공유하므로 잘못 구성된 권한 컨테이너나 지나치게 광범위한 장치 매핑으로 인해 Proxmox 노드의 의도하지 않은 영역이 더 많이 노출될 수 있습니다. 비권한 LXC, 제한적인 장치 권한, 읽기 전용 마운트 및 최소 기능을 사용하면 경계를 강화할 수 있지만, 전체 VM보다 아키텍처 간 결합도가 높은 것은 변하지 않습니다.

VM은 별도의 커널을 제공하므로 독점 GPU 스택, Docker 네트워킹, 방화벽 모듈 및 실험적 소프트웨어를 Proxmox 기반 시스템에서 격리할 수 있습니다. Docker 호스트에서 타사 이미지, 공개 서비스를 제공하는 애플리케이션, 로컬 AI 패키지 또는 잦은 드라이버 실험을 실행할 때 이러한 분리는 유용합니다.

VM이 자동으로 안전한 것은 아닙니다. PCI 패스스루, 공유 스토리지 마운트, 관리 자격 증명 및 브리지 네트워킹은 여전히 공격과 장애가 발생할 수 있는 경로를 만듭니다. 독립적인 커널과 드라이버 경계가 위협 및 유지 관리 모델을 실제로 단순화할 때 VM을 선택하세요.

백업과 마이그레이션은 서로 다른 종류의 단순성을 선호합니다

LXC 백업은 게스트에 완전한 가상 하드웨어 스택이 포함되지 않기 때문에 용량이 작고 빠릅니다. 그러나 다른 Proxmox 노드에서 하드웨어 액세스를 복원하려면 장치 노드, 그룹, 드라이버 및 권한이 일치해야 합니다. 컨테이너 파일 시스템은 마이그레이션할 수 있지만 물리 장치에 대한 연결 조건은 그대로 이전되지 않습니다.

VM 백업에는 게스트 운영 체제와 드라이버 구성이 포함되므로 애플리케이션 복구를 보다 독립적으로 수행할 수 있습니다. 대상 호스트에서 USB 연결과 PCI 주소를 다시 매핑해야 하며, 물리 장치가 하나의 노드에 종속되므로 패스스루된 GPU는 라이브 마이그레이션을 방해할 수 있습니다.

ZimaSpace의 Proxmox 백업 워크플로는 게스트 보호를 다룹니다. 이 비교에서 복구가 완료된 것으로 간주하려면 Docker가 시작되고 USB 또는 GPU에 의존하는 애플리케이션이 교체된 장치를 인식할 수 있어야 합니다.

게스트 유형을 선택하기 전에 장치 복구 테스트를 진행하세요

Docker 애플리케이션에 필요한 모든 USB 및 PCI 장치를 나열하세요.
각 장치를 호스트와 공유할지, 하나의 게스트가 전용으로 사용할지 결정하세요.
LXC에서 호스트 드라이버, 장치 노드, UID/GID 매핑 및 Docker 권한을 테스트하세요.
IOMMU 그룹화, 게스트 드라이버 설치 및 VM의 재설정 동작을 테스트하세요.
Proxmox 호스트를 재부팅하고 장치 연결이 자동으로 복구되는지 확인하세요.
백업에서 게스트를 복원하고 문서에 따라 하드웨어 매핑을 다시 생성하세요.
마이그레이션이나 하드웨어 교체가 중요하다면 호환되는 다른 노드에서 다시 테스트하세요.

게스트 오버헤드만이 아니라 애플리케이션 동작을 측정하세요. 하드웨어 트랜스코딩 안정성, USB 재연결, 드라이버 업데이트, 호스트 유지 관리 및 복구 시간은 일반적으로 LXC와 KVM 간의 작은 CPU 성능 차이보다 더 중요합니다.

Docker 호스트에는 어떤 Proxmox 게스트가 적합할까요?

LXC를 선택해야 하는 경우

모든 워크로드가 Linux 기반이고, 호스트가 드라이버를 관리할 수 있으며, USB 장치가 안정적인 노드를 노출하고, GPU를 여러 서비스에서 공유해야 한다면 LXC를 선택하세요. 가능한 경우 컨테이너를 권한 없는 상태로 유지하고 모든 장치 및 그룹 매핑을 문서화하세요.

VM을 선택해야 하는 경우

Docker 호스트에 PCI GPU 독점 소유권, 독점 또는 실험적 드라이버, 더 강력한 커널 격리 또는 전체 소프트웨어 스택의 간편한 이식성이 필요하다면 VM을 선택하세요. 게스트에 충분한 RAM과 스토리지를 할당하고 재부팅 후 장치 재설정을 테스트하세요.

워크로드를 분리해야 하는 경우

가벼운 미디어 및 USB 서비스는 LXC에서 실행하고, GPU 컴퓨팅 전용 작업, Windows 종속 도구 또는 신뢰할 수 없는 Docker 스택은 VM에 배치하세요. Proxmox를 지원하는 플랫폼은 두 가지 모두 지원할 수 있지만, 각 물리적 장치에는 문서화된 단일 소유권 모델이 있어야 합니다.

자주 묻는 질문

권한이 없는 LXC 안에서 Docker를 안정적으로 실행할 수 있나요?

많은 워크로드에서 가능합니다. 하지만 중첩 실행, 스토리지 드라이버, 마운트, 네트워킹 및 장치 액세스에는 추가 구성이 필요할 수 있습니다. 정확한 Docker 기능을 테스트하고, 원인을 알 수 없는 권한 문제를 우회하기 위해 권한 있는 컨테이너로 전환하지 마세요.

하나의 GPU를 LXC와 VM에서 모두 사용할 수 있나요?

일반적인 전체 장치 VFIO 패스스루 방식으로는 동시에 사용할 수 없습니다. LXC는 호스트가 관리하는 렌더 장치를 공유할 수 있지만, VM은 일반적으로 장치를 호스트에서 분리해야 합니다. 특정 하드웨어에서는 SR-IOV 또는 mediated-device 지원에 따라 달라질 수 있습니다.

USB Zigbee 코디네이터에는 어떤 옵션이 더 나을까요?

둘 다 사용할 수 있습니다. 안정적인 serial-by-ID 경로와 권한이 확실하다면 LXC가 효율적입니다. 코디네이터의 소프트웨어 스택이나 드라이버를 Proxmox 호스트와 독립적으로 유지해야 한다면 VM이 더 깔끔합니다.

최종 결론

USB와 GPU 리소스를 Proxmox 호스트의 Linux 드라이버 스택을 통해 공유할 수 있고 오버헤드가 낮아야 한다면 Docker 호스트에 LXC를 사용하세요. 하드웨어를 게스트에 전용으로 할당해야 하거나, 드라이버를 격리해야 하거나, 복구 시 자체적으로 완결된 운영 체제를 유지해야 한다면 VM을 사용하세요. 컨테이너가 항상 더 간단하다고 가정하지 말고, 장치 소유권과 복원 동작을 기준으로 선택하세요.