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 use qemu to virtualize a Windows machine. I run KDE with Virt Manager, so i created a new VM, selected Windows 11 and everything else worked normally.
virtio-win allow for much better performance using virtualized drivers rather than plain emulation from qemu. Virt Manager doesn’t offer windows guest paravirtualized drivers, that’s on the guest side, and virtio-win ISO helps a lot with this.
I used to have issues with the different processor types, I used to downgrade to the core2duo to get things to boot.
Oh huh. Is that a QEMU option? I’m new to all this.
Yep, and there’s a shocking number of them to pick from: https://www.qemu.org/docs/master/system/qemu-cpu-models.html
Oh wow! Thanks for this. I’m learning.
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.
it sounds like you’re either missing a boot loader or it’s not configured correctly.
did you install grub on the vhdx? what’s the boot up order for your vm?
Habe the same Problem. What exactly die you change? Generating the Image in the Windows side?
Forgot to include the boot/system volume. It’s a lovely time waster when you’re dealing with disk images that are hundreds of gigabytes in size that have to be copied over the network. 😆
I’ll add Disk2hvd screenshots when I get a sec.
Situation gets slightly more complicated if you had multiple drives in your system when you installed Windows, of course. Installer might put system volume on a different drive, so you’d have to image more than one drive to get a working system. Might get a little confusing as to which volumes should go in which image. There’s a tool called GWMI that might help with that since afaik the volume guids don’t show up in the Windows Disk Management snap-in.
Edit: The promised screenshot. In my case, I knew the volume labelled SYSTEM resided on the same disk as my C: drive. Probably don’t have to include the recovery partition, strictly speaking, but I did.
