Can a Proxmox VM Feel Like Bare Metal? Dual 144Hz + GPU Passthrough + Low Latency

[procyonjs]

Hi everyone,

I'm planning to build a new PC and use Proxmox as the host OS, with a Linux VM as my main daily desktop.

I haven't purchased the hardware yet, so I still have some flexibility with the build. However, I'm pretty much set on using an Intel Core i5-14600K as the CPU. I haven't decided on the GPU yet, and I'm specifically looking for something that works reliably with Linux and GPU passthrough. NVIDIA is an option, but I'm open to other recommendations if AMD or a particular GPU would make more sense for this setup.

My planned setup is roughly:

• CPU: Intel Core i5-14600K
• GPU: Not purchased yet / looking for recommendations
• RAM: 32 GB DDR5
• Host: Proxmox VE
• Main desktop: Linux VM (Ubuntu, Pop!_OS, or similar)
• Monitors: 2 × 144 Hz
• Keyboard & mouse: Bluetooth
• GPU passthrough is absolutely an option

I'm not really interested in gaming. My main use case is software development and normal desktop usage. However, latency is extremely important to me.

What I want is for the VM to feel basically indistinguishable from running Linux directly on bare metal. I don't want to feel additional mouse/input latency, sluggish window movement, reduced refresh rate, or any noticeable delay caused by virtualization.

Ideally, I want both monitors running at their full 144 Hz refresh rate with the same responsiveness I would get from a normal desktop installation.

My current idea is to passthrough a dedicated GPU to the Linux VM and connect both monitors directly to the DisplayPort/HDMI outputs of that GPU, rather than using SPICE, RDP, VNC, or another remote-display solution.

As far as I understand, in this configuration Proxmox isn't actually streaming the desktop—the VM controls the physical GPU and the monitors receive the signal directly from it. Would this allow the VM to provide an effectively bare-metal experience, including 144 Hz on both monitors and very low input latency?

I'm also wondering about the best way to handle the keyboard and mouse. Would passing through an entire USB/Bluetooth controller to the VM be preferable to passing through individual devices if minimizing input latency is the priority?

My main requirement is simple: when I'm sitting in front of the computer and using the Linux VM, I want it to feel like I'm using a normal physical desktop. If virtualization introduces noticeable input/display latency, even if performance benchmarks are otherwise good, that would be a deal-breaker for me.

For anyone running a similar Proxmox workstation setup:

• Can a GPU-passthrough VM realistically feel indistinguishable from bare metal?
• Can I reliably run two 144 Hz monitors this way?
• Is there any noticeable mouse/keyboard latency?
• Are there any particular GPUs you would recommend for Linux + Proxmox passthrough?
• Is the i5-14600K a good choice for this kind of setup?
• Are there any specific motherboard/IOMMU considerations I should keep in mind before buying the remaining hardware?

I'd especially appreciate experiences from people who actually use a passthrough VM as their main daily desktop, rather than only for occasional gaming or remote access.

 

[UdoB]

I'm planning to build a new PC and use Proxmox as the host OS, with a Linux VM as my main daily desktop.

Yes, it can work. But it increases complexity. Drastically, from my point of view.

Perhaps the "Dev workstation"-concept may be interesting for you?

• https://pve.proxmox.com/wiki/Developer_Workstations_with_Proxmox_VE_and_X11
• https://forum.proxmox.com/threads/h...ation-for-proxmox-virtual-environment.181435/

 

[alexskysilk]

What I want is for the VM to feel basically indistinguishable from running Linux directly on bare metal. I don't want to feel additional mouse/input latency, sluggish window movement, reduced refresh rate, or any noticeable delay caused by virtualization.

crazy idea- given your use case, why not start with a normal Windows/Linux desktop and run the rest of the vms in qemu? PVE isnt even desirable in your use case...

 

[Johannes S]

I'm planning to build a new PC and use Proxmox as the host OS, with a Linux VM as my main daily desktop.

Why? ProxmoxVE is not designed around this usecase. A workstation setup like the one linked by UdoB is mainly for people who want to contribute to ProxmoxVE development. If this isn't your usecase using your favorite distribution as daily driver together with virt-manager or VirtualBox for virtualization is for most usecases the more sensible setup.

 

[procyonjs]

