13년차의 서버실

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

[태그:] 가상 머신 성능

  • [OpenStack] OpenStack Nova 성능 최적화: CPU 스케줄링 및 리소스 할당 분석

    [OpenStack] OpenStack Nova 성능 최적화: CPU 스케줄링 및 리소스 할당 분석

    목차

    [OpenStack] OpenStack Nova 성능 최적화: CPU 스케줄링 및 리소스 할당 분석

    OpenStack Nova 성능 최적화 이야기는 결국 운영하면서 한 번쯤 꼭 부딪히는 문제로 이어집니다. 가상 머신은 충분히 띄웠는데, 어떤 인스턴스는 반응이 빠르고 어떤 인스턴스는 같은 flavor(플레이버, 가상 머신 자원 정의)인데도 체감 성능이 들쭉날쭉하거든요. 저도 처음엔 “스토리지가 느린가?” 하고 엉뚱한 데를 먼저 봤었는데, 실제로 파고 들어가 보니 Nova CPU 스케줄링과 리소스 할당 방식이 병목의 핵심인 경우가 많았습니다. 특히 benchmark(벤치마크, 성능 측정) 결과를 비교할 때 CPU 오버커밋(overcommit, 실제 물리 자원보다 더 많이 논리 할당)과 NUMA(Non-Uniform Memory Access, 메모리 접근 거리가 다른 구조) 인식 여부가 결과를 꽤 크게 흔들더라고요.

    이번 글에서는 제가 홈랩과 테스트 환경에서 반복적으로 확인했던 관찰 포인트를 기준으로, OpenStack Nova 성능 최적화를 어디서부터 봐야 하는지 정리해보겠습니다. 숫자를 지어내거나 과장된 벤치마크를 보여드리기보다는, 무엇을 설정하고 무엇을 검증해야 재현 가능한 성능 분석이 되는지에 초점을 맞추겠습니다.

    Nova 스케줄러와 컴퓨트 노드, 하이퍼바이저, NUMA 토폴로지 관계를 한눈에 보여주는 개요 이미지입니다.

    1. 왜 OpenStack Nova 성능 최적화가 생각보다 까다로운가

    쉽게 말해 Nova는 “가상 머신을 어디에 올릴지”만 결정하는 도구가 아닙니다. CPU pinning(피닝, vCPU를 특정 pCPU에 고정), emulator thread(에뮬레이터 스레드), huge page(휴즈페이지, 큰 메모리 페이지), NUMA topology(토폴로지, 자원 배치 구조) 같은 요소가 다 엮여 있습니다. 그래서 표면적으로는 인스턴스 생성이 잘 되더라도, 실제 가상 머신 성능은 스케줄링 정책에 따라 크게 달라질 수 있습니다.

    제가 직접 해보니 가장 흔한 착각은 이겁니다. “vCPU 개수만 맞으면 성능도 비슷하겠지”라는 생각이요. 근데 현실은 그렇지 않더라고요. 같은 4 vCPU 인스턴스라도 어느 소켓(socket, CPU 패키지) 위에 배치됐는지, 이웃한 워크로드가 얼마나 시끄러운지(noisy neighbor, 자원 경쟁을 유발하는 인접 워크로드), CPU 공유 정책이 어떤지에 따라 결과가 달라집니다.

    • CPU overcommit ratio가 높으면 밀도는 올라가지만 지연 시간이 튈 수 있습니다.
    • Dedicated CPU policy를 쓰면 예측 가능성은 좋아지지만 수용량은 줄어듭니다.
    • NUMA mismatch가 나면 메모리 접근 비용이 늘어나 체감 성능이 떨어질 수 있습니다.
    • Benchmark 결과는 테스트 시간대와 이웃 인스턴스 상태에 따라서도 흔들립니다.

    2. Nova CPU 스케줄링 개념, 쉽게 말해 이런 구조입니다

    여기서 중요한 포인트! Nova CPU 스케줄링은 단순한 라운드로빈(round-robin, 순환 배치)이 아닙니다. 스케줄러는 호스트 필터(filter, 후보 선별 규칙)와 weighers(가중치 계산기)를 사용해서 컴퓨트 노드를 고릅니다. 그 다음 실제 하이퍼바이저 계층에서 vCPU와 pCPU 관계가 정해지죠.

    2-1. Shared CPU와 Dedicated CPU 차이

    구분 설명 장점 주의점
    Shared CPU 여러 VM이 물리 CPU 시간을 공유 집적도 높음 성능 편차 가능
    Dedicated CPU 특정 pCPU를 인스턴스에 고정 할당 예측 가능한 성능 운영 유연성 감소
    CPU Pinning vCPU를 지정 코어에 매핑 지터 감소 NUMA 설계 필요

    실제로 써보니까 데이터베이스나 NFV(Network Functions Virtualization, 네트워크 기능 가상화)처럼 지연 시간에 민감한 워크로드는 Shared CPU보다 Dedicated CPU 쪽이 훨씬 해석하기 편했습니다. 반대로 일반 웹 애플리케이션은 적당한 오버커밋이 더 경제적일 때가 많았고요.

    2-2. 리소스 할당에서 꼭 같이 봐야 할 요소

    • vCPU allocation ratio: 논리적으로 얼마나 더 많이 잡을지
    • RAM allocation ratio: 메모리 과할당 정책
    • Reserved host memory: 호스트 OS와 에이전트가 쓸 여유 공간
    • NUMA affinity: CPU와 메모리 지역성 유지
    • Huge pages: TLB 부담 감소에 유리

    저도 처음엔 헷갈렸는데, CPU만 최적화하면 끝이 아니더라고요. 메모리 배치가 틀어지면 CPU pinning을 해도 기대만큼 안 나오는 경우가 있습니다.

    3. 실전 기준선 만들기: benchmark 전에 먼저 해야 할 것

    OpenStack Nova 성능 최적화를 하겠다고 바로 설정부터 바꾸면 나중에 비교가 안 됩니다. 삽질 좀 했습니다 ㅎㅎ 결국 가장 먼저 해야 하는 건 기준선(baseline, 비교 기준)을 만드는 일입니다.

    1. 테스트 대상 flavor를 고정합니다.
    2. 테스트용 이미지와 커널 상태를 동일하게 맞춥니다.
    3. 동일한 시간대에 반복 실행합니다.
    4. 가능하면 noisy neighbor 영향을 줄인 별도 호스트를 씁니다.
    5. 인스턴스 내부 지표와 호스트 지표를 같이 수집합니다.

    제가 권장하는 최소 수집 항목은 아래 정도입니다.

    # Compute node
