CPU Spike with DRS and VMotion
January 20th, 2008 by slowe
An issue has been discovered that can cause a CPU spike when VMotion is used in a DRS-enabled cluster with ESX Server 3.5 and VirtualCenter 2.5. It is my understanding that this can occur with both DRS-initiated VMotion operations as well as manually-initiated VMotion operations.
Fortunately, there’s a workaround for this issue which involves editing the vpxd.cfg on the VirtualCenter server. Full details on the change that needs to be made, as well as on the log entries that you should see on ESX Server afterward, are found in this article.
UPDATE: It appears that VMwarewolf has had to pull the original article that described this problem and the workaround. Fortunately, Google has a long memory, and here’s the workaround for this problem.
Immediately after the “<vpxd>” line in vpxd.cfg, add the following lines:
<cluster>
<VMOverheadGrowthLimit>5</VMOverheadGrowthLimit>
</cluster>
I’m guessing that this information may not be information that VMware wants easily disseminated to the world, or that the workaround has not been fully and completely tested. So, use this information at your own risk.
In the meantime, this Google search will return the now-unavailable page; use the Cached link to see the workaround and the details from the log file that will help troubleshoot the problem.
UPDATE 2: VMware has now published this KB article about the issue, along with the workaround for the problem.
Site Tags: ESX, Virtualization, VMotion, VMware
Related Site Tags: Security, Networking, VLAN, VMwareHA, Cisco, HyperV, IOS, Microsoft
This entry was posted on Sunday, January 20th, 2008 at 5:44 pm and is filed under Virtualization. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
January 22nd, 2008 at 4:54 pm
Hey, Scott. Thanks for this post; wouldn’t you know it we’ve been grappling with this exact same issue for the past few days, willy-nilly restarting Windows Guests because, you know, it’s got to be Windows!
Any ideas on how this could affect a VCenter that’s managing 3.5 and 3.0.2 clusters? Also, any “official” word on this from VMWare? I couldn’t find a KB article or anything.
It worked like a charm, btw, although we had to create a net-new HA/DRS cluster for the vpxd.cfg changes to push down to the ESX hosts.
Thanks, again!
March 27th, 2008 at 9:21 am
This is a great post, We have been having the problem for about a week after a massive upgrade from 3.02 to 3.5, along with lots of major outages in our environment.
Thanks for the post should help with our outages.