What finally got my existing Win10 guest VM (originally upgraded from Win7) to see a TPM2 device was the following process:
1) Make a copy of the raw disk image. This isn't really necessary, but I did this for backup purposes.
2) In virt-manager I created a new VM, pointing to the existing raw disk image, and directed it to use the canned "Windows 10" operating system configuration, and also selecting the manual configuration option, and then using that to add the TPM2 module. Google searches seemed to suggest that the "TIS" model is the one to use, so that's what I selected.
3) This creates a new VM with the emulated "Q35" chipset, rather thanthe existing i440fx chipset, that Win7 was originally configured for. This is the trick, apparently.
When I booted the new VM, Windows 10 went through some noticable setup and reconfiguration, but it did survive the transplant. The only result was it required me sign into my Microsoft account (I recommend that the Win10 seat be registered to a Microsoft account before doing this, this appears to be the simplest way to avoid license/activation problems). Over the next couple of minutes Windows10 also popped up occasional prompts about setting up this PCI device, or that PCI device. But nothing seemed to indicate a problem with the new VM.
And it now sees the TPM2 device, however it does show a "Device health attestion isn't available" because "Your device does not support this feature". After a few minutes it offered me the option to "Clear TPM" to fix this issue (initially the button was disabled, but it became enabled a few minutes after the boot). However that made no difference, this status remained after the "Clear TPM" and the reboot.
I have another Win10 license which I'll try, later, with the other "CRB" emulated TPM model, to see if that works fully. It's also possible that this is it's way of expressing that it knows it's running in a VM. And it now sees the TPM2 device, however it does show a "Device health attestion isn't available" status because "Your device does not support this feature".
Is anyone else getting this error in the "Security processor troubleshooting" (21H1, with all updates installed)?
On 20/09/2021 00:08, Sam Varshavchik wrote:
Is anyone else getting this error in the "Security processor troubleshooting" (21H1, with all updates installed)?
It has been nearly 2 months since I worked on this. But, yes, that is what I was seeing. No matter what I did I could not get passed that issue. I gave up and moved on to installing Win11.
-- Nothing to see here.
Ed Greshko writes:
On 20/09/2021 00:08, Sam Varshavchik wrote:
Is anyone else getting this error in the "Security processor troubleshooting" (21H1, with all updates installed)?
It has been nearly 2 months since I worked on this. But, yes, that is what I was seeing. No matter what I did I could not get passed that issue. I gave up and moved on to installing Win11.
I think I figured it out. That message has nothing to do with the TPM chip per se, real or emulated. In "Security Processor" there was a similar, vague message, but with a "more information" link. That goes to a web page, which is full of Microsoftese. Rather than describing what it wants in clear technical terms, it meanders on topics like "basic security requirements", "enhanced security requirements", and similar handwaving. I reread that five times, then I figured out that it wants UEFI+Secure Boot, to make this warning message go away.
All the Win11 press was about the TPM 2.0 requirement, there was no mention of a UEFI+Secure Boot requirement for upgrading, but I wouldn't want to draw any conclusions.
Sam Varshavchik writes:
Ed Greshko writes:
On 20/09/2021 00:08, Sam Varshavchik wrote:
Is anyone else getting this error in the "Security processor troubleshooting" (21H1, with all updates installed)?
It has been nearly 2 months since I worked on this. But, yes, that is what I was seeing. No matter what I did I could not get passed that issue. I gave up and moved on to installing Win11.
I think I figured it out. That message has nothing to do with the TPM chip per se, real or emulated. In "Security Processor" there was a similar, vague message, but with a "more information" link. That goes to a web page, which is full of Microsoftese. Rather than describing what it wants in clear technical terms, it meanders on topics like "basic security requirements", "enhanced security requirements", and similar handwaving. I reread that five times, then I figured out that it wants UEFI+Secure Boot, to make this warning message go away.
All the Win11 press was about the TPM 2.0 requirement, there was no mention of a UEFI+Secure Boot requirement for upgrading, but I wouldn't want to draw any conclusions.
I tried to give one more college try with another, licensed, VM. I found very useful reading material here: https://ogris.de/howtos/windows-uefi- virtio.html
So, I took my other, licensed, Windows 10 VM and tried the same thing I did with the other one, except that this time I also converted the raw disk image to qcow2. Afterwards, like before, I created a new VM from scratch, pointed it to the new disk image and manually added TPM 2.0 hardware. The new VM booted fine.
This looked promising. I shut it down, created a qcow2 snapshot, booted the VM, ran mbr2gpt, as described there, to convert the MBR to GPT. mbr2gpt first claimed that it succeeded, but also complained something about ReAgent.xml, and told me that I need to enable EFI in my firmware, when I reboot. So I shut down the VM, creating another VM, this time selecting the secboot EFI firmware.
Windows did boot, but came up in 640x480 mode with basic drivers, unactivated, and refused to activate, wanting me to pay for a license. The explanation it gave me: new hardware. This was a retail license, though, which should be transferable.
I cut the experiment short, shut down the EFI VM, restored the qcow2 snapshot, and went back to the BIOS VM. It came up fine.
I see two possible reasons: 1) It's been documented how Windows unactivates after what it considers to be too many hardware changes, or maybe 2) it is necessary to update to EFI first, then add a TPM module. The new EFI VM has its own separate TPM module, so Windows doesn't find the same TPM chip it already saw, so it does not activate.
It's unclear if Win11 requires just a TPM chip, or TPM+secure boot. I don't recall anyone mentioning a secure boot requirement, just TPM, which does seem to work, by creating a new VM.
In a couple of months, if neither one of my VMs offer a Win11 upgrade I'll try to switching to an EFI VM, and copy swtpm's data to the new VM's swtpm, before the first boot, and see what happens…
On 24/09/2021 06:52, Sam Varshavchik wrote:
Sam Varshavchik writes:
Ed Greshko writes:
On 20/09/2021 00:08, Sam Varshavchik wrote:
Is anyone else getting this error in the "Security processor troubleshooting" (21H1, with all updates installed)?
It has been nearly 2 months since I worked on this. But, yes, that is what I was seeing. No matter what I did I could not get passed that issue. I gave up and moved on to installing Win11.
I think I figured it out. That message has nothing to do with the TPM chip per se, real or emulated. In "Security Processor" there was a similar, vague message, but with a "more information" link. That goes to a web page, which is full of Microsoftese. Rather than describing what it wants in clear technical terms, it meanders on topics like "basic security requirements", "enhanced security requirements", and similar handwaving. I reread that five times, then I figured out that it wants UEFI+Secure Boot, to make this warning message go away.
All the Win11 press was about the TPM 2.0 requirement, there was no mention of a UEFI+Secure Boot requirement for upgrading, but I wouldn't want to draw any conclusions.
I tried to give one more college try with another, licensed, VM. I found very useful reading material here: https://ogris.de/howtos/windows-uefi-virtio.html
So, I took my other, licensed, Windows 10 VM and tried the same thing I did with the other one, except that this time I also converted the raw disk image to qcow2. Afterwards, like before, I created a new VM from scratch, pointed it to the new disk image and manually added TPM 2.0 hardware. The new VM booted fine.
This looked promising. I shut it down, created a qcow2 snapshot, booted the VM, ran mbr2gpt, as described there, to convert the MBR to GPT. mbr2gpt first claimed that it succeeded, but also complained something about ReAgent.xml, and told me that I need to enable EFI in my firmware, when I reboot. So I shut down the VM, creating another VM, this time selecting the secboot EFI firmware.
Windows did boot, but came up in 640x480 mode with basic drivers, unactivated, and refused to activate, wanting me to pay for a license. The explanation it gave me: new hardware. This was a retail license, though, which should be transferable.
I cut the experiment short, shut down the EFI VM, restored the qcow2 snapshot, and went back to the BIOS VM. It came up fine.
I see two possible reasons: 1) It's been documented how Windows unactivates after what it considers to be too many hardware changes, or maybe 2) it is necessary to update to EFI first, then add a TPM module. The new EFI VM has its own separate TPM module, so Windows doesn't find the same TPM chip it already saw, so it does not activate.
It's unclear if Win11 requires just a TPM chip, or TPM+secure boot. I don't recall anyone mentioning a secure boot requirement, just TPM, which does seem to work, by creating a new VM.
In a couple of months, if neither one of my VMs offer a Win11 upgrade I'll try to switching to an EFI VM, and copy swtpm's data to the new VM's swtpm, before the first boot, and see what happens…
All I can say is you have more patience with Windows than I have. Way more. :-) :-)
-- Nothing to see here
Ed Greshko writes:
In a couple of months, if neither one of my VMs offer a Win11 upgrade I'll try to switching to an EFI VM, and copy swtpm's data to the new VM's swtpm, before the first boot, and see what happens…
All I can say is you have more patience with Windows than I have. Way more. :-) :-)
This is mostly intellectual curiousity, something to tinker with, and a learning experience. I learned about qcow2 snapshots by screwing around with this thing. They are very useful, without them it would be a mess. And I did learn that qemu is capable of booting Windows 10 in secure boot mode.
When I pick this up again, in a month or two (unless I get a good lead, earlier) the first step would be to figure out how to create a new VM in virt-manager but preserve the data in the emulated TPM chip, to see if that makes Windows 10 survive the firmware transplant. I see that it's in a directory whose name is te VM's random UUID. So, what will it be? Copy the existing VM's TPM directory to the new VM when it gets created? virt-manager seems to automatically start the new VM after creating it, I don't really see a reason for this behavior, but I'd have to force-off the VM to get its UUID. I don't remember if I can edit the XML file in the custom installation mode, maybe I can cut/paste and create a VM with the same UUID, so that virt- manager-started swtpm ends up loading the same data?
On Thu, Sep 23, 2021 at 6:52 PM Sam Varshavchik mrsam@courier-mta.com wrote:
Windows did boot, but came up in 640x480 mode with basic drivers, unactivated, and refused to activate, wanting me to pay for a license. The explanation it gave me: new hardware. This was a retail license, though, which should be transferable.
When I upgraded some VMs running Windows 7 on VirtualBox to Windows 10 on KVM I had to re-enter the license key for some of them. When you say it "refused to activate" did you mean that you re-entered the key and it rejected it? Or that it just didn't automatically accept the pre-existing key?
Go Canes writes:
On Thu, Sep 23, 2021 at 6:52 PM Sam Varshavchik mrsam@courier-mta.com wrote:
Windows did boot, but came up in 640x480 mode with basic drivers, unactivated, and refused to activate, wanting me to pay for a license. The explanation it gave me: new hardware. This was a retail license,
though,
which should be transferable.
When I upgraded some VMs running Windows 7 on VirtualBox to Windows 10 on KVM I had to re-enter the license key for some of them. When you say it "refused to activate" did you mean that you re-entered the key and it rejected it? Or that it just didn't automatically accept the pre-existing key?
The license key is used only when upgrading to Win10. From that point, Win 10 uses some kind of a digital entitlement license. All Win 7 seats that get a free upgade to Win 10 show the same license key, post upgrade.
Windows 10 only offered to sell a license, in order to activate itself, before I reverted the snapshot.
On Thu, Sep 23, 2021 at 10:09 PM Sam Varshavchik mrsam@courier-mta.com wrote:
Go Canes writes:
On Thu, Sep 23, 2021 at 6:52 PM Sam Varshavchik mrsam@courier-mta.com wrote:
Windows did boot, but came up in 640x480 mode with basic drivers, unactivated, and refused to activate, wanting me to pay for a license. The explanation it gave me: new hardware. This was a retail license,
though,
which should be transferable.
When I upgraded some VMs running Windows 7 on VirtualBox to Windows 10 on KVM I had to re-enter the license key for some of them. When you say it "refused to activate" did you mean that you re-entered the key and it rejected it? Or that it just didn't automatically accept the pre-existing key?
The license key is used only when upgrading to Win10. From that point, Win 10 uses some kind of a digital entitlement license. All Win 7 seats that get a free upgade to Win 10 show the sam
Yes, that is how it is *supposed* to work. But in the cases I mentioned, I had to re-enter the Windows 7 license key to get to activate. The "digital license" for Windows 10 (which as you indicated is the same for all the upgrades) would not work - the Windows 7 license key worked fine.
-
Ed Greshko -
Go Canes -
Sam Varshavchik