lscpu
numactl --hardware
virsh vcpuinfo INSTANCE_DOMAIN
virsh emulatorpin INSTANCE_DOMAIN
virsh dumpxml INSTANCE_DOMAIN

# Guest VM
grep -E 'processor|physical id|core id' /proc/cpuinfo
lscpu
uptime
mpstat -P ALL 1 5

    이 정도만 모아도 “스케줄링은 잘 됐는지”, “게스트가 기대한 토폴로지를 보고 있는지” 정도는 꽤 빨리 감이 옵니다.

    4. Nova CPU 스케줄링 설정 확인 포인트

    이제 본론입니다. Nova CPU 스케줄링과 리소스 할당을 볼 때 저는 보통 nova.conf의 CPU 정책부터 확인합니다. 환경마다 값은 다를 수 있지만, 아래와 같은 항목들이 자주 등장합니다.

    [DEFAULT]
cpu_allocation_ratio=4.0
ram_allocation_ratio=1.0
reserved_host_memory_mb=4096

[compute]
cpu_shared_set=2-15
cpu_dedicated_set=16-31

[libvirt]
virt_type=kvm
emulator_threads_policy=share

    위 예시는 구조 설명용입니다. 특정 값이 정답이라는 뜻은 아닙니다. 다만 운영 의도는 분명해야 합니다. 예를 들어 cpu_shared_set와 cpu_dedicated_set를 섞어서 쓴다면, 어떤 워크로드를 공유형으로 둘지, 어떤 워크로드를 전용형으로 둘지 먼저 정해야 하거든요.

    중요한 건 설정 파일의 숫자보다 정책 일관성입니다. 한 호스트는 전용 CPU 정책, 다른 호스트는 공유 정책인데 같은 aggregate(집합, 스케줄링 그룹)로 묶여 있으면 benchmark 결과가 해석 불가능해질 수 있습니다.

    OpenStack Nova 성능 최적화 설정에서 CPU 정책과 NUMA 배치를 설명하는 이미지

    공유 CPU 세트, 전용 CPU 세트, 에뮬레이터 스레드 정책이 어떻게 나뉘는지 보여주는 설정 이미지입니다.

    5. 리소스 할당 전략: 워크로드별로 다르게 가져가야 합니다

    이 부분이 현업에서 진짜 중요합니다. 모든 인스턴스에 같은 정책을 적용하면 편하긴 한데, 성능과 밀도 둘 다 애매해지기 쉽습니다.

    5-1. 일반 웹/배치 워크로드

    • Shared CPU 기반 운영이 보통 효율적입니다.
    • 적절한 오버커밋으로 집적도를 높일 수 있습니다.
    • 대신 benchmark는 피크 시간과 비피크 시간을 나눠 봐야 합니다.

    5-2. DB, 메시지 큐, 지연 민감 서비스

    • Dedicated CPU 또는 CPU pinning 검토가 필요합니다.
    • NUMA 정렬과 huge page를 함께 보는 편이 좋습니다.
    • 가상 머신 성능 비교 시 평균값보다 tail latency(꼬리 지연)를 더 중시해야 합니다.

    5-3. 혼합 클러스터 운영 팁

    제 경험상 host aggregate(호스트 애그리게이트)와 flavor extra spec(플레이버 추가 속성)을 같이 쓰는 방식이 운영 설명력이 좋았습니다. 예를 들면 성능형 호스트 풀과 일반형 호스트 풀을 나누고, 성능형 flavor만 전용 CPU 정책으로 보내는 식이죠.

    openstack flavor set perf.large \
  --property hw:cpu_policy=dedicated \
  --property hw:mem_page_size=large

