KVM 게스트가 엔비디아 유저모드 드라이버 그대로 구동하는 virtio-nvgpu 공개, GPU 한 장을 최대 4게스트가 공유

프로젝트 자체는 진짜 대단한데 README는 솔직히 LLM이 쓴 문장 티가 너무 남. 이런 도구들은 능력은 엄청난데 글발만 보면 바로 티가 나더라.

그거 내가 쓴 건데 영어 원어민이 아니라서 GPT로 다듬었음. 문체가 어색했다면 미안함.

오버헤드를 퍼센트로만 비교한 건 좀 억지임. 전체가 느린 시스템이면 오버헤드가 작아 보일 뿐이고, 제대로 비교하려면 이걸 virtio랑 나란히 놓고 봐야지.

글만 그런 게 아님. 코드에서도 LLM 패턴이 보이는데 패키지 테스트 스위트 열어보면 특히 티가 난다.

ASCII 차트 줄이 아예 안 맞거든? 이건 만든 사람이 한 번도 렌더링 결과를 안 본 거임.

윈도우 게스트에서도 쓸 수 있나? 아직은 안 되고 로드맵에 들어있음.

gVisor nvproxy랑 뭐가 다른 거임? README에 영감을 받았다고만 써있고 왜 nvproxy를 백엔드로 안 쓰는지도 안 나와 있더라.

nvproxy 아키텍처를 많이 가져왔고, 거기서 그래픽 워크로드를 지원하도록 만든 거임. microVM에 핫플러그로 끼울 수 있어서 cloud-hypervisor나 Firecracker에서도 쓸 수 있는 게 차이점.

IOMMU 제한 없는 passthrough 상황에서 카드가 호스트에 어디까지 접근하는지 설명이 아예 없음. GPU 가상화 좀 해본 입장에서 엔비디아는 라이선스 드라이버 없이 멀티 게스트 공유하게 둘 생각이 없어서 회의적임.

그냥 vfio-pci 일반 passthrough 쓰면 되는 거 아닌가? 이 소프트웨어를 쓸 이점이 뭔지 모르겠음.

README에 최대 4게스트가 GPU를 공유한다고 나옴. 일반 passthrough는 호스트가 GPU를 통째로 잃어서 한 장이면 호스트 화면이 안 나오는데, 이건 호스트가 계속 쓰면서 게스트도 headless로 같이 쓰는 거라서.

격리는 좀 걱정됨. 냄새가 KVM/VM escape 쪽으로 난다.

KVM 게스트에 GPU 주는 방법은 대략 세 가지임. VFIO passthrough는 격리가 제일 강한 대신 게스트 하나만 쓰고 호스트 화면을 잃고, virtio-gpu는 virgl/venus로 그래픽 API를 직렬화해서 재생하니 멀티 VM은 되는데 오버헤드가 크고 NVENC 같은 저수준을 쓰려면 CPU readback 비용이 듬. virtio-nvgpu는 가짜 /dev/nvidia*가 ioctl 바이트와 핸들을 그대로 호스트로 넘겨서 근원속도가 나오는데 대신 격리가 제일 약함. ioctl이 기본적으로 전부 포워드되고 VMM이 읽기/쓰기 FD를 쥐고 seccomp, cap, 화이트리스트가 없음.

이 방식이 완전히 새로운 건 아님. virtio-gpu 쪽에 'DRM native context'라는 이름으로 이미 있던 접근이야.

나도 cgroups2랑 LXC로 비슷한 걸 해봤음. Proxmox 호스트에서 LXC에 DRM passthrough해서 모니터랑 udev 장치를 주고, 다른 스트리밍 LXC에는 cgroup으로 nvidia cuda API를 공유시켜서 로컬에서는 내가 게임하고 친구는 원격으로 같이 씀.

Nesbox도 오늘 비슷한 목적으로 올라왔는데 이건 GPU를 여러 게스트에 공유함. nestri라는 원격 데스크톱 스트리밍 킷의 하위 부품이고 아직 초보 단계임.

KVM은 만져본 정도라 잘 모르는데, '게스트 여러 대를 근원속도로' 이 use-case를 README 맨 앞 문단에 넣는 게 좋겠음. 오케이 그렇게 바꿀게.

보안은 제쳐두면 이 구조가 GPU나 canvas 지표 쓰는 봇 탐지를 얼마나 복잡하게 만들까?

윈도우 VM에 라이선스 없이 GPU 가속이 드디어 되는 건가?