Why? ProxmoxVE is not designed around this usecase. A workstation setup like the one linked by UdoB is mainly for people who want to contribute to ProxmoxVE development. If this isn't your usecase using your favorite distribution as daily driver together with virt-manager or VirtualBox for virtualization is for most usecases the more sensible setup.

crazy idea- given your use case, why not start with a normal Windows/Linux desktop and run the rest of the vms in qemu? PVE isnt even desirable in your use case...

Yes, it can work. But it increases complexity. Drastically, from my point of view.

Perhaps the "Dev workstation"-concept may be interesting for you?

• https://pve.proxmox.com/wiki/Developer_Workstations_with_Proxmox_VE_and_X11
• https://forum.proxmox.com/threads/h...ation-for-proxmox-virtual-environment.181435/

The main reason I want to use Proxmox isn't just to run a few VMs. I want to use the same machine as both my daily workstation and an independent homelab/server.

If I use Ubuntu as the host and run everything through KVM/QEMU, my daily desktop also becomes the foundation for all my services. If I break something while changing the kernel, GPU drivers, networking, etc., I could lose access to all of my VMs and self-hosted services.

With Proxmox, I can keep them separated:

Proxmox
├── Linux Desktop VM
├── Server VM/LXC (self-hosted apps)
├── Home Assistant
└── Other VMs/LXCs

So even if I completely break or reinstall my desktop VM, the other services keep running and I can still manage everything through Proxmox from another device.

I understand that the Proxmox host itself is still a single point of failure, but the idea is to keep the host minimal and stable and do all my daily work/experimentation inside the desktop VM.

That's why I'm considering the extra complexity of Proxmox + GPU passthrough, provided I can still get a near bare-metal desktop experience.

 

[alexskysilk]

That's why I'm considering the extra complexity of Proxmox + GPU passthrough, provided I can still get a near bare-metal desktop experience.

The point- you dont NEED pve to achieve your desired functionality, and USING pve for it involves uncomfortable compromises with user experience. But you do you

If it were me, and you havent yet purchased anything- I'd buy two machines- one for the workstation and one for pve. the pve machine can be a 10 year old 1L box from ebay. works fine for the purpose. it also allows you to sleep/turn off the hungry workstation and retain services.

 

[leesteken]