openstack flavor set general.medium \
  --property hw:cpu_policy=shared

    이렇게 해두면 나중에 문제 생겼을 때 추적이 쉬워집니다. “왜 이 인스턴스는 빠르지?” 혹은 “왜 이건 느리지?”를 설명할 근거가 남거든요.

    6. ⚠️ 실제로 자주 겪는 트러블슈팅

    여기서는 제가 실제로 많이 부딪혔던 문제 위주로 적어보겠습니다. 문서만 보면 단순해 보이는데, 현장에서는 꼭 꼬입니다.

    6-1. Pinning은 했는데 성능이 기대보다 안 나오는 경우

    가장 먼저 NUMA 배치를 의심해보세요. vCPU는 한 소켓 쪽에 몰렸는데 메모리는 다른 NUMA 노드에서 잡히면 메모리 접근이 꼬일 수 있습니다. 이럴 때는 인스턴스 XML과 호스트 NUMA 정보를 같이 확인해야 합니다.

    virsh dumpxml INSTANCE_DOMAIN | grep -i -E 'numa|vcpu|cputune|emulatorpin'
numactl --hardware

    6-2. 동일한 벤치마크인데 결과 편차가 큰 경우

    이건 noisy neighbor 가능성이 큽니다. 특히 공유형 CPU 정책에서는 배치 타이밍에 따라 차이가 꽤 납니다. 저도 처음엔 테스트 툴 문제인 줄 알았는데, 같은 호스트에 다른 VM이 CPU burst를 치고 있었더라고요.

    6-3. 호스트는 여유 있는데 스케줄링이 실패하는 경우

    Placement(플레이스먼트, 자원 추적 및 배치 서비스) 관점에서 자원 클래스(resource class, 자원 분류)나 trait(특성)이 안 맞는 경우가 있습니다. 숫자상 여유와 스케줄링 가능 여부는 다를 수 있습니다. 그래서 단순히 top만 보는 식으로는 원인 파악이 안 됩니다.

    6-4. 에뮬레이터 스레드가 의외의 병목이 되는 경우

    이거 놓치기 쉽습니다. 전용 CPU만 신경 쓰다가 emulator thread가 같은 코어에 얹혀서 변동성이 생기기도 하거든요. 성능 민감 워크로드라면 이 부분도 꼭 확인해보세요.

    OpenStack Nova 성능 최적화 트러블슈팅과 벤치마크 편차 분석 이미지

    vCPU pinning, NUMA 노드, noisy neighbor 분석 지표를 함께 보는 트러블슈팅 예시 이미지입니다.

    7. 검증은 이렇게 합니다: 가상 머신 성능 확인 절차

    설정 바꾸고 느낌상 빨라진 것 같다고 끝내면 안 됩니다. 검증 절차를 남겨야 다음 변경 때도 비교가 되거든요. 저는 보통 아래 순서로 봅니다.

    1. 호스트 토폴로지 확인
    2. 인스턴스 배치 정책 확인
    3. 게스트 내부 CPU 인식 상태 확인
    4. 동일 조건으로 benchmark 반복 실행
    5. 평균값보다 편차와 최저 구간을 함께 비교
    # Example benchmark flow inside guest
