I have several ESX hosts running Intel Xeon 5050 processors. I just purchased a server that has a Xeon 5160 processor. When going to VMotion a VM, it complains about EAX and ECX registers. No problem - I modified the CPU masks in advanced options for the problematic virtual machine. I realize that I will have to make the CPU ID changes on every virtual machine in my environment if I want to migrate to/from ESX servers with different CPU classes. I also realize that VMware does not support this workaround (at least the documentation I was reading said that)
My question is: Have any of you experienced the same issue and used the same workaround? The documentation and VC messages say that changing the CPU ID masks may degrade performance in certain guest operating systems. If this is true, have any of you experienced any performance issues with your virtual machines in which you had to modify the CPU ID masks? I'm very weary of doing this to all production virtual machines in the environment.
I have to use masks and it is a common and neccesary task for growing environments and if it is in the GUI it is fully supported.
It's when you have to get creative with CPUID masks that they have issues on the recommended configuration side.
Interesting to know. It is good that I ran into it now rather than later. I was wondering how in the future if I added different CPU families how VMotion was going to be affected. Thanks for the input mike.
One last question regarding this. If I make the changes to the default CPU ID mask in Virtual Center's vpxd.cfg file, will it affect all of the virtual machines immediately or will I have to reboot all of the virtual machines for the settings to take effect. Also - my main concern is that there may be some performance degradation experienced by changing the mask. Can anyone confirm or deny this?
While I have not implemented a change like that after the fact, I do have some understanding of how it works. When you change the vpxd.cfg and restart the Virtual Center Service (allow for propagation time to the esx servers) the next VMotion will use the new CPU mask. I cannot tell you if this will work from the upper capable VMotion to a lower capable after a VM is powered on but logic would say no, assume a reboot or test on a non-critical VM. You will not loose any significant performance, it will simply not use the advanced features of a CPU e.g. large address memory support, new instructions etc.