I run a (Linux) gaming VM with a (AMD) GPU (and USB) passthrough and it works great. As long as I give it a between a quarter to half the resources of the host (and don't stress the host with other things while gaming), I don't notice any latency issues. Most games don't benefit from more than 4-10 cores and 24-48GiB and PCI(e) passthrough (with ReBAR) is native speed anyway.
The storage layer is simply mirrored SSDs and gives good read IOPS and allows backups to PBS while gaming. I don't go through the trouble of passing drives as NVMe or hiding the fact that it is a VM, as I don't play competitive multiplayer games. In short: yes, it easily be done in the host hardware is big enough to prevent CPU/RAM/storage latency issues and you don't give too much to any single VM.

EDIT: I agree with everybody here that this is not what PVE was intended for and it's a waste of resources (to achieve good latency) to use it a a desktop (only). Personally, I came for PVE and will stay forever because of PBS. I run all my browsers in separate Linux VMs (a bit like QubesOS) and with SPICE video/audio is perfect without only 4 virtual CPUs and no GPU.

 

[Johannes S]

The main reason I want to use Proxmox isn't just to run a few VMs. I want to use the same machine as both my daily workstation and an independent homelab/server.

If I use Ubuntu as the host and run everything through KVM/QEMU, my daily desktop also becomes the foundation for all my services. If I break something while changing the kernel, GPU drivers, networking, etc., I could lose access to all of my VMs and self-hosted services.

With Proxmox, I can keep them separated:

Proxmox
├── Linux Desktop VM
├── Server VM/LXC (self-hosted apps)
├── Home Assistant
└── Other VMs/LXCs

So even if I completely break or reinstall my desktop VM, the other services keep running and I can still manage everything through Proxmox from another device.

I understand that the Proxmox host itself is still a single point of failure, but the idea is to keep the host minimal and stable and do all my daily work/experimentation inside the desktop VM.

Most distributions have nowadays btrfs together with something like snapper or timeshift integrated for this. With this you have snapshots of your system state and can always revert to an earlier point in time. I also wouldn't feel comfortable having all my services/Home assistant etc on the same device as my workstation. What if my workstation gets broken and now all my tax documents or family pictures are lost too?
And a virtualized desktop will always have some loss in performance compared to bare metal, no ways around it (nobody beats physics).
And since ProxmoxVE isn't really designed for running as a workstation os getting stuff like wifi, power management or DHCP can get complicated. Desktop distributions usually work out of the box.
If you want to do this non the less https://www.qubes-os.org/ might be of interest for you, I don't know about it's performance though. Please note, that it's NOT a Linux distribution but a XEN-based environment .

 

[Kingneutron]

I have a "headless" Debian LXC running with xrdp on a Ryzen 9 mini-pc (( AMD/ATI Rembrandt Radeon 680M builtin graphics )) that is responsive enough to play 8x animated GIFs / mp4 movies at once, even without /dev/dri passthru.

I connect to it over 2.5Gbit ethernet from a Mac with Jump Desktop, and have seen it do up to 12-16x animated at once with good interactive response if sized slightly smaller.

Honestly though, you would arguably have a more stable environment if you had a client/server arrangement. Put the proxmox server separate and connect to it (from another desktop or laptop) with remote-desktop tools such as Nomachine NX, RDP, even Sunshine/Moonlight.

As they say, " Horses for courses " - proxmox is good at being a server/hypervisor running 24/7. Desktop distros are (usually) good at what they put on the tin, so to speak - and you'll have more flexibility with desktop environment there.

Regardless of what you put in place, put everything on UPS and stand up Proxmox Backup Server + regular backup schedule.

 

[UdoB]

If you want to do this non the less https://www.qubes-os.org/ might be of interest for you, I don't know about it's performance though.

The performance is fine. For a workstation that is, not for a gaming machine. And - of course - it depends on the actual hardware.

The Mini-PC I am using in this very moment has a Ryzen 7 and 32 GiB Ram and I use two 4k displays with the integrated Graphic. This is my daily driver now, @home. Each active Xen-Domain consumes 2 to 6 GiB of Ram, so 32 GiB is the minimum for a vivid experience.

Qubes-OS is about security. I do highly recommend it for everybody who has anything to administrate and/or wishes to have a better isolation between tasks than just a separate browser-session. For me @home this absolutely starts with personal emails and private homebanking in a browser.

 

[shodan]

Hi everyone,

I'm planning to build a new PC and use Proxmox as the host OS, with a Linux VM as my main daily desktop.

Hi,
I'm on the same side-quest as you.

This topic that is roughly called "single gpu passthrough", but that I call the "Hypervisor Desktop" (as opposed you typical desktop hypervisor, which is basically just running virtualbox.

And as you can see, every thread on the internet is people who have never done it, who don't want to do it, trying to convince you it can't be done. They can't point to why it won't work, but they don't have advice on how to make it work, they can only tell you why don't never bothered to try.

You can CTRL+F this thread, the acronym "IRQ" hasn't shown up yet.

I'm still a few months away from making this samurai sword of a computer a reality so I can only tell you good luck and I will be joining you in the papercut forest shortly !

EDIT:
Check out the looking glass app
https://looking-glass.io/community
that is mostly about laptop people who are mostly just trying to avoid dual booting, but
There's also https://www.reddit.com/r/VFIO/ but reddit is a dumpster fire unfortunately, /r/VFIO used to be one of the top places.

Other than that we're on our own but I'll add more here and I'll post my experience when I finally get around to it.

 

[Johannes S]

And as you can see, every thread on the internet is people who have never done it, who don't want to do it, trying to convince you it can't be done. They can't point to why it won't work, but they don't have advice on how to make it work, they can only tell you why don't never bothered to try.

Nobody claimed that it won't work. UdoB even mentioned the relevant page from the Proxmox wiki. The point being is, that ProxmoxVE isn't designed as a desktop OS so it's more work to make it behave like one. Now there are some usecases for it (like as a developer workstation if you plan on contributing to Proxmox development) but for people like OP who mainly wants ro run the system as his Desktop daily driver with low latency nothing beats a bare metal Desktop distriubtion with some Desktop virtualization for his development VMs.

 

[shodan]

Nobody claimed that it won't work. UdoB even mentioned the relevant page from the Proxmox wiki. The point being is, that ProxmoxVE isn't designed as a desktop OS so it's more work to make it behave like one. Now there are some usecases for it (like as a developer workstation if you plan on contributing to Proxmox development) but for people like OP who mainly wants ro run the system as his Desktop daily driver with low latency nothing beats a bare metal Desktop distriubtion with some Desktop virtualization for his development VMs.

But he's not going to use proxmox as the desktop, in this case, proxmox is doing what it is designed to do, host high performance VMs.
He's not going to install a display server in proxmox, the host won't handle the GPU, nor keyboard/mouse/sound card and other peripherals.

Any issue he might have is general purpose performance problem on proxmox's part.
Using a desktop hypervisor, which I understand is IT's typical, conventional solution, isn't going to cut it here, because you end up running two whole desktop OS on top of one another, that is a big waste of resources.

As far as I can tell, the majority of people doing "single gpu passthrough", are using virtviewer, so it's also QEMU. I really don't see what exact part of proxmox can't be just as fast as virtviewer. And as a bonus, you get a web interface to direct things from your desktop and configuration is easier than virtviewer.

I think proxmox will work better, it's just not what conventional wisdom dictate is the solution and because of that few people ever try, most simply getting discouraged before even getting there.

And I understand that the money people are going to say "datacenters don't care about this so money doesn't care either" but that is really shortsighted (as usual for money people) because any hiccup a proxmox-based hypervisor desktop is going to encounter I guaranteeeeeee you the servers are wasting cycles on, you just don't see it because the proxmox instrumentation doesn't see anything under 1 second temporal resolution. There's just no way to feel those millisecond hiccup via a web interface, but the desktop does and the servers apps feel them too and the end user too but they can't tell it apart from network hiccups.

 

[Johannes S]

But he's not going to use proxmox as the desktop, in this case, proxmox is doing what it is designed to do, host high performance VMs.

But he does. He wants to use a VM as his main desktop but also the lowest potential latency. A VM will always have a higher latency than a bare metal OS because nobody can change physics.

He's not going to install a display server in proxmox, the host won't handle the GPU, nor keyboard/mouse/sound card and other peripherals.

Which is exactly the reason I see trouble with said approach, to quote him:

My current idea is to passthrough a dedicated GPU to the Linux VM and connect both monitors directly to the DisplayPort/HDMI outputs of that GPU, rather than using SPICE, RDP, VNC, or another remote-display solution.

So instead of letting the host handle the hardware he passes it through to the VM. This adds another layer where problems might arise. Just have a look how many people are having trouble with passtrough (not due to a bug in that feature per se but due to the envolved higher compexity).

Any issue he might have is general purpose performance problem on proxmox's part.
Using a desktop hypervisor, which I understand is IT's typical, conventional solution, isn't going to cut it here, because you end up running two whole desktop OS on top of one another, that is a big waste of resources.

No, he wouldn't since he would run his main daily driver (aka his actual desktop) directly on the hardware. Only for development/test purposes he would run another VM. And for most development I can imagine you wouldn't even need another desktop.
This would also fit his declared main goal:

My main requirement is simple: when I'm sitting in front of the computer and using the Linux VM, I want it to feel like I'm using a normal physical desktop.

The best way to ensure that it behaves as a normal physical desktop would indeed be to actually have one.

My main problem is that I still fail to see which problem the OP wants to solve with this approach. For having different Desktop environments something like QubesOS is more suited (since it's designed for that usecase and has several QoL features to make it work). For hosting VMs on a desktop Virtualbox or virt-viewer are etablished solutions. Preferring the Proxmox WebUI to virt-viewer, Virtualbox or Incus WebUI (which can also be installed on a regular desktop) doesn't make a bad architecture better.

 

[shodan]

I don't wish to engage is a point by point refutation.

Instead, let me rephrase the question,
so that "still fail to see which problem the OP wants to solve with this approach" is side stepped

How to configure a headless Proxmox so that a single VM with
GPU,keyboard,mouse,audio passthrough behaves as smoothly as possible.

We put aside the why and the question is only, what settings will achieve the highest performance for this situation.
No SPICE, no sunshine, not display server on the proxmox host and not even looking glass.

It's just one VM and all the peripheral are passthrough, how do you make that the best it can possibly be ?

No why, no X-Y derailment, no alternative architecture, stay focused.

What we're talking about and what the real question is, is this

Host configuration
VT-d / IOMMU enablement, Above 4G Decoding, ReBAR, PCIe/IOMMU config, ACS behavior, motherboard IOMMU-group layout, devices on CPU lanes versus chipset, chipset/DMI contention, P-core / E-core allocation strategy, ASPM, C-states, package C-states, SpeedStep / Speed Shift / CPPC equivalents, BIOS latency-related settings, PL1/PL2 limits, sustained turbo behavior, preventing downclocking, VRM throttling, GPU power state
Ideal GPU selection, GPU BIOS
Proxmox kernel parameters, kernel config, VFIO binding / early device binding, power management, host CPU governor, scheduler behaviour, hugepages configuration, Kernel Samepage Merging, swapping, ramdrives
CPU pinning/isolation, CPU isolation strategy, NUMA awareness, SMT sibling handling, P-core / E-core placement, host core reservation, IOThreads isolation
QEMU process priority, host workload interference, preventing backups / ZFS scrub / resilver / containers / monitoring jobs from interfering with latency-sensitive CPUs or devices, stripping Proxmox services that are not immediately needed
IRQ handling, irqbalance, interrupt affinity, MSI/MSI-X interrupt configuration, interrupt vector distribution
Host bridge configuration, vhost-net, network multiqueue, network interrupt/coalescing settings, network offloads where relevant
Storage backend choice (ZFS / LVM-thin / directory / raw), filesystem and pool layout, SSD/NVMe selection, RAID/mirror topology, queue depth, I/O scheduler, async I/O mode, cache mode, writeback behaviour, sync write handling, discard/TRIM, alignment/block size, ZFS recordsize/volblocksize, ARC sizing and memory pressure, ZIL/SLOG behaviour, compression, deduplication, read-ahead, write amplification, NVMe power states, PCIe link width/generation, storage IRQ affinity, IOThread placement, host swapping, backup/scrub/resilver interference, SMART/background maintenance, thermal throttling, benchmarking latency/IOPS rather than only throughput

VM configuration
CPU host type, vCPU count, vCPU topology, CPU affinity / pinning, NUMA settings if relevant
Fixed RAM allocation, memory ballooning off, hugepages if used, memory preallocation / locking where appropriate
Q35 machine type, OVMF / UEFI, avoiding unnecessary emulated devices
GPU passthrough configuration, GPU HDMI/DP audio passthrough, GPU reset behavior, multifunction PCI devices, ROM/UEFI quirks, ReBAR passthrough quirks where applicable
USB device versus USB controller passthrough, whole-controller passthrough where practical, high-polling-rate devices configuration
raw / LVM-thin / ZFS / qcow2 differences, VirtIO storage choice, dedicated IOThread, queue depth, disk cache mode, AIO mode, NVMe passthrough versus virtualized NVMe/storage
VirtIO NIC choice, vhost-net usage, network multiqueue, VirtIO network versus network passthrough, SR-IOV where relevant

Guest configuration
Linux kernel / version, CPU governor, scheduler / preemption behavior, guest CPU topology sanity
Guest IRQ affinity, irqbalance, MSI/MSI-X handling inside the guest
Guest clocksource, TSC stability / sanity, HPET exposure / avoidance where appropriate
swap / zram behavior, transparent hugepages, guest hugepage behaviour where relevant
GPU driver, Wayland / X11 compositor configuration, 144 Hz configuration, VRR, VSync, frame scheduling, mixed-refresh behaviour
PipeWire / audio buffer settings, HDMI/DP audio behaviour, USB audio latency where applicable
USB / Bluetooth behavior, polling rates, controller behaviour, power saving / autosuspend
filesystem / I/O tuning, I/O scheduler, mount options, discard/TRIM behaviour, queue depth where exposed to guest
network queue tuning, network interrupt/coalescing tuning, offload settings where relevant
latency measurement and validation, cyclictest, perf, turbostat, /proc/interrupts, lspci -vv, lstopo, storage latency / IOPS testing, frame-time testing, input latency testing

How do you adjust all of these levers for the maximum guest OS performance

Answer that and leave the X-Y Why to the user.

 

[uzumo]

Even if it runs slowly, have you actually configured it to the point where you can make it work? If not, it’s nothing more than a pipe dream.

There are no instructions for taking it out of the box and using it, and of course, there’s no one to help someone who can’t even get it to work in the first place.

This is an issue that comes before even discussing things like lag.

You want me to help with that, too? That's out of the question.