stress-ng --cpu 4 --timeout 60s --metrics-brief
sysbench cpu --threads=4 run

    여기서 조심할 점은, 특정 툴의 점수 자체보다 반복 실행 시 일관성입니다. OpenStack Nova 성능 최적화가 잘 된 환경은 최고점만 높은 게 아니라, 여러 번 돌려도 편차가 상대적으로 줄어드는 경우가 많았습니다.

    검증 항목 좋은 신호 경계 신호
    CPU 사용률 분포 예상 코어에 집중 임의 분산, 잦은 변동
    Benchmark 반복성 결과 편차 작음 실행마다 차이 큼
    NUMA 정렬 CPU/메모리 지역성 유지 원격 메모리 접근 증가
    호스트 안정성 예약 자원 충분 호스트 자체가 바쁨

    드디어 됐다! 싶었던 순간도 사실 이런 표를 정리한 뒤에야 왔습니다. 그냥 체감이 아니라, 왜 결과가 좋아졌는지 설명이 되어야 다음 운영 변경에도 자신이 생기더라고요.

    OpenStack Nova 성능 최적화 전후 가상 머신 성능 비교 대시보드 이미지

    반복 벤치마크 결과의 편차 감소와 CPU 배치 안정성을 비교하는 결과 시각화 이미지입니다.

    8. 정리와 다음 단계: 무엇부터 손대면 좋을까

    정리해보면 OpenStack Nova 성능 최적화는 결국 세 가지입니다. 정책을 분리하고, 배치를 검증하고, 결과를 반복 측정하는 것이죠. Nova CPU 스케줄링은 단순 옵션 튜닝이 아니라, 워크로드 성격에 맞는 리소스 할당 전략을 설계하는 일에 가깝습니다.

    • 일반 워크로드는 공유 정책과 적절한 오버커밋으로 효율을 봅니다.
    • 민감한 워크로드는 전용 CPU, NUMA 정렬, 메모리 정책을 같이 봅니다.
    • 가상 머신 성능 평가는 평균 점수보다 재현성과 편차를 함께 봐야 합니다.
    • 벤치마크는 반드시 배치 정보와 같이 기록해야 의미가 있습니다.

    혹시 이런 경험 있으신가요? 분명 스펙은 같은데 어떤 VM만 유독 느린 상황이요. 그런 경우라면 애플리케이션을 의심하기 전에 CPU 정책과 배치 상태부터 보시는 걸 추천드립니다. 생각보다 거기서 답이 나오는 경우가 많거든요.

    다음 글에서는 Placement와 flavor extra spec을 조금 더 깊게 들어가서, 스케줄링 의도를 어떻게 코드처럼 관리할지 다뤄볼 예정입니다. 이전 글에서 다뤘던 가상화 호스트 기본 점검 내용과 함께 보시면 흐름이 더 잘 잡히실 겁니다.

    OpenStack Nova 성능 최적화 운영 체크리스트와 CPU 정책 요약 이미지

    공유 CPU와 전용 CPU 선택 기준, NUMA 체크포인트, 검증 절차를 요약한 인포그래픽 이미지입니다.

    자주 묻는 질문

    Q1. CPU overcommit을 무조건 낮추면 성능이 좋아지나요?

    항상 그렇진 않습니다. 집적도가 너무 낮아져 운영 효율이 떨어질 수 있고, 워크로드 특성상 공유 정책으로도 충분한 경우가 있습니다.

    Q2. Nova CPU 스케줄링만 조정하면 끝인가요?

    아닙니다. libvirt 설정, NUMA 구조, 메모리 정책, 게스트 OS 튜닝까지 함께 봐야 합니다.

    Q3. benchmark 결과가 매번 다르면 무엇부터 확인해야 하나요?

    테스트 시간대, noisy neighbor, 배치 호스트, NUMA 정렬, 에뮬레이터 스레드 정책 순으로 점검해보시면 됩니다.

  • [Proxmox] GPU 패스스루: 가상 머신 성능 문제 디버깅하기

    [Proxmox] GPU 패스스루: 가상 머신 성능 문제 디버깅하기

    목차

    [Proxmox] GPU 패스스루: 가상 머신 성능 문제 디버깅하기

    안녕하세요! 13년차의 서버실, 인프라 엔지니어 박 사장입니다. 오늘은 제가 홈랩에서 정말 많이 삽질했던 경험 중 하나인 Proxmox GPU 패스스루(Passthrough)에 대한 이야기를 해볼까 합니다. 다들 설레는 마음으로 Proxmox에 GPU 패스스루를 세팅하고, 가상 머신(VM)을 켰는데, 웬걸? 생각보다 성능이 안 나와서 당황한 경험 있으신가요? 저도 처음엔 이게 뭔가 싶어서 밤샘 디버깅을 밥 먹듯이 했었거든요. 오늘은 그 삽질의 결과물, 즉 GPU 패스스루 시 겪을 수 있는 성능 문제와 그 해결 과정을 멘토처럼 알려드리겠습니다. ⚠️ 특히 NVIDIA Error 43 같은 골치 아픈 문제 해결 팁도 있으니 끝까지 주목해주세요!

    Proxmox에서 GPU 패스스루를 구현했을 때의 전체적인 아키텍처를 시각화한 다이어그램이에요. 호스트와 게스트 OS 간의 GPU 자원 전달 과정이 어떻게 흘러가는지 한눈에 볼 수 있습니다.

    💡 Proxmox GPU 패스스루와 VFIO, 왜 중요할까요?

    Proxmox GPU 패스스루(Passthrough)는 쉽게 말해 물리적인 서버에 꽂힌 GPU(그래픽 처리 장치)를 가상 머신(VM, Virtual Machine)에 통째로 할당해주는 기술입니다. 호스트 OS(Proxmox가 설치된 리눅스)는 해당 GPU에 대한 제어권을 내려놓고, 그 제어권을 게스트 OS(VM 내부의 Windows나 Linux)가 직접 가져가서 사용하게 하는 거죠. 이렇게 하면 가상 환경에서도 물리 GPU의 성능을 거의 그대로 활용할 수 있게 됩니다. 게임 서버, AI 학습, 미디어 트랜스코딩 등 고성능 그래픽 처리가 필요한 작업에 필수적이죠.

    이 기술의 핵심에는 VFIO (Virtual Function I/O)라는 프레임워크가 있습니다. VFIO는 호스트 OS가 특정 하드웨어 장치(여기서는 GPU)에 대한 제어권을 포기하고, 그 제어권을 게스트 OS가 직접 가져갈 수 있도록 해주는 메커니즘을 제공합니다. 덕분에 게스트 OS는 GPU를 마치 물리 머신에 직접 연결된 것처럼 사용할 수 있게 되는 겁니다. 저도 처음엔 이 VFIO 개념이 좀 헷갈렸는데, 쉽게 생각하면 ‘직통 연결 통로’를 만들어주는 거라고 보시면 돼요.

    문제는 이 과정이 생각보다 복잡하고, 작은 설정 실수 하나로 성능 저하나 오류가 발생할 수 있다는 겁니다. 특히 Proxmox GPU 패스스루를 하려는 분들이 가장 많이 겪는 문제가 바로 ‘설정은 다 했는데 왜 성능이 안 나오지?’ 하는 부분이죠.

    🛠️ 기본적인 Proxmox GPU 패스스루 설정 요약

    사실 Proxmox에서 GPU 패스스루를 위한 기본적인 설정(BIOS에서 IOMMU 활성화, vfio 모듈 활성화, 커널 매개변수 추가 등)은 다른 좋은 자료들이 많으니 여기서는 간략히 언급하고 넘어가겠습니다. 오늘은 이미 기본적인 세팅은 마쳤다는 가정하에, 성능 문제 디버깅에 집중할 거거든요.

    1. BIOS/UEFI 설정: IOMMU (Intel VT-d 또는 AMD-Vi) 기능을 반드시 활성화해야 합니다. 이게 안 되면 VFIO 자체가 작동하지 않아요.
    2. 커널 모듈 활성화: vfio, vfio_iommu_type1, vfio_pci 등의 모듈을 로드하고, 블랙리스트에 GPU 드라이버(nouveau, amdgpu, nvidia)를 추가해 호스트 OS가 GPU를 점유하지 않도록 합니다.
    3. GPU ID 확인 및 격리: lspci -nns [PCI ID] 등으로 GPU의 Vendor ID와 Device ID를 확인하고, /etc/modprobe.d/vfio.conf 파일에 해당 ID를 추가하여 VFIO 모듈이 GPU를 독점하도록 설정합니다.
    4. VM 설정 변경: Proxmox 웹 UI에서 VM 하드웨어에 PCI Device로 GPU를 추가하고, 필요한 경우 Primary GPU 옵션이나 ROM-Bar 옵션을 활성화합니다.

    여기까지 했는데도 문제가 생겼다면, 이제부터가 진짜 디버깅의 시작입니다!

    Proxmox 가상 머신에 PCI 장치(GPU) 추가 설정 화면

    Proxmox 웹 UI에서 가상 머신에 PCI 장치(GPU)를 추가하는 설정 화면이에요. 이 화면에서 어떤 GPU를 선택하고 어떤 옵션을 적용할지 결정하게 됩니다.

    ⚠️ Proxmox GPU 패스스루 성능 문제 디버깅하기

    1. NVIDIA Error 43: 가장 흔하고 짜증나는 문제!

    제가 Proxmox GPU 패스스루를 하면서 제일 많이 삽질했던 부분이 바로 이 NVIDIA Error 43입니다. Windows VM에서 장치 관리자를 열었을 때 그래픽 카드에 느낌표가 뜨면서 Code 43 오류가 발생하면 정말 미쳐버리죠. 드라이버 문제인 줄 알고 온갖 버전을 다 깔아봤는데도 안 됐었거든요.

    원인: NVIDIA 드라이버가 가상 환경에서 실행 중임을 감지하고 기능을 제한해버린다는 거예요. 일종의 ‘가상화 감지’ 보호 메커니즘이죠.

    해결책:

    1. KVM 가상화 숨기기 (VM 설정): Proxmox가 KVM이라는 하이퍼바이저를 사용하고 있다는 사실을 게스트 OS에 숨겨야 합니다. VM 설정을 통해 QEMU 인자를 추가해줍니다.
      2. 
