I'm throwing this one up here as well, in addition to having filed my first ever VMware support request.
One of my ESX hosts started to act erractic and trying to migrate guests off the machine gave no results whatsoever. It basically started by me wanting to shut down a few machines and remove some unneeded memory from them.
Basically the bug/error boils down to this:
\- Given a machine that has X Mb memory configured and a resource guarantee for Y Mb memory.
\- Shut down the machine and remove some memory so that Y now exceeds X.
When now clicking OK and VC sends of the command to reconfigure the guest it will hang at "100% complete" and never finish. /var/log/vpx/vpxa.log will fill up with conitnous running text like this:
\[2007-03-11 04:09:18.102 'App' 8940464 warning] ============BEGIN FAILED METHOD CALL DUMP============
\[2007-03-11 04:09:18.102 'App' 8940464 warning] Invoking \[updateChildResourceConfiguration] on \[vim.ResourcePool:pool0]
\[2007-03-11 04:09:18.102 'App' 8940464 warning] Arg spec:
(vim.ResourceConfigSpec) [
...\[more data]
]
\[2007-03-11 04:09:18.102 'App' 8940464 warning] Fault Msg: "A specified parameter was not correct.
spec.memoryAllocation.reservation"
\[2007-03-11 04:09:18.102 'App' 8940464 warning] ============END FAILED METHOD CALL DUMP============
And ther eit ends. The host cannot process any other commands now that this is spinning and I'm not sure what to kill to make the host forget to process this obviously bogus command (in the \[more data] section above you will clearly see what it is trying to do, and that the resource allocation excees the current memory its attempting to configure for the guest).
Has anyone seen this and know what t kill/whack/thump to get the host to forget this configuration attempt?
I have stopped vmware-mgmt and vpx and removed/reinitalised vpxa without luck.
-A
PS: The net effect of the above is that a VM admin can unwittingly create a VC farm wide DoS, as nothing gets processed any longer
Message was edited by:
ahoogerhuis
I've had a very helpfull support tech from VMWare call me up and walk through this. They couldn't reproduce it immeadetly in their lab, but I can repeatedly show them the crash.
Could anyone out there that has a lab environment please try the following:
1. Create a VM ith 512 Mb RAM.
2. Close VC and log back in again.
3. Open settings for the VM and go to the resources tab, guarantee the machine 384Mb RAM.
4. Close the settings window and wait for the client to finish reconfiguring the machine.
5. Open the settings for the VM and reduce the available memory from 512 mb to 256mb.
6. Please let us know what happens?
-A