Reindert Pelsma claims nvkvm-pv lets multiple QEMU/KVM guests run stock CUDA and Vulkan by forwarding NVIDIA driver ioctls while the host retains use of the same GPU, potentially enabling shared virtualized AI compute without dedicated GPU passthrough.
state: corroboratedheat: lowuncertainty: highconvergesscott: mediumgpu-virtualization local-inference ai-infrastructureReindert PelsmaNVIDIA
What is this?
nvkvm-pv is an unvalidated Show HN project (Reindert Pelsma, Sept 2026) claiming multiple QEMU/KVM guests can run stock CUDA and Vulkan by forwarding the NVIDIA driver's ioctl surface while the host keeps using the same GPU; the only on-file evidence is the creator's own GitHub testimony (an echo, not scraped), and none of the supplied web results mention the project at all. What the web material does establish is the surrounding landscape: the incumbent approach is whole-GPU VFIO passthrough, which dedicates the card to a single guest and carries well-documented friction, while API-forwarding alternatives have a long lineage (Google/Collabora's Venus Vulkan driver on VirtIO-GPU, virglrenderer, qemu-3dfx) and driver-interface forwarding has production prior art in gVisor's nvproxy. Since the case opened, two independent implementations of shared-GPU virtualization have surfaced — virtio-nvgpu (near-native NVIDIA access inside KVM guests, naming nvproxy as direct inspiration) and Nesbox (microVM with GPU sharing) — which corroborates the shared-virtualized-GPU-compute pattern without validating nvkvm-pv specifically. Isolation guarantees, concurrent-workload performance versus passthrough or API remoting, host retention under load, and guest OS coverage remain unmeasured across all of these projects.
Why it matters to Scott
Converges with his sandboxed-execution canon, which already names nvproxy-style driver-interface forwarding as the isolation-preserving route to GPU access and weighs GPU-virtualization-vs-passthrough tradeoffs — virtio-nvgpu and Nesbox independently extend that mechanism class from gVisor sandboxes to KVM guests and microVMs, with virtio-nvgpu citing nvproxy directly. It bears on active territory: gamepc's model zoo gains a candidate alternative to passthrough for VM-isolated inference, and shared-GPU virtualization is a structural alternative to his singleton-GPU-job-queue answer to contention. Still medium, not high: the pattern is corroborated but nvkvm-pv itself remains creator testimony, isolation guarantees and concurrent-workload performance are unmeasured across all three projects, and nothing here would change what he deploys yet — an evaluation lead with a dated-receipts angle for his containment writing, not an adoption case.
ip:concept.sandboxed-executiondev:project.gamepcdev:concept.hardware-aware-local-inferencedev:concept.singleton-gpu-job-queuedev:technology.cudaradar:concept.gpu-infrastructureradar:concept.gpu-securityradar:cua-macos-vm-gpu-passthroughradar:concept.microvmsradar:nvidia-rtx-pro-5500-84gb
queries asked of Scott's wikis
- sandbox GPU access for agent code execution
- ioctl forwarding driver surface as isolation mechanism gVisor nvproxy
- local inference multi-tenant GPU sharing economics
- model zoo deployment local hardware gamepc
- GPU virtualization vs passthrough tradeoffs
- self-hosted inference GPU utilization idle cost
Measured heat
now 0 pts/hpeak 0 pts/hcomments 0/hpeers p14momentum: steady2 platformsage 796h
points/hour across evidence · reading as of 2026-10-12 02:59:37.977291+11:00 · deterministic, not a model opinion
How the heat travelled
pace: p78 vs 519 stories at the 720h mark (now 796h old) — ahead of llama-cpp-hot-expert-offload (1.0x), behind experiential-open-model-gateway (1.0x)
Evidence (4) — ⭐ canonical anchor
Interpretation history
2026-09-25T19:07:19Z
The virtio-nvgpu attention wave crested (152/65, peak ~16 pts/h on 09-25) and has flatlined to 0 pts/h without producing substance — no benchmark, reproduction, or answer on isolation, Windows guests, or nvproxy differentiation; Nesbox drifted 7→27. The case's meaning is unchanged (pattern corroborated, nvkvm-pv still testimony-only); what changed is attention: the magnitude-valve spread reading reflects a two-day-old spike confined to one platform plus the creator's own echo, so heat cools to low while the evaluation lead stays open.
2026-09-24T04:45:05Z
grounded: converges/medium — Converges with his sandboxed-execution canon, which already names nvproxy-style driver-interface forwarding as the isolation-preserving route to GPU access and
2026-09-24T04:38:42Z
The case's meaning shifts from one creator's unverified claim to a corroborated engineering direction: virtio-nvgpu (near-native NVIDIA GPU access in KVM guests, citing gVisor nvproxy as direct inspiration) and Nesbox (microVM with GPU sharing) are independent implementations of the same shared-GPU-virtualization pattern, giving it a production ancestor (nvproxy) and two new lines of evidence. This corroborates the pattern, not nvkvm-pv itself, which remains creator testimony only; isolation, concurrent-workload performance and guest coverage are unresolved across all three projects.
2026-09-24T04:28:12Z
evidence attached: hn.story.49824884 — Independent microVM-with-GPU-sharing artifact shows the shared-virtualized-GPU-compute pattern emerging from a second direction, context for re-judging the nvkvm-pv case.
2026-09-24T04:28:12Z
evidence attached: hn.story.49824864 — Independent parallel project (virtio-nvgpu) achieving near-native NVIDIA GPU access in KVM guests, corroborating the shared-GPU-virtualization approach.
2026-09-10T15:54:57Z
The staleness review adds no validation beyond the creator’s announcement and its echo; nvkvm-pv remains an unverified local GPU-sharing evaluation lead, not an established deployment option. Cool attention pending independent reproduction, concurrent-workload measurements or clarification of guest–host isolation.
2026-09-08T13:36:24Z
No substantive evidence has arrived since the announcement was routed for attention; the GitHub echo remains the same creator’s testimony, not independent validation. This remains a plausible GPU-sharing evaluation lead, with compatibility, concurrent-workload performance and guest–host isolation unresolved.
2026-09-08T13:30:39Z
grounded: novel/medium — This introduces a GPU-sharing mechanism not established in Scott’s wiki or already tracked in the supplied radar hits: if validated, it could offer an alternati
2026-09-08T13:28:25Z
case created — The released artifact addresses a concrete GPU-sharing constraint, but the announcement does not establish safe isolation between guests and host.
Decision trace
- 10-08 14:50review_dormantscheduled targets exhausted or 28 quiet days
- 10-08 14:50drop_targetsquiet through full ladder or over cap 8
- 10-07 19:40drop_targetsquiet through full ladder or over cap 8
- 09-26 05:07repriceThe virtio-nvgpu attention wave crested (152/65, peak ~16 pts/h on 09-25) and has flatlined to 0 pts/h without producing substance — no benchmark, reproduction, or answer on isolation, Windows guests,
- 09-25 02:21sensor_dirtyvelocity_spike
- 09-25 01:21sensor_dirtycomment_update
- 09-24 19:22sensor_dirtycomment_update
- 09-24 16:21sensor_dirtyvelocity_spike
- 09-24 14:45repriceThe case's meaning shifts from one creator's unverified claim to a corroborated engineering direction: virtio-nvgpu (near-native NVIDIA GPU access in KVM guests, citing gVisor nvproxy as dir
- 09-24 14:45groundConverges with his sandboxed-execution canon, which already names nvproxy-style driver-interface forwarding as the isolation-preserving route to GPU access and weighs GPU-virtualization-vs-passthrough
- 09-24 14:28attachIndependent microVM-with-GPU-sharing artifact shows the shared-virtualized-GPU-compute pattern emerging from a second direction, context for re-judging the nvkvm-pv case.
- 09-24 14:28attachIndependent parallel project (virtio-nvgpu) achieving near-native NVIDIA GPU access in KVM guests, corroborating the shared-GPU-virtualization approach.
- 09-24 14:25propose_attachIndependent microVM-with-GPU-sharing artifact shows the shared-virtualized-GPU-compute pattern emerging from a second direction, context for re-judging the nvkvm-pv case.
- 09-24 14:24propose_attachIndependent parallel project (virtio-nvgpu) achieving near-native NVIDIA GPU access in KVM guests, corroborating the shared-GPU-virtualization approach.
- 09-13 10:23review_screenThe change is a speculative question about performance versus alternative approaches and adds no validation, implementation result, or new factual evidence.
- 09-11 01:54repriceThe staleness review adds no validation beyond the creator’s announcement and its echo; nvkvm-pv remains an unverified local GPU-sharing evaluation lead, not an established deployment option. Cool att
- 09-11 01:54alert_silentThe announcement was already routed, and this review supplies no new consequential delta. Another interruption would repeat the same evaluation lead without improving Scott’s ability to act.
- 09-11 01:54alert_routeThe announcement was already routed, and this review supplies no new consequential delta. Another interruption would repeat the same evaluation lead without improving Scott’s ability to act.
- 09-08 23:36repriceNo substantive evidence has arrived since the announcement was routed for attention; the GitHub echo remains the same creator’s testimony, not independent validation. This remains a plausible GPU-shar
- 09-08 23:36alert_silentThe creator’s announcement has already been routed, and this reobservation adds no consequential delta warranting another interruption. Preserve its evaluation value without treating the echoed claim
- 09-08 23:36alert_routeThe creator’s announcement has already been routed, and this reobservation adds no consequential delta warranting another interruption. Preserve its evaluation value without treating the echoed claim
- 09-08 23:35alert_shadowThe creator’s announcement introduces a concrete alternative to dedicating a GPU to VM passthrough: reportedly, multiple guests can use stock CUDA and Vulkan through forwarded NVIDIA driver ioctls whi
- 09-08 23:35alert_routeThe creator’s announcement introduces a concrete alternative to dedicating a GPU to VM passthrough: reportedly, multiple guests can use stock CUDA and Vulkan through forwarded NVIDIA driver ioctls whi
- 09-08 23:30groundThis introduces a GPU-sharing mechanism not established in Scott’s wiki or already tracked in the supplied radar hits: if validated, it could offer an alternative deployment path for his gamepc CUDA m
- 09-08 23:28createThe released artifact addresses a concrete GPU-sharing constraint, but the announcement does not establish safe isolation between guests and host.