qm set [VMID] -args '-cpu host,kvm=off,hv_vendor_id=null'
# 예시: qm set 100 -args '-cpu host,kvm=off,hv_vendor_id=null'

      여기서 [VMID]는 여러분의 가상 머신 ID예요. kvm=off는 KVM 기능을 비활성화하는 것이 아니라, KVM 하이퍼바이저가 존재한다는 사실을 게스트 OS에 알리지 않는 역할을 합니다. hv_vendor_id=null은 하이퍼바이저 벤더 ID를 숨깁니다.

    2. KVM MSR(Model Specific Register) 무시 (호스트 설정): 호스트에서 KVM 모듈에 특정 MSR을 무시하도록 지시하여 가상화 감지를 더 어렵게 만듭니다.
      3. 
echo "options kvm ignore_msrs=1" > /etc/modprobe.d/kvm.conf
update-initramfs -u -k all
reboot

      이 설정을 추가하고 update-initramfs로 initramfs를 업데이트한 뒤 재부팅하면, 게스트 OS가 가상 환경임을 감지하기가 정말 어려워진다는 거죠. 저도 이 방법을 쓰고 나서야 드디어 Error 43에서 벗어날 수 있었어요! 🎉

    2. IOMMU 그룹 분리 문제: 장치가 제대로 격리되지 않을 때

    IOMMU (Input/Output Memory Management Unit) 그룹은 패스스루의 근간입니다. IOMMU 그룹이 제대로 분리되지 않으면, 패스스루하려는 GPU와 다른 장치들이 같은 그룹에 묶여 있어 패스스루 자체가 안 되거나, 안정성 문제가 생기거든요.

    확인 방법:

    
