Windows 11 VM on Omarchy (Arch) — setup summary and issues

I set up a Windows 11 guest on Omarchy (Arch-based) with QEMU/KVM and virt-manager, primarily for Visual Studio 2022, WinForms, and other Windows-only tooling. No GPU passthrough — VirtIO and SPICE are enough for desktop responsiveness.

This post is a setup record and a troubleshooting log for the networking problems that took the longest to sort out.

Host and VM configuration

Item	Value
Host OS	Omarchy (Arch-based)
Hypervisor	QEMU/KVM
Manager	virt-manager
Libvirt connection	System (`sudo virsh` required)
VM name	`win11`
Firmware	UEFI (OVMF)
CPU	host-passthrough, 6 vCPUs
RAM	12 GB
Disk	128 GB qcow2
Network	Virtual network `default`

Windows 11 installed successfully. The NIC was later switched from e1000e to virtio after the guest tools were in place.

Problems encountered

1. No network during Windows setup

Windows could not finish OOBE without Internet. From the setup screen:

Shift + F10 to open a command prompt
Run OOBE\BYPASSNRO
Restart and continue offline

That cleared the network requirement so install could finish.

2. DHCP not working

After boot the guest showed a link-local address (169.254.x.x), and ipconfig /renew hung forever.

On the host, the usual pieces looked fine:

sudo virsh net-list --all
# default  active  yes

ip addr show virbr0
# 192.168.122.1/24

sudo ss -lunp | grep :67
# dnsmasq listening

So libvirt’s default network and DHCP daemon were up, but the guest still got nothing useful.

3. UFW blocked DHCP

Allowing DHCP on the libvirt bridge fixed address assignment immediately:

sudo ufw allow in on virbr0 to any port 67 proto udp

The VM then received a 192.168.122.x address.

4. DHCP worked, Internet did not

With a lease, ping 1.1.1.1 still failed. Disabling the firewall made outbound traffic work instantly:

sudo ufw disable

UFW was clearly interfering with libvirt NAT/forwarding, not just DHCP.

5. UFW forward and NAT rules

I changed /etc/default/ufw:

DEFAULT_FORWARD_POLICY="ACCEPT"

and added a MASQUERADE rule in /etc/ufw/before.rules for the default libvirt subnet out through the host Wi‑Fi interface:

*nat
:POSTROUTING ACCEPT [0:0]

-A POSTROUTING -s 192.168.122.0/24 -o wlan0 -j MASQUERADE

COMMIT

Then re-enabled UFW. Connectivity was still inconsistent.

6. Bridge issue: vnet not enslaved to virbr0

While the VM was running:

sudo virsh domiflist win11
# interface: vnet3

but the bridge itself looked dead:

ip addr show virbr0
# NO-CARRIER, state DOWN

sudo bridge link
# vnet3 was NOT listed as master virbr0

The tap device existed, yet it was not attached to virbr0. That explains why NAT/firewall tweaks alone felt flaky — the guest was not actually on the bridge.

7. Manual bridge attachment

Enslaving the tap device fixed it immediately:

sudo ip link set vnet3 master virbr0

virbr0 went LOWER_UP, and networking started working. The remaining host-side question is why libvirt is not automatically attaching vnetX to virbr0 after certain network/firewall changes.

VirtIO

Downloaded virtio-win.iso, ran virtio-win-guest-tools.exe inside the guest, then changed the NIC model from e1000e to virtio. Drivers installed cleanly and networking continued to work.

Current status

Working:

Windows 11
Internet
VirtIO NIC
VirtIO guest tools
KVM acceleration

Outstanding:

The vnetX interface sometimes needs a manual ip link set … master virbr0 after network or firewall changes. That attachment should be automatic via libvirt, so there is likely a host-side issue involving libvirt, bridge handling, or firewall interaction still to investigate.

Goal for this VM

Primary use:

Visual Studio 2022
WinForms development
.NET development
General Windows-only tooling

No GPU passthrough planned; good desktop responsiveness with VirtIO/SPICE is enough.