Over the last year, the VDI conversation has shifted.
Between licensing realignments in the VMware ecosystem and continued cost pressure around GPU acceleration, many IT teams are re-evaluating their stack. At the same time, open platforms like Proxmox VE have matured into legitimate production contenders - a shift highlighted repeatedly by notably Level1Techs and others in their deep dives into Proxmox clustering and Intel’s new SR-IOV capable GPUs.
As a solutions engineer at Kasm Technologies, I spend a lot of time thinking about where VDI is going - not just where it is today.
This post is a look forward.
The GPU Question in VDI
When people think about GPU-accelerated VDI, they often jump straight to heavy compute:
- AI / data science workloads
- CUDA-driven applications
- ML model training
And for those use cases, NVIDIA + CUDA is the clear leader.
But that’s not the whole VDI story.
A large class of deployments need GPU acceleration for different reasons:
- Delivering a smoother Windows desktop experience
- Engineers running CAD tools
- Creative teams using Photoshop or video editing software
- WebGL-heavy browser workloads
- Light 3D visualization
Historically, if you wanted to virtualize GPUs properly in this space, you used NVIDIA vGPU. It’s a mature, excellent technology - and notably, Proxmox now officially supports NVIDIA vGPU as of 2025.
But the tradeoffs are well known:
- Enterprise-grade GPU SKUs
- Paid vGPU licenses
- Licensed drivers
- Higher entry cost
For some environments, that’s perfect. For others, it’s more than they need.
Enter SR-IOV on Professional GPUs
Single Root I/O Virtualization (SR-IOV) changes the conversation.
Instead of time-slicing a GPU in software, SR-IOV allows a physical PCIe device to expose multiple hardware-backed Virtual Functions (VFs). Each VF can be assigned directly to a VM.
Conceptually, it’s similar to vGPU:
One physical card -> multiple isolated virtual GPU devices.
One of the most interesting developments here is the Intel Arc Pro B50.
At a workstation-friendly price point, the B50:
- Provides 16GB of VRAM
- Implements SR-IOV
- Targets professional workloads
- Works on Linux
Thanks in part to coverage and experimentation from Level1Techs, the community has been actively exploring what this means for virtualization.
The big shift?
SR-IOV support is steadily landing upstream in the Linux kernel. We are no longer in “custom patch and DKMS hack” territory.
The Test Environment: Real Versions, Real Results
For this lab, we ran:
- Proxmox VE 9.1.5
- Kernel: 6.17.2-1-pve (stock)
- Intel Arc Pro B50 with SR-IOV enabled
No custom kernel modules were required.
No out-of-tree patches.
No experimental builds.
This is important.
In earlier cycles, GPU SR-IOV experimentation often required special kernels. In this test, everything that worked did so on a shipping Proxmox release.
That’s a meaningful maturity milestone.
How We Partitioned the GPU
In this test, we split a single 16GB B50 into 8 Virtual Functions.
That allowed us to allocate:
- 2GB of VRAM per Windows VM
From a VDI perspective, that’s a very interesting density profile:
- 1 physical card
- 8 GPU-backed desktops
- Hardware-isolated functions
For many task-worker, CAD-lite, browser-heavy, or creative workloads, 2GB per desktop is entirely usable.
A Windows 11 VM using a 2GB slice of the B50 streamed via Kasm Workspaces
The Intel B50 as seen from the PVE host advertising SR-IOV capabilities (12 available VFs , 8 configured in this case)
This wasn’t theoretical. Each VM saw its own VF and operated independently.
Multi-Node Cluster + Resource Mapping
We deployed a multi-node Proxmox cluster, with GPUs distributed across nodes.
In Proxmox, we grouped SR-IOV Virtual Functions into a Resource Mapping abstraction.
This was the key architectural enabler.
Instead of binding a VM to a specific PCI address:
- We created a resource pool of GPU VFs
- Allowed orchestration to request “a GPU”
- Let Proxmox resolve the actual physical mapping
With this in place, Kasm Workspaces could:
- Clone a golden Windows template
- Deploy it to any eligible node
- Attach an available GPU VF dynamically
This moves the pattern from static passthrough to programmable infrastructure. Learn more about VDI with Kasm Workspaces.
Resource Mapping of the B50 virtual functions across multiple Proxmox nodes
Multiple GPU-enabled VMs are auto-scaled across the cluster using a single template
The test bench - pardon the mess
Migration Testing Results
We tested real operational scenarios, not just boot success.
Results:
- ✅ Cloning across cluster nodes - worked
- ✅ Powered-off migration - worked
- ❌ Live migration (powered-on) - not working yet
Live migration of SR-IOV-backed VMs did not function in this kernel/driver combination.
For many autoscaling or non-persistent VDI environments, cold migration is acceptable. But live migration support would be an important future milestone.
Driver Observations
We did encounter driver considerations:
- To expose a higher number of VFs, we dropped back to an earlier Intel driver version.
- Some quirks remain - this is still early in the lifecycle.
That said, Intel’s GPU driver stack has steadily improved over time, and the fact that this works on a stock Proxmox kernel is a strong signal.
Intel could slot extremely well into this market - though their segmentation and messaging around driver support has felt fluid. If they lean into SR-IOV for professional virtualization, the opportunity is significant.
Why This Matters Now
The broader context:
- VMware is focusing upward in the market.
- Enterprises are re-evaluating cost structures.
- GPU-backed VDI demand is rising.
- Open hypervisors are maturing.
This is not a takedown of VMware or NVIDIA. Both remain strong partners and technology leaders.
But markets evolve.
SR-IOV GPUs in the workstation class introduce a new acceleration tier:
- Below full datacenter GPU stacks
- Above basic non-accelerated desktops
- License-light
- Infrastructure-native
For VDI platforms integrating across clouds and hypervisors, this unlocks new design space.
A Look Forward
This lab wasn’t meant to claim perfection.
It was meant to answer:
- Is it viable?
- Is it stable enough to explore?
- Does it integrate cleanly?
- Can it scale across a cluster?
- Does it behave operationally?
The answer today:
- It works on stock Proxmox VE 9.1.5
- Kernel 6.17.2-1-pve is sufficient
- 8 VFs at 2GB each are practical
- Cluster cloning works
- Cold migration works
- Live migration isn’t there yet
That’s a very different place than we were even a year ago.
If you’re an engineer, architect or CTO watching the direction of virtualization and GPU economics, this is worth paying attention.
This isn’t the final state of GPU-backed VDI.
It’s a preview of what the next tier might look like.
