maydayv7

Windows VM

Unknown — Sat, 27 Jun 2026 00:00:00 +0000

Intro§</a > </h1>
This is a guide to running a Windows 11 VM with an NVIDIA dGPU passed straight through to it, displayed via Looking Glass</a> directly on the primary display (no secondary monitor required), CPU-pinned and hugepage-backed for lower latency, and defined declaratively with NixVirt</a> - all on NixOS.
I run this on a laptop with an AMD Ryzen CPU, an integrated Radeon iGPU, and an NVIDIA RTX 4060. Any other host with 2 GPUs, or a dGPU + iGPU, should work the same way.

Prerequisites §</a > </h1>

CPU support for IOMMU </li>

A GPU you can dedicate to the VM that sits alone in its own IOMMU group. Check with:
`$ for d in /sys/kernel/iommu_groups//devices/; do echo "Group ${d%/devices/}: $(lspci -nns ${d##/})"; done | sort</code></pre> Find your GPU and note its vendor:device</code> IDs:`
`$ lspci -nnk -s 01:00.0 01:00.0 VGA compatible controller [0300]: NVIDIA ... [10de:28e0] 01:00.1 Audio device [0403]: NVIDIA ... [10de:22be]</code></pre></li>`

Download ISOs:

Windows 11 - Download from Microsoft</a>.</li>
virtio-win - The para-virtual Windows drivers: `nix build nixpkgs#virtio-win</code></li> </ul> </li> </ul>`Binding the GPU for VFIO§</a > </h1> The core idea is to bind the GPU to the vfio-pci</code> stub driver at boot, before its real driver kicks in. How you do that depends on your setup: Case A - the host renders on a different GPU (Eg. your desktop runs on the iGPU). Just bind the dGPU permanently: boot.initrd.kernelModules = [ "vfio" "vfio_pci" "vfio_iommu_type1" ]; boot.kernelParams = [ "amd_iommu=on" "iommu=pt" "vfio-pci.ids=10de:28e0,10de:22be" # your GPU + its audio function ];</code></pre> Case B - the host renders on the same GPU you want to pass (Eg. NVIDIA PRIME Sync, where the desktop holds nvidia_drm</code>). A NixOS specialisation</a> can be used: your default boot keeps the GPU for the desktop, and a different boot entry binds it to vfio-pci</code> instead: specialisation.vfio.configuration = { boot = { blacklistedKernelModules = [ # don't load host driver "nvidia" "nvidia_drm" "nvidia_modeset" "nvidia_uvm" ]; ... # rest is same as above }; };</code></pre> You reboot, pick the vfio</code> entry , and reboot back to normal afterwards. Either way, confirm after booting: $ lspci -nnk -s 01:00.0 | grep 'in use' Kernel driver in use: vfio-pci</code></pre> Dynamic GPU passthrough (w/o reboot) is possible, but is cumbersome and comes with its own set of drawbacks Building the VM§</a > </h1> First, enable libvirt/QEMU on the host. The essentials are libvirtd</code> itself, swtpm</code> (the software TPM that Windows 11 requires), SPICE USB redirection, and virt-manager</code> to drive it all - plus adding your user to the libvirtd</code> and kvm</code> groups so you can manage VMs and open /dev/kvm</code> without sudo</code>: { pkgs, ... }: { virtualisation.libvirtd = { enable = true; qemu = { package = pkgs.qemu_kvm; runAsRoot = false; swtpm.enable = true; }; }; virtualisation.spiceUSBRedirection.enable = true; programs.virt-manager.enable = true; users.users.<you>.extraGroups = [ "libvirtd" "kvm" ]; }</code></pre> The guest disk should be a raw block device or image (rather than an emulated SATA disk) for performance. I back it with a sparse ZFS zvol (a qcow2</code> file works just as well): $ sudo zfs create -s -V 120G -o volblocksize=16k <pool>/vm/windows # appears as /dev/zvol/<pool>/vm/windows</code></pre> Now create a standard Windows 11 guest (virt-manager</code> makes this easy, you may refer to this guide</a>). The settings that matter: Q35 chipset + UEFI/OVMF with Secure Boot, and TPM 2.0 (swtpm</code>) - Windows 11 requires the latter two.</li> host-passthrough</code> CPU.</li> virtio everywhere - disk (on the zvol above) with cache=none</code>, io=native</code>, discard=unmap</code>; virtio NIC (for performance).</li> Hyper-V enlightenments so Windows uses its kernel fast paths.</li> A QEMU guest agent channel.</li> </ul> On AMD, in the Hyper-V block, omit <evmcs/></code> - that enlightenment is Intel-only and the VM won't start with it. A good set: <hyperv mode="custom"> <relaxed state="on"/> <vapic state="on"/> <spinlocks state="on" retries="8191"/> <vpindex state="on"/> <runtime state="on"/> <synic state="on"/> <stimer state="on"/> <frequencies state="on"/> <tlbflush state="on"/> <ipi state="on"/> <avic state="on"/> </hyperv></code></pre> Since the disk is virtio, the Windows installer won't see it until you Load driver from the mounted virtio-win.iso</code> (viostor\w11\amd64</code>, then NetKVM</code> for network). After install, run virtio-win-guest-tools</code> for the rest. Finally, add the GPU (and its audio function) as PCI host devices. Looking Glass§</a > </h1> A passed-through GPU usually has no monitor attached, so Looking Glass</a> captures the guest framebuffer and passes it through a shared-memory device into a client window on the NixOS host, with very low latency. The transport is the kvmfr</code> kernel module, which exposes /dev/kvmfr0</code>: boot = { extraModulePackages = [ config.boot.kernelPackages.kvmfr ]; kernelModules = [ "kvmfr" ]; extraModprobeConfig = "options kvmfr static_size_mb=64"; }; # Add your user to the 'kvm' group to open the device services.udev.extraRules = '' SUBSYSTEM=="kvmfr", KERNEL=="kvmfr0", MODE="0660", GROUP="kvm", TAG+="systemd" ''; environment.systemPackages = [ pkgs.looking-glass-client ];</code></pre> Give the VM the matching ivshmem</code> device via a <qemu:commandline></code> block that points mem-path</code> at /dev/kvmfr0</code> (this needs xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'</code> on the root <domain></code> tag): <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='ivshmem-plain,id=shmem0,memdev=looking-glass,bus=pcie.0,addr=0x0a'/> <qemu:arg value='-object'/> <qemu:arg value='memory-backend-file,id=looking-glass,mem-path=/dev/kvmfr0,size=67108864,share=yes'/> </qemu:commandline></code></pre> Inside Windows, install the following: NVIDIA driver - Automatic via Windows Update. </li> A virtual display driver (MikeTheTech's VDD</a>) - gives the desktop a head to render on. Its config (C:\VirtualDisplayDriver\vdd_settings.xml</code>) can pin the virtual display to a specific GPU and define exact modes, so bind it to the passed-through GPU at your native resolution: <vdd_settings> <monitors><count>1</count></monitors> <gpu><friendlyname>NVIDIA GeForce RTX 4060 Laptop GPU</friendlyname></gpu> <resolutions> <resolution><width>2560</width><height>1600</height><refresh_rate>165</refresh_rate></resolution> </resolutions> </vdd_settings></code></pre></li> Looking Glass (host) - its build must match the client build exactly. Its installer also provides the IVSHMEM driver for the "PCI standard RAM Controller" device in Device Manager. Install it as a service (looking-glass-host.exe InstallService</code>) rather than launching it interactively - the service can capture the secure desktop, so UAC prompts don't black out the stream, and it starts at boot on its own. </li> </ol> Then run looking-glass-client</code> on the host, and a full-resolution Windows desktop appears in a window, GPU-accelerated, captured off the GPU framebuffer over DirectX 12. Keyboard, mouse and clipboard ride back over SPICE. Performance tuning§</a > </h1> The values below (which cores, how many hugepages) are machine-specific - compute them from your own topology. CPU pinning§</a > </h2> By default the scheduler shuffles vCPUs across host threads and runs QEMU's emulator/IO threads on top of them, which shows up as frame-time spikes. Pin each guest vCPU to a fixed host thread, matching SMT siblings, and push the emulator/IO threads onto separate housekeeping cores. Find your sibling pairs first: $ cat /sys/devices/system/cpu/cpu*/topology/thread_siblings_list</code></pre> For a 6-vCPU guest whose host has siblings N</code>/N+8</code>, mapping three physical cores (2, 3, 4) and keeping cores 0–1 for the host: <vcpu placement='static'>6</vcpu> <iothreads>1</iothreads> <cputune> <vcpupin vcpu='0' cpuset='2'/> <vcpupin vcpu='1' cpuset='10'/>  <vcpupin vcpu='2' cpuset='3'/> <vcpupin vcpu='3' cpuset='11'/>  <vcpupin vcpu='4' cpuset='4'/> <vcpupin vcpu='5' cpuset='12'/>  <emulatorpin cpuset='0-1,8-9'/> <iothreadpin iothread='1' cpuset='0-1,8-9'/> </cputune></code></pre> Assign that iothread to the virtio disk so storage interrupts stay off the cores: <driver name='qemu' type='raw' cache='none' io='native' discard='unmap' iothread='1'/></code></pre>Core isolation§</a > </h2> Pinning chooses which host threads the guest uses - isolating those cores stops the host from scheduling its own work there. If your passthrough lives in a dedicated boot entry, scope the isolation to it so it costs nothing during normal use: boot.kernelParams = [ "isolcpus=2-4,10-12" "nohz_full=2-4,10-12" "rcu_nocbs=2-4,10-12" ];</code></pre>Hugepages§</a > </h2> Backing the guest RAM with 1 GiB hugepages reduces TLB misses and the cost of memory virtualisation (more about latency consistency than throughput). Reserve them at boot - and since they're held exclusively, this is another good thing to scope to the boot entry: boot.kernelParams = [ "default_hugepagesz=1G" "hugepagesz=1G" "hugepages=16" ]; # 16 GiB</code></pre> Request them in the domain, and drop the memory balloon (it fights fixed hugepage-backed RAM): <memoryBacking><hugepages><page size='1048576' unit='KiB'/></hugepages></memoryBacking> ... <memballoon model='none'/></code></pre> Keep these in sync: the <cputune></code> cpuset must match isolcpus</code>, and the hugepage count must match the guest's RAM. </blockquote> Other tweaks§</a > </h2> Run the host CPU governor at performance</code> (powerManagement.cpuFreqGovernor = "performance"</code>). Inside Windows, a few standard tweaks help: bcdedit /set useplatformclock No</code> - with Hyper-V enlightenments on, leaving it enabled hurts performance.</li> Disable SysMain / SuperFetch, set Visual Effects → best performance, and disable ScheduledDefrag (never defrag a virtio disk).</li> </ul> Declarative Domain configuration§</a > </h1> NixVirt</a> manages libvirt domains from Nix and accepts an XML file directly: { inputs, pkgs, ... }: { imports = [ inputs.nixvirt.nixosModules.default ]; virtualisation.libvirt = { enable = true; package = pkgs.libvirt; connections."qemu:///system".domains = [ { definition = ./windows.xml; active = null; } ]; }; }</code></pre> active = null</code> is important: NixVirt redefines the domain on every rebuild but never starts, stops or destroys a running guest. If you use impermanence (an erase-on-boot root), the domain definition is now regenerated from Nix, so you only need to persist the actual state. Two directories matter: environment.persist.directories = [ "/var/lib/libvirt" # NVRAM, swtpm state, networks "/var/lib/systemd" # Host key that decrypts libvirt's secrets ];</code></pre> Also ensure the disk image itself is persisted. Networking§</a > </h1> The virtio NIC on libvirt's default network gives the guest internet through NAT out of the box. Just run the following command once: $ virsh -c qemu:///system net-autostart default</code></pre>File sharing§</a > </h1> virtiofs</a> shares a host directory straight into the guest over a shared-memory transport - much faster than SMB. Point a <filesystem></code> device at the host path and give it a tag: <filesystem type='mount' accessmode='passthrough'> <driver type='virtiofs' queue='1024'/> <source dir='/data/files'/> <target dir='Files'/> </filesystem></code></pre> The device needs access to guest RAM, so the memory backing must be shared: <memoryBacking> <hugepages><page size='1048576' unit='KiB'/></hugepages> <access mode='shared'/> </memoryBacking></code></pre> Host-side, libvirt spawns the virtiofsd</code> daemon - just hand it the package: virtualisation.libvirtd.qemu.vhostUserPackages = [ pkgs.virtiofsd ];</code></pre> Inside Windows, the virtio-win-guest-tools</code> installer ships the VirtIO-FS driver and the VirtioFsSvc</code> service. You must additionally install WinFSP</a> - the user-mode filesystem layer it depends on, then start the service so it mounts (set it to Automatic so it survives reboots): > sc start VirtioFsSvc</code></pre>USB passthrough§</a > </h1> For an ad-hoc device, virt-manager</code> is the easiest route: open the running guest, Add Hardware → USB Host Device, pick it from the list, and it's hot-plugged into Windows. SPICE USB redirection is also enabled, so the Redirect USB Device menu option can be used as well. For something you want always attached - say a webcam - bind it by USB ID in the domain instead. Find it with lsusb</code>: $ lsusb Bus 003 Device 002: ID 3277:0018 Sonix Technology Co., Ltd. USB2.0 FHD UVC WebCam</code></pre> Then add a USB <hostdev></code>: <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x3277'/> <product id='0x0018'/> </source> </hostdev></code></pre>Useful commands§</a > </h1> Run as your user (in the libvirtd</code> + kvm</code> groups, no sudo</code> needed): $ virsh -c qemu:///system list --all $ virsh -c qemu:///system start windows $ virsh -c qemu:///system shutdown windows --mode=agent # Clean shutdown $ virsh -c qemu:///system destroy windows # Force off $ virsh -c qemu:///system net-dhcp-leases default # Guest IP # Peek at the guest headlessly $ virsh -c qemu:///system screenshot windows --file /tmp/vm.ppm $ nix shell nixpkgs#imagemagick -c magick /tmp/vm.ppm /tmp/vm.png</code></pre>Wrapping up§</a > </h1> You may refer to my own configuration</a>, which sets up all of the above (on the host valkyrie</code>), if you'd like a reference.

Prelude Unknown — Wed, 17 Dec 2025 00:00:00 +0000 I don't know Linux§</a > </h1> Go away. If you’re looking for a beginner’s guide, this is not it. This is a postmortem of a bad idea that worked. I sadly do not possess much time, and quite frankly, most of the rest of this page/series will go over your head. However, if your tastes are sufficiently messed up - or if you enjoy watching someone over-engineer their computer to the point of absurdity - this might hopefully be a fun read. My entire life has been a contradiction of sorts, notwithstanding the OS I currently use. I chose arguably the most difficult distro to learn to use specifically so I would never have to learn how to fix it again. What is this "NixOS" thing?§</a > </h1> If you've ever used Linux before (like Ubuntu or Arch), you know the drill: you install the OS, you run a bunch of terminal commands to install software, you edit a text file here and there, and eventually, you have a system that feels like home. But you also know the fear. The fear that if you delete the wrong file, mess with the wrong package, or even upgrade to a new release, your computer might implode, and you'll have no idea how to get back to the way things were. That's it I'm <redacted> switching back to Windows forever --> Me (right after the 69420th distro-hop that caused my system to crash and burn)</del> </blockquote> NixOS is different. Basically, you define a blueprint - a single configuration file that describes exactly how you want your computer to function. You want Firefox? You write firefox</code> in the file. You wanna set your wallpaper? Just chuck it into the file. After you're done, Nix</a> reads it, and builds your entire operating system to match exactly what you wrote. If you mess up, you just undo the text in the file, and your computer goes back to being perfect. And oh, lest I forget to mention, you’d never have to deal with the godforsaken dependency hell 1</a>. And now for the theatrics... The Descent into Madness§</a > </h1> It started innocently enough. I just wanted a system that was reproducible. I began with Nix Flakes, the "Gateway Drug" 2</a> of the ecosystem. Instead of vaguely gesturing at a repository and hoping for the best, flake.nix</code> declares every input my system depends on, and flake.lock</code> pins each one to an exact revision. It is the ultimate insurance policy: if I build this system today, or in about 10 years in the midst of an imminent meteor strike, I will get the exact same system 3</a>. But having a reproducible system wasn't enough. It had to be obedient. I pulled in Home Manager</a> because configuring the OS wasn't enough; I needed to micromanage my user config files too. Then came Stylix</a>. I declare a single image and a color scheme, and Stylix enforces this theme across everything. It generates CSS for Waybar</a>, restyles all my apps, and even bullies my terminal into submission. But why stop there? I grabbed Spicetify</a> to force Spotify to match my aesthetic, and Nixcord</a> for Discord cuz why the heck not. "Okay, it's pretty," you say. "But is it useful?" You have no idea 3</a>. I don't "install" development tools. I have a directory</a> that defines isolated environments for C++, Python, JavaScript and so on. When I cd</code> into a project, Direnv</a> and Lorri</a> kick in, and the compiler, linter, LSP and whatnot along with all of their configuration just appear in my shell. When I leave, they vanish. Every little thing is specified in code, from backups to network settings and even complex editor workflows (thanks for your concern, but I very likey my trusty VS Code</a>). Heck, even my Printer configuration is defined in a Nix file. Well what else do ya need? I still wanted to play games and run Android apps. A normal person would dual-boot or use an emulator. I run Waydroid</a> to run Android in a container. Then, for the pièce de résistance, I set up VFIO</a> GPU Passthrough 4</a>. I pass that GPU directly into a Windows VM and use Looking Glass</a> to stream the video output back to my PC screen with negligible latency. I've also declaratively configured Minecraft Servers</a> (cuz that 2 week period happens every other month for me, don't judge). At this point most people would stop Well I didn't. I needed to know that my system was spiritually pure. So I formatted my drive with ZFS</a> (its own merits</a> aside) and implemented Impermanence</a>. Every time I reboot, my root dataset rolls back to an empty snapshot. Wiped. Gone. My OS comes back from a blank slate every boot, preserving only what I explicitly whitelist on a separate dataset. To manage secrets without em dying in the purge, I use sops-nix</a> to encrypt passwords and API keys using GPG, directly into my publicly hosted git</code> repo, without leaking any sensitive data. The result of all this? If I buy a new computer today, I don't spend a week installing drivers and recovering my workflow. I clone my repository. I run one single command. And I doomscroll</del>. Soon as I return 3</a>, I spin up an AAA Windows game, displayed on a tiling Linux WM (heck, even choose between Hyprland</a> and Niri</a>), on a system that deletes and rebuilds itself on every boot. God, I love NixOS, and I hate it cuz now I can't go back to anything else. A Fair Warning§</a > </h1> Before you rush off to install this magical operating system, we need to have a serious chat. NixOS is hard. And I don't mean "Linux is hard" kind of hard. Its more "I have to relearn how everything works" kind of hard. It is not standard Linux: Most tutorials you find on the internet simply will not work here. You can't just apt install</code> your problems away.</li> The Documentation is... sparse: Sometimes you will be reading a manual, and sometimes you will be reading 10-year-old Reddit threads praying for an answer.</li> Patience is key (or severe OCD tbh): If you are not acquainted with the command line, programming languages, random crash logs, or want a computer that "just works" to play games or browse the web, consider yourself warned. Cuz this setup costs time, sanity, and a concerning amount of self-restraint.</li> </ul> Still Reading?§</a > </h1> If you really want to get dirty with Nix and decide to invest oodles of your time into building your own configuration, my repository</a> can be used as inspiration. You can check out the list of links below to resourceful Nix documentation/tutorials/projects that may be helpful in your endeavour, as they were in mine. Links§</a > </h2> See: A Curated List</a> of the best resources in the Nix Community Also: This</a> website for beginners starting out with NixOS and Flakes Official Documentation</a></li> NixOS Manual</a></li> Nix Pills</a></li> NixOS Discourse</a></li> NixOS Package Search</a></li> nixpkgs</code></a> Package Repository</li> NUR</a> Nix User Repository</li> NixOS Hardware Modules</a></li> Home Manager Options</a></li> </ul> Other Sources§</a > </h3> Tweag Article</a> introducing Flakes</li> Serokell's Blog</a> on Flakes</li> Jordan Isaac's Blog</a> for porting configuration to Flakes</li> Jon Ringer's Videos</a> on general NixOS Tooling and Hackery</li> Justin's Notes</a> on using Nix</li> Lan Tian's Series of Blog Posts</a> on NixOS</li> Christine's Blog Posts</a> addressing NixOS Security</li> Graham's</a> and Elis'</a> Blog Posts on Ephemeral Partition Schemes</li> </ul> Other Configurations§</a > </h3> Here are some repositories that I may have shamelessly rummaged through for building my dotfiles</code>: Thanks a lot! ;) 4JX</a></li> balsoft</a></li> bbigras</a></li> cole-h</a></li> colemickens</a></li> davidtwco</a></li> fufexan</a></li> gvolpe</a></li> hlissner</a></li> jordanisaacs</a></li> kclejeune</a></li> lovesegfault</a></li> lucasew</a></li> nobbz</a></li> rasendubi</a></li> sioodmy</a></li> tejing1</a></li> vlaci</a></li> wiltaylor</a></li> wimpysworld</a></li> </ul> ^1Wiki</a> for life </div> ^2Meaning</a> ig </div> ^4Arch Wiki</a> my love </div> ^{3 T&C Apply ;) </div>} Hello World! Unknown — Tue, 15 Feb 2022 00:00:00 +0000 Hello World! Just following tradition ;) This website is generated by Zola</a> using a modified version of the zerm</code></a> Theme, with support for custom color schemes, and math typesetting using $\KaTeX$</a> Check out the Test Page</a> to view the capabilities of this website

maydayv7

Windows VM

Prerequisites§</a > </h1> CPU support for IOMMU</strong></p> </li>

Prelude

Hello World!