Final edit: I got all the Linux stuff right but made a dumb mistake generating the image on the Windows side. Watching the VM boot right now. Thanks to all for your support!
cross-posted from: https://slrpnk.net/post/15860280
Contemplating Fedora Kinoite for work daily driver. Need to prove that I can virtualize an existing physical Windows 11 machine. Using Bazzite on a personal laptop as a host test bed.
Test host seems to be set up correctly. I layered the packages in the virtualization group, layered virtio-win (from downloaded rpm package), added my user to the libvert group, and enabled libvirtd. After a reboot or two, I can connect with the Virtual Machine Manager and define my VM.
On physical machine I used Disk2vhd to generate a vhdx. Moved that file to the test host and converted to qcow2. Copied disk image to /var/lib/libvert/images and added it as my drive image when I defined the VM.
VM starts but will not boot. Stupid question: Should I have installed virt-win-gt-x64.msi from the virtio-win ISO on the source Windows install before I created the vhdx?
Edit: Since I posted, I installed a Debian guest from scratch in this environment and it runs like a champ. 👍
I don’t get this comment. Again, the virtio-win is an ISO that’s easily mounted on a qemu (whether libvirt environment or not, which is not required, it just helps making the qemu configuration easier), which comes with several virtualized drivers that accelerate the windows experience quite a bit.
Changing the storage driver is complex on plain qemu (I don’t think it’s easier through libvirt just because the heck of it, the issue is the windows guest), first one need to run qemu with a dummy storage driver using virtualized driver, so that windows detects it. On the guest one needs to install the driver for the discovered storage from the ISO, then reboot and the dummy disk can go away and windows will find a driver for the main disk). Other drivers like the ethernet one, graphics cards, memory baloon, and other stuff need to change the corresponding driver manually, but no need for immediate reboots, but for sure several reboots are expecting while changing the windows drivers.
I no longer use a VM for windows, thankfully, but here it’s a command line meant not to use a GUI qemu front end, but rather a Spice backend (requires virtualized special serial driver and special graphics driver):
qemu-system-x86_64 \ -name win-10 \ -enable-kvm \ -machine type=q35,accel=kvm \ -cpu host,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \ -smp cores=1,threads=2,sockets=1 \ -m 4G \ -device intel-iommu \ -device virtio-balloon \ -drive file=/home/vasqueja/.qemu/imgs/win10-coe.qcow2,index=0,media=disk,if=virtio,aio=native,cache.direct=on,l2-cache-size=10M \ -drive file=/usr/share/virtio/virtio-win.iso,index=1,media=cdrom \ -drive file=/usr/share/spice-guest-tools/spice-guest-tools.iso,index=2,media=cdrom \ -device virtio-net-pci,netdev=net0 \ -netdev tap,id=net0,ifname=tap0,script=no,downscript=no,vhost=on \ -usb \ -device usb-tablet,bus=usb-bus.0 \ -display none \ -vga qxl \ -device virtio-serial-pci \ -chardev spicevmc,id=spice0,name=vdagent \ -device virtserialport,chardev=spice0,name=com.redhat.spice.0 \ -spice unix,addr=/tmp/win10_spice.socket,disable-ticketing \ -chardev socket,path=/tmp/win10_qga.socket,server,nowait,id=qga0 \ -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 \ -device intel-hda -device hda-duplex \ -rtc base=localtime \ -monitor stdio \ -k es \ -device usb-host,bus=usb-bus.<...>,vendorid=<...>,productid=<...> \ -device usb-host,bus=usb-bus.<...>,vendorid=<...>,productid=<...> \ -device usb-host,bus=usb-bus.<...>,vendorid=<...>,productid=<...>
Some investigation on your side is required if wanting to use spice (to add copy/paste cabalities on the guest, but perhaps that’s not needed anymore with libvirt and some of the popular forntends from GTK/QT), and the QLX dirver needs to be chosen correctly since it depends on the windows version (there was one for windows 10, not sure if there’s a 11 one).
Again, all this just to improve the windows guest experience. Some of this might have been made easier through libvirt, but the windows side of the drivers is a manual windows process, one driver at a time, and using virtualized storage is tricky on windows guests…
BTW I was setting a tap interface, with IP tables, because I found it to be the easier way to share my host VPN connection with the guest, without the need to establish a host and a guest VPN connection…
Well before today, I’d never heard of virtio-win, and I’d never used KVM/QEMU for virtualization on Linux, and despite an error on my part I had a running VM by close of business. Thanks for stopping by.