Most XenDesktop deployments are not rolled out all at once – they are usually done in phases: demo, pilot, test, initial, major, and completion. And more often then not, these phases span months if not years depending on the size of the project. Or sometimes hardware is purchased at different times and happens to be before and after a release of new processor tech. The below error can be a bit hard to track down:
The root cause of the problem is dissimilar compute hardware – more specifically different processors. This can be very similar hardware – X5550 and X5560 – same processor family and instruction set, with a different clock speed…or completely different processor – E5-2650 and E5-2650V2. How do these differences happen?
In VMware, this happens thanks to a trick known as EVC, or enhanced vmotion compatibility. On a cluster, this allows for hosts with newer processors to join a cluster and also prevents issues when vmotioning between different hosts by masking the CPUID to match the lowest hardware capabilities.
The problem is that EVC works great when you’re talking about vMotion and CPU instruction sets, but NOT when the VM boots cold on a new host – and in this case, a different host than the master PVS image was built on. While EVC will mask the capabilities and instruction set of the processor, it does NOT mask the name of the processor. So when you boot on a different host, Windows will detect a different processor and kick off UPNP.
And thus a reboot is requested.
The moral of the story? Keep your XenDesktop machines in a VMware cluster with 100% identical hardware.
Thanks – you saved me a lot of trouble!
Do you know if we put the PVS image on maintenance and reboot will it stop the prompt on the new Hosts ?
kc,
No, it will not.
Hey KC, that’s an old thread but it’s still time to bring my 2 cents 😉
As you suggested it, if you migrate your master onto a host having “new” physical processors, and then boot it in maintenance mode, the UserPNP event will show up, you will have to reboot but then the hardware repository will have been updated and you won’t be prompted anymore to reboot (at least until you bring up a new host in your cluster ;-).
Kind regards.
Yvan