find /sys/kernel/iommu_groups/ -type l
# 또는 특정 장치의 IOMMU 그룹 확인
lspci -nnv | grep -i "VGA compatible controller"

    만약 GPU와 다른 중요한 장치(예: SATA 컨트롤러)가 같은 그룹에 묶여 있다면 문제가 됩니다.

    해결책:

    • PCIe 슬롯 변경: 물리적으로 GPU를 다른 PCIe 슬롯에 꽂아보세요. 간혹 슬롯에 따라 IOMMU 그룹이 달라지는 경우가 있습니다.
    • PCIe ACS Override 패치: Proxmox 호스트의 커널에 PCIe ACS Override 패치를 적용하는 방법이 있습니다. 이 패치는 IOMMU 그룹을 강제로 분리시키는 역할을 하지만, 시스템의 안정성을 해칠 수 있으므로 ⚠️ 주의해서 사용해야 합니다. 저도 정말 최후의 수단으로 사용했던 기억이 있네요.

    3. 성능 저하 (병목 현상): 할당 리소스 점검

    Error 43은 해결했지만 막상 게임이나 AI 학습을 돌려보니 성능이 기대에 못 미친다면, 리소스 할당이나 설정 최적화를 의심해봐야 합니다.

    • PCIe 슬롯 대역폭: 혹시 GPU를 낮은 대역폭의 PCIe 슬롯(예: x16 대신 x8, x4)에 꽂은 건 아닌지 확인해보세요. 대역폭이 충분하지 않으면 GPU 성능을 100% 활용하기 어렵습니다. 메인보드 매뉴얼을 확인하는 게 가장 정확합니다.
    • CPU 코어/스레드 할당: VM에 충분한 CPU 코어와 스레드를 할당했는지 확인해야 합니다. VM에 CPU 코어를 너무 적게 주면 GPU가 아무리 좋아도 병목이 생겨요. 보통 물리 코어 수의 절반 이상을 할당하는 것이 좋습니다.
    • RAM 할당: VRAM(GPU 자체 메모리) 외에 VM에 할당된 시스템 RAM도 중요합니다. 특히 고사양 게임이나 AI 학습 시에는 충분한 RAM이 필수적입니다.
    • QEMU/KVM 최적화 옵션: VM 설정에서 QEMU 인자를 추가하여 성능을 최적화할 수 있습니다.
      • 
