VMware Cloud Community
burtond
Contributor
Contributor

ESX 3.5 CPU VMotion masking issue

I would like to open a bit of a discussion on the issue of CPU masking with ESX 3.5. Now I know there are some great references out there about CPU masking, but looking at the present and near future I am a bit worried. Here is my dilema and the main reason I am asking for insight:

Our environment has recently been upgraded from ESX 3.02 to 3.5, then to 3.5 update 1. Through this process we of course received the same CPU warning messages like everyone else about maintaining CPU compatibilities. What the message failed to say was that an explicit CPU mask was being created in the VMX file of EVERY vm. Someone might say, well that is for your protection. Well here is my problem, this mask is requiring bit 18 (ecx) Direct Cache Access, which is a new feature on the Intel quad-core CPU's that we have. In trying to VMotion from our IBM x3950's to our new x3850 M2's (dual-core to quad-core) the incompatibilities are SSSE3 (SSE4) and DCA, but from what I understand and have tested are not a problem when VMotioning from a CPU without these features to a CPU with them. Since we will not be going back I made the following changes to our vpxd.cfg file:

--:::-X:--:X-:--:----:::::XX:--:--</eax>

</level-1>

</default-vendor>

</cpuFeatureMask>

</all-guests>

</all-versions>

</esx-3-x-x>

</guestOSDescriptor>

This works beautifully on VM's that were created on an ESX 3.5 server (only ~ 2% of our farm). All VM's that were created with an earlier version had a CPU mask hard set in their VMX file making the Virtual Center mask void. If I power off and reset (either in the VMX file or in VC) the masks to default, the VC masks work and VMotion is successful. So after a PMR with IBM they agreed that the only way to really fix things is to power all VM's off, remove their masks and power them back on (GRRRRRR). Now I can do that, my script is almost done, but wait a minute...didn't I get a CPU warning message when VMotioning from ESX 3.5 to 3.5 update 1 as well? I need to test this more as all my servers now are at the latest patch level. I am worried that the next big patch will put masks in all of my VMX files again. Am I off my rocker here, or are there more of you out there trying to figure this out?

0 Kudos
2 Replies
lamw
Community Manager
Community Manager

Very interesting observations, but I think it's a good idea to open an SR with VMware, they can provide you with the correct masking and also give you information about future patches if they might overwrite what you've done so far. We've usually contacted them for any type of masking that maybe required between different CPUs.

0 Kudos
burtond
Contributor
Contributor

I wish it were that simple! Being that we have a contract with IBM all support MUST go through IBM and I have already done that. This is not the first time we have been in this perdicament. I am really just wanting to know if anyone has come up with a quick way of fixing all of these masks that are "auto" created when VMotioning from 3.02 to 3.5.

0 Kudos