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. 👍
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.