qm set [VMID] -args '-cpu host,hv_time,hv_vapic,hv_spinlocks=0x1fff,hv_relaxed,hv_reset,hv_vpindex,hv_runtime,hv_synic,hv_stimer,hv_ipi,hv_eoi,pv_unhalt,kvm=off,l3-cache=on'

      이 옵션들은 KVM의 하이퍼바이저 기능을 최적화하여 게스트 OS의 성능을 향상시키는 데 도움을 줍니다. l3-cache=on은 L3 캐시를 활성화하여 CPU 성능에 긍정적인 영향을 줍니다.

    • Display Output (VMware/SPICE) 비활성화: Proxmox GPU 패스스루를 사용하는 경우, VM의 디스플레이 장치로 VMware나 SPICE 같은 가상 디스플레이를 켜두면 충돌하거나 불필요한 오버헤드가 생길 수 있습니다. 패스스루한 GPU를 유일한 디스플레이 장치로 설정하고, 다른 가상 디스플레이는 모두 끄는 것이 좋습니다.

    4. 사운드 장치 패스스루: HDMI 오디오도 잊지 마세요!

    대부분의 최신 그래픽 카드에는 HDMI나 DisplayPort를 통한 오디오 출력 기능이 내장되어 있습니다. Proxmox GPU 패스스루를 할 때 이 오디오 장치를 함께 패스스루하지 않으면, VM에서 소리가 안 나오거나 문제가 발생할 수 있습니다.

    확인 및 해결:

    1. lspci -nnv | grep -i audio 명령어로 GPU에 연결된 오디오 장치의 ID를 확인합니다.
    2. GPU의 비디오 장치와 오디오 장치가 같은 IOMMU 그룹에 속해 있는지 확인합니다. 대부분은 같은 그룹에 있습니다.
    3. VM 설정에서 GPU의 비디오 장치와 함께 오디오 장치도 PCI Device로 추가해줍니다. 이 두 장치를 모두 한 VM에 할당해야 정상적으로 소리가 나옵니다.

    ✅ 검증 및 결과 확인

    모든 설정을 마치고 디버깅까지 끝냈다면, 이제 Proxmox GPU 패스스루가 제대로 작동하는지 확인해볼 차례입니다. 게스트 OS에 접속해서 다음을 확인해보세요.

    • 장치 관리자 (Windows) / nvidia-smi (Linux): GPU가 정상적으로 인식되고 드라이버가 잘 설치되었는지 확인합니다. 더 이상 느낌표나 오류 코드가 없어야 합니다.
    • 벤치마크 툴: 3DMark, FurMark, Unigine Heaven/Superposition 같은 벤치마크 툴을 실행하여 GPU의 실제 성능을 측정해봅니다. 예상했던 성능 수치가 나오는지 확인하는 것이 중요합니다.
    • 실제 사용: 게임을 돌려보거나, AI 학습 스크립트를 실행해 보면서 체감 성능을 확인합니다.

    드디어 제대로 된 성능이 나오는 걸 보면 그렇게 뿌듯할 수가 없어요! 🎉 그동안의 삽질이 보상받는 느낌이랄까요? 저도 처음엔 수많은 시행착오를 겪었지만, 하나씩 문제를 해결해나가는 과정이 결국 저의 경험치를 올려주더라고요.

    Proxmox GPU 패스스루 후 게스트 OS 벤치마크 결과

    가상 머신 내부에서 실행된 벤치마크 프로그램의 결과 화면이에요. 패스스루된 GPU가 정상적으로 작동하면서 기대하던 성능을 제대로 내고 있는 모습을 볼 수 있습니다.

    마무리하며: 삽질은 경험치를 올려주는 최고의 자산!

    오늘은 Proxmox GPU 패스스루 설정 후 가상 머신에서 발생할 수 있는 성능 문제들을 디버깅하는 저의 경험을 공유해드렸습니다. 특히 NVIDIA Error 43과 같은 고질적인 문제부터 IOMMU 그룹 분리, 그리고 리소스 할당 최적화까지 다양한 관점에서 살펴봤는데요. 사실 이 모든 과정이 결코 쉽지는 않았습니다. 저도 수많은 밤을 새워가며 구글링하고, 포럼을 뒤적이며 해결책을 찾아다녔으니까요. 😅

    하지만 결국 이런 ‘삽질’들이 쌓여서 지금의 제가 될 수 있었다고 생각합니다. 단순히 기술을 적용하는 것을 넘어, 문제가 생겼을 때 스스로 해결할 수 있는 능력이 인프라 엔지니어에게는 가장 중요한 자산이거든요. 혹시 여러분도 Proxmox VFIO-PCI 설정에 어려움을 겪고 있다면, 오늘 제가 알려드린 팁들이 도움이 되었으면 좋겠습니다.

    다음번엔 오늘 다룬 Proxmox 그래픽 카드 패스스루를 활용해서 홈랩에 AI/머신러닝 작업 환경을 구축하는 방법에 대해 이야기해볼까 합니다. 그때까지 여러분의 서버실에 평화가 가득하기를 바랍니다! 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 제가 아는 선에서 최대한 도와드리겠습니다.

    Proxmox GPU 패스스루 문제 해결을 위한 디버깅 흐름도

    Proxmox GPU 패스스루 설정 시 발생할 수 있는 주요 문제점과 그 해결책을 시각적으로 정리한 흐름도예요. 디버깅 과정에서 어떤 순서로 체크해야 할지 한눈에 알 수 있게 정리했습니다.