ToddAndMargo via users writes:
By the way, the "registry hack" came from Microsoft itself. So it will probably be around for a long while.
I'm aware of that. I just don't trust them. If you note, they put up all sorts of disclaimers and caveat-emptors on that. I don't get the same warm and fuzzy feeling, myself. I think that this is just a temporary stopgap, while Microsoft makes up its mind what to do with this crapstorm. If they decide to pull the plug, they'll just do it, and give a song-and-dance routine about how some feature in the 22H1 update, or something, means that, super-sorry, the hacks don't work. You need TPM and secure boot. And a new CPU.
Well, I just piddled away half of my weekend, on this crap. But I think I've got it, by "it" meaning: as much as I can possibly expect to get out of stock qemu. I have Windows 10 21H1 running in a Windows 10 VM that originally traces its lineage to Windows 7, and its digital license. It's running in EFI+secure boot mode, and a clean bill of health in "Security Processor" – both "Encryption" and "Device Attestation" show as "Ready".
Earlier this morning (before this long day begun) Settings popped up a new, never before seeing, scary red message (I mentioned this before), telling me that I don't have enough mojo to update to Windows 11, and inviding me to run the "health check" to see if "maybe" I could do something.
This is now gone, and replaced by a slightly less scary message. It doesn't outright say that all systems are go in my case. It's just saying something along the lines of "see if your hardware is supported", which is a linked to a Windows page that says, more or less, "We're working on figuring it out". I suspect that Windows is seeing my old CPU, but Microsoft hasn't decided whether to allow upgrades to that configuration yet. But it's now a done deal: yes, you can get qemu to run Windows 10 in secure boot and an emulated TPM 2.0 chip.
So, looks like I'm in a holding pattern: to see what Microsoft decides, or maybe our brilliant qemu friends, who are much smarter than me, can figure out how to emulate a CPU to Microsoft's likings.
I took notes, and I'll need some time to clean them up, and, dunno, I think I'll post them to the Fedora wiki, after I clean them up. But, TLDR, the way to do this:
A) You need a retail Windows license (pretty much the only way to run a licensed Windows in a VM)
B) You MUST have a Microsoft account, and your VM registered to your Microsoft account
C) My VMs did not have the virtio drivers for Windows. I have no idea if the virtio drivers are signed. You need signed drivers for secure boot. Someone else will have to figure out if a virtio-based Windows 10 VM can be updated in this manner.
D) Your VM disk image needs to be in a qcow2 format solely because it makes it easy to snapshot it, and rewing it if you mess up, and end up with a brick. I used a lot of snapshots…
E) You need to do the migration in two steps, creating a new VM in each step (pointing to the same disk image), cutting over to the new VM and making sure that Windows settles down in its new home.
F) The first VM gets set up using virt manager's default Windows 10 configuration, but with manual configuration that adds a TPM 2.0 TIS chip. Windows 10 will see the chip, and partially support it. It needs to be initialized in Windows, so that Windows gets married to this TPM chip, first, before taking the plunge into EFI and secure boot. It might be possible to do everything in one big jump. But someone else will need to figure that out.
G) When everything is ready, use mbr2gpt to create a GPT partition (there are some tricky details to that that required piecing together multiple Google searches), then shut down, and create the 2nd VM, same configuration but using qemu's secure boot firmware. Additionally a manual step is needed to copy the emulated TPM chip's files from the first to the second VM; as well as set up the VGA resolution in the EFI firmware (that was new to me) before secure-booting Windows 10 for the first time.
H) It may also be be necessary to set up the secure boot VM's NIC to the same mac address as the first VM's NIC. Virt manager won't let you create VMs with the same NIC, so it's necessary to virsh-edit the first VM's configuration and manually change its Mac address, then put the original one into the EFI VM. Not actually sure if you need to do this, but Windows kept secure-booting successfully but refusing to activate, and I was trying to keep all the changes to the minimym.
I finally discovered how to activate it using the former VM's license, and it was fairly straightforward once I figured out the right incantation, in Settings, how to do it. So, it might not be necessary to mess around with MAC addresses, but I can't be sure of that. I can only be sure of what worked for me.
So, I'm in a holding pattern now, waiting to see what happens in Microsoft- verse, and if qemu will pull a new CPU rabbit out of their hat. I still have a snapshot of this VM's disk before its secure-boot conversion (even though its licensed has been moved to the EFI VM, but I think I'll be able to transfer it back, if needed), so I have that to go back to. I doubt I'll need to. Although the new VM is notably slow, it feels stable.
Big, big thanks to qemu and virt-manager folks.
pgptxa7CSGnBY.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
