It sounds like your VM config was presenting a COU or TPM config that the upgrade wasn’t comfortable with. If your new machine presented acceptable configs to a brand new VM, then making a new VM and feeding it the old .vhdx would be the same as pulling a storage device and putting it in a new motherboard that was win 11 compliant. After a reboot to install new drivers it probably would have upgraded happily.
Hmm, the only barrier to upgrading was that the i5 processor wasn’t supported, no complaints about TPM/motherboard compatibility and a fresh install worked fine on the exact same hardware. Oh well, it’s done anyway.
The hypervisor doesn’t necessarily present the guest the exact CPU you’re running. Maybe it was presenting an older model, or something stripped down that didn’t have the features win 11 was looking for. It’s moot.now that you found a solution but I believe this is what happened and moving the disks to a new VM probably would have worked.
I just went for a new installation. Why would that work? Just curious.
It sounds like your VM config was presenting a COU or TPM config that the upgrade wasn’t comfortable with. If your new machine presented acceptable configs to a brand new VM, then making a new VM and feeding it the old .vhdx would be the same as pulling a storage device and putting it in a new motherboard that was win 11 compliant. After a reboot to install new drivers it probably would have upgraded happily.
Hmm, the only barrier to upgrading was that the i5 processor wasn’t supported, no complaints about TPM/motherboard compatibility and a fresh install worked fine on the exact same hardware. Oh well, it’s done anyway.
The hypervisor doesn’t necessarily present the guest the exact CPU you’re running. Maybe it was presenting an older model, or something stripped down that didn’t have the features win 11 was looking for. It’s moot.now that you found a solution but I believe this is what happened and moving the disks to a new VM probably would have worked.