TLDR; tell me if this is a waste of time before I spend forever tinkering on something that will always be janky

I want to run multiple OSs on one machine including Linux, Windows, and maybe OSX from a host with multiple GPUs + igpu. I know there are multiple solutions but I’m looking for advice, opinions and experience. I know I can google how-to but is this worh pursuing?

I currently dual boot Bazzite and Ubuntu, for gaming and develoent respectively. I love Bazzite ease of updates and Ubuntu is where it’s at for testing and building frontier AI/ML tools.

What if I kept my computer running a thin hypervisor 24/7 and switched VMs based on my working context? I could pass through hardware as needed.

Proxmox? XCP-NG? Debian + QEMU? Anyone living with these as their computing machines (not homelabs/server hosts)?

This is inspired by Chris Tidus’s (YouTube) setup on arch but 1) i don’t know arch 2) I have a fairly beefy i7 265k 192gb build, but he’s on an enterprise xenon ddr5 build so in a differenrent power class 3) I have a heterogenous mix of graphics cards I’m hoping to pass though depending on workload

Use cases:

  • Bazzite + 1 gpu for gaming
  • Ubuntu + 1 or more GPUs for work
  • Windows + 0 or more GPU Music Production paid vstis and kernel-level anti cheat games (GTAV, etc)
  • OSX? Lightroom? GPU?

Edit: Thank you all for your thoughts and contributions

Edit: what I’ve learned

  • this is viable but might be a pain
  • a Windows VM for getting around anti-cheat in vames defeats the purpose. I’d need a dual boot for that use case
  • hyperV is a no. Qubes Qemu libvirt, yes
  • may want to just put everything on sparate disks and boot / VM into them as needed

Edit: distrobox/docker works great but doesn’t fit all my needs because I can’t install kernel-level modules in them (AFAIK)

  • atzanteol@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    0
    ·
    10 days ago

    I use VMs a lot for desktops doing development work. It’s certainly possible, with some caveats. Here’s a bit of a knowledge-dump that may be helpful.

    Multiple displays can be tricky. If you just want a single monitor you’re fine. But hypervisors have varying support for more than one display and some do it better than others. VirtualBox had the absolute best support for it. Hyper-V has “support” for it but only really if you use their preferred Ubuntu install. I’m not sure how libvirt handles it. Remote display protocols have varying support and can be options - rustdesk seems to support it very nicely (one window per display like VirtualBox) but I’ve had lots of keyboard issues with that.

    Running VMs is less efficient, you’ll need more memory in the base system to handle each VM but it sounds like you’re pretty decked out there.

    Access to hardware can be tricky. Hyper-V sucks at this - don’t use it if you can help it. I’ve never quite done gaming in a VM but I suspect this would be the most problematic. I have done libvirt pass-through of an nvidia card but only for video encoding/decoding with Jellyfin - which does work just fine. But VM displays tend not to be well accelerated so I would expect other issues. As an example my hyper-v Linux guest can’t play video above a small resolution without the audio skipping and losing track.

    I’d avoid Hyper-V entirely. It absolutely sucks as a desktop environment. It relies heavily on RDP “enhanced mode” for everything, has shitty support for hardware pass-through, etc. Just a complete fail.

    VirtualBox was really quite good for a desktop environment - but Oracle is more lawfirm than software company these days. There are hidden license issues with using any extensions (for, e.g. accelerated displays).

    Libvirt I don’t have as much experience with unfortunately. I’ve usually emulated Linux on Windows not the other way 'round.

    • afk_strats@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      9 days ago

      I think I’m sold on NOT using HyperV. I will also keep it to one monitor because thats my current setup.