Hacker News new | past | comments | ask | show | jobs | submit login

Would a VM not work for this?



I fire up VMs for windows-only [mostly graphical] applications from time to time and the experience is never very good. No matter how beefy my host system is, the experience is awful and I end up giving up out of frustration. I have an old used Toshiba laptop with Windows that I fire up on those rare occasions now.


GPU passthrough can give you excellent performance, at the cost of some convenience (depending on how your setup is.)

Somewhat recently, Intel released GVT-g mode, which effectively allows you to carve up an Intel graphics adapter into chunks that can be used by VMs. I tried it on my laptop and it indeed works as advertised. https://01.org/igvt-g

The traditional method, though, is just having a secondary GPU with VT-d passthrough. This will give you the raw performance of a dedicated GPU, and you can either connect it to an external display for no latency, or you can use something like LookingGlass to get a more traditional setup (SPICE input + KVMFR video.)

I used GPU passthrough for a while, only stopping because it occurred to me that modern Wine and Steam Proton had largely closed the gap for me in needing virtualization for graphical applications. libvirt + Qemu/KVM + virt-manager with Windows guest SPICE agent installed is my weapon of choice these days. Without a GPU passthrough configuration, dragging windows is a little laggy, and I can't imagine graphical programs will work well since there is no 3D acceleration, but the performance with a lot of other tools (like Visual Studio) seems fairly acceptable. I will note that they should really make an easier auto-install for the SPICE drivers and agent, because it was tricky enough that it took me a while to realize I didn't actually have the right agent installed.

VirtIO block and network devices also can offer some I/O benefit, though you will want to use the Load Drivers mechanism to load the viostor driver prior to installation; it's a little tricky to switch to VirtIO storage later, since the driver obviously needs to be available during early boot. You probably also want to avoid qcow2 storage, instead opting for raw image or even disk passthrough for better I/O performance.


Thank you for this wealth of information.

I love the idea of a 2nd GPU, and I have a couple laying around that it's definitely worth trying. I already have three screens on my desk... what's one more?

I'm thoroughly impressed with the Wine project, and yet I'm generally hesitant to install it on my system. I think it may just be the massive install list I get when I try to `apt install` it. I've a similar aversion to installing KDE apps on a system that's not already running kde, which generally include about 150 other k* libs.

Steam Proton looks great. I'd played a few games once Steam started releasing them on linux and truly enjoyed how well some worked (and some _really_ didn't). I don't play as much lately, but this may change that.

It's going to take me some time to read about and further understand everything else you've posted here, which I appreciate.


Wine does tend to clutter the file associations a bit :( It’s probably possible to work around that but understandable that you don’t want to.

Steam Proton is great since it doesn’t do that and is mostly automatic. I was surprised to see Direct3D 11 titles running just fine at 60 FPS and maxed out settings, very cool.

And yeah, GPU passthrough is kind of the holy grail for desktop VMs. It’s definitely a little tricky, but once you have a good setup going it’s hard to beat. There’s a lot of guides. NixOS really shines here because your entire configuration can be declaratively configured, making your setup easily reproducible and surfacing all of the configuration in one place, but it’s obviously not distro dependent in any way and will work fine on Debian or Ubuntu.

Some downsides:

- Not all machines can VT-d, some can but are not stable. This is better today than ever.

- Your VM GPU needs to be in its own IOMMU group. Modern motherboards tend to do this basically automatically it seems, though its not guaranteed and if not your only workaround is a patch that lets you “split” the groups in an unsafe way that breaks isolation.

- Audio is tricky. Looking Glass does not forward SPICE audio today, so most folks configure qemu to output directly to PulseAudio. If you are using a physical display this approach obviously still works. You can also attempt to forward a USB audio device, or use audio over HDMI/DisplayPort.

edit: I hopped on my desktop. Here's my former NixOS configuration for GPU passthrough, to give you an idea of what kinds of system level configuration is needed:

    # IOMMU configuration
    boot.kernelParams = [ "amd_iommu=on" "pcie_aspm=off" ];
    boot.kernelModules = [ "kvm-amd" "vfio_virqfd" "vfio_pci" "vfio_iommu_type1" "vfio" ];
    boot.extraModprobeConfig = ''
        options vfio-pci ids=10de:13c2,10de:0fbb
        options kvm ignore_msrs=1
    '';

    boot.postBootCommands = ''
        # Enable VFIO on secondary GPU
        for DEV in "0000:0a:00.0" "0000:0a:00.1"; do
            echo "vfio-pci" > /sys/bus/pci/devices/$DEV/driver_override
        done
        modprobe -i vfio-pci

        # Setup Looking Glass shared memory object
        touch /dev/shm/looking-glass
        chown john:kvm /dev/shm/looking-glass
        chmod 660 /dev/shm/looking-glass
    '';

    virtualisation = {
        libvirtd = {
            qemuOvmf = true;
            # To make the PULSE Qemu audio driver work.
            qemuVerbatimConfig = ''
                namespaces = []
                nographics_allow_host_audio = 1
                user = "john"
                group = "kvm"
            '';
        };
    };
The virtual machine itself also needs some configuration. It will need to use UEFI with a properly-equipped TianoCore image to initialize the GPU. Also, to set the audio driver to something other than SPICE. Finally you need to add the PCI devices, this can be done trivially through the UI as long as you know the PCI IDs of your card.


There's no way to do GPU passthrough on Windows, right? It seemed to be just a Linux thing last time I checked? And similarly with GVT?


This is correct, I am unaware of any way to bring GVT-g to Windows. It is probably not impossible but the groundwork isn’t there yet. I suspect Microsoft will have its answer in the form of GPU-P and SR-IOV, though it is currently unclear if that’ll work with consumer hardware or not.

Simple VT-d is supported in the form of DDA in Hyper-V - I have not attempted to use this for a GPU and I’m not sure what limitations it may have versus KVM’s PCI passthrough.


Cool, thanks!


I used virtual box running xp a few years ago for a vba project I did for a contract. I never ran into any issues.


XP is NT-based, so it's not surprising. They're saying for non-NT systems it's an issue.


Ah ok fair enough. I have to admit i haven't tried running windows 8 or 10 in a vm since the preview builds. I assumed any instability was from the lack of polish on the OS itself in its state at the time.


What VM software are you using? I find that virtual box is always awful but I haven't tried anything else.


I believe Windows 95 has trouble with CPUs that are too fast and needs to be patched to handle it.

I think I also read somewhere that older Windows (and some other operating systems) don't handle modern TCP/IP very well. A TCP session start with window size 9 and ECN bits, for example. And I believe there's more timing problems with networking as well, because no one believed in gigabit Ethernet back in the day.


Oh wow I see, okay thanks.


It would, with setup to replicate the environment.

It might well be a miserable buggy experience compared to just using the original hardware.


Windows 95 is very difficult to get working in a VM in a reasonable way, and this machine likely relies on custom ISA cards, which is likely impossible to virtualize.


Most VMs don't really work with Windows 9x which tends to crash even more than usual (NT based windows is fine though). The only one tool I know of that's running 9x relatively stable is PCem, and that's more of an emulator than a VM proper.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: