Exploring Gaming VM Setup (Part 1)

For years, I've been playing games and doing everything else on the same PC. Hoever, after a recent positive experience with Qubes OS, I no longer feel comfortable keeping my games, passwords, and other stuff all in the same place. Because of this, I decided to change my gaming setup.

My requirements are:

• Performance. Gaming should be functional and playable.
• Isolation. At a minimum, game binaries should not have access to my other files.
• Quick Switch. I need to be able to switch between gaming and non-gaming easily.
• Single Display. All my workflows should be performance well on a single display. I do have a secondary display, but I want to rarely use it.

So, here goes my adeventure.

Option 1: Dual Boot

This is the classic solution, which sounds boring but almost always works.

• Performance: Good. All operating systems have direct access to physical hardware.
• Isolation: OK-ish, each OS technically has access to all data from other OSes. Disk encryption and Secure Boot can mitigate this risk.
• Quick Switch: not so good, I would need to go through UEFI post and disk decryption every time.

Basically, I skipped this option just to explore something more "fun" (read: torturing).

Option 2: Qubes OS

Because of my positive experience with Qubes OS, I thought it would be great to use use it as my daily driver, while keeping gaming in a separate VM (qube).

So I installed Qubes. However, unsurprsingly, I couldn't get the GPU to work.

At the time, I thought I probably didn't try hard enough, as there are successful examples online. Looking back now, I think I probably should try to enable UEFI.

Through this excerce, I also releasize that dom0 is not meant for headless, e.g. it is not supposed to to be accessed remotely. This would make it difficult to recover if anything goes wrong. Perhaps sys-gui-vnc might help.

Anyways, I decided to move on to the next option.

Option 3: Sandboxes and Containers

So I installed Debian with GNOME to see if any lightweight sandbox or container technologies could be useful.

Note that some technologies, like Podman and Docker, are not security boudnaries. I'm talking about options like:

• Flatpak + Flatseal
• Firejail
• Bubblewrap
• gVisor
• Kata Containers

In particular I have had a very positive experience with Podman + gVisor on my server.

After some research and long disucssions with AI, I figured out that none of them work well for isloating games. Games, like many other graphical programs, naturally require access to hardware. But most container/sandbox options only offer an "all-or-nothing" permission model.

Flatpak seems to allow fine-grained control, especially since it provides a DBus proxy. But I doubt it provides good default profiles for all games. In particular, I noticed Firefox has full filesystem access by default.

I also learned that Flatpak's approach might interfere with a software's own sandbox, like Firefox or Chromium.

So, this option was a pass. I decided to go back to VMs.

Option 4: Single GPU Passthrough

Many GPU passthrough tutorials assume you have "a spare GPU", because the main GPU (which can be an integrated one) is used by the host.

While I do have a secondary iGPU, I prefer not to use it. Since I'm using a laptop, the iGPU is connected to the built-in display, which sits too far away fro my main setup.

I then leared about the "single GPU passthrough" technique. The procesure look like this:

• Turn off all programs that are using GPU (e.g. kill the display server).
• Unload the GPU driver (e.g. nouvea, nvidia, amdgpu).
• Rebind the vfio-pci driver to GPU.
• Launch the VM.

Then, you just reverse the sequence when the VM is shut down.

I don't really like this procedure for a few reasons:

• Frequently rebinding drivers sounds unstable. I actually tried this later, and it confirmed my concerns. I'll disucss this in a later article.
• Killing the display manager might destroy my active session (though I've heard this might not be the case for GNOME). It made me think I should just do multile VMs or dual boot instead.

Ultimately, I decided this option was not for me either. Time to move on.

Option 5: Headless VM Orchestrator

Combining lessions from all my previous attempts, I concluded that I should build something like Proxmox. Basically a minimal OS acting as a VM Orchestrator, where I only interact with VMs.

I think this is the best compromise. Comparied to all previouis options:

• Only one VM (with GPU passthrough) can run at a time, so it feels similar to dual boot. However, it is much faster to swtich between VMs because I don't need to decrypt the disk every time. Plus, one VM has no access to the disks of other VMs.
• Compared to sandboxes and containers, VMs provide much stronger security guarantees, and the I find them easier to set up securely.
• Compared to single GPU passthrough, the experience is similar, but the system is much more stable.

While I've heard nothing but positive feedback about Proxmox, I'd prefer building my own environment from vallina Debian. I'll dicuss exactly how I did that in the next article.