topic Re: Zombie process on VMWare ESX 3.5x hosts with PMP 8.x in Server Management - Systems Insight Manager

Zombie process on VMWare ESX 3.5x hosts with PMP 8.x

Chris Hasler — Wed, 08 Oct 2008 13:58:22 GMT

Installed on all of our VMWare ESX 3.5x hosts (9 total) is the ProLiant Management Pack 8.x for VMWave 3.5.x. On all of the hosts

there are zombie processes for cimserver. The number of the zombie processes continually climb until the Pegasus (cimserver)

service is stopped and restarted.

I upgraded one server to use PMP 8.1 and the issue still occurs.

Any assistance in fixing this issue with the parent process (which appears to be the

/var/pegasus/bin/cimprovagt/SLPProviderModule process) so that the zombie processes no longer occur would be greatly appreciated.

Below is an example of the Pegasus (cimserver) processes on an ESX hosts. This host has 14 zombie processes.

26674 1 /bin/sh /usr/bin/vmware-watchdog -s cimserver -u 60 -q 5 /var/pegasus/bin/cimserver
26684 26674 /var/pegasus/bin/cimserver daemon=false
26746 26684 /var/pegasus/bin/cimprovagt 14 17 SLPProviderModule
27097 26684 /var/pegasus/bin/cimprovagt 17 20 VICimProvider
27100 26684 /var/pegasus/bin/cimprovagt 17 22 VMwareIpmiOemExtenServProvider
27605 26684 /var/pegasus/bin/cimprovagt 10 13 SensorProvider
27615 26684 /var/pegasus/bin/cimprovagt 73 76 RawIpmiProvider
27631 26684 /var/pegasus/bin/cimprovagt 76 79 VMware_LatchedHealthState
27636 26684 /var/pegasus/bin/cimprovagt 80 83 SMBIOSProvider
27641 26684 /var/pegasus/bin/cimprovagt 84 87 LogicalIpmiProvider
27645 26684 /var/pegasus/bin/cimprovagt 88 91 VMware_PortController
27647 26684 /var/pegasus/bin/cimprovagt 91 94 VMware_Controller
27649 26684 /var/pegasus/bin/cimprovagt 94 97 VMware_Battery
27651 26684 /var/pegasus/bin/cimprovagt 97 100 VMware_StorageVolume
27653 26684 /var/pegasus/bin/cimprovagt 100 103 VMware_StorageExtent
27655 26684 /var/pegasus/bin/cimprovagt 103 106 VMware_DiskDrive
27657 26684 /var/pegasus/bin/cimprovagt 106 109 VMware_SASSATAPort
27659 26684 /var/pegasus/bin/cimprovagt 109 112 VMware_StoragePool
20520 26684 [cimservera ]
20521 26684 [cimservera ]
20522 26684 [cimservera ]
20523 26684 [cimservera ]
20524 26684 [cimservera ]
20525 26684 [cimservera ]
20528 26684 [cimservera ]
20535 26684 [cimservera ]
20536 26684 [cimservera ]
20537 26684 [cimservera ]
20538 26684 [cimservera ]
20572 26684 [cimservera ]
20573 26684 [cimservera ]
20574 26684 [cimservera ]

Re: Zombie process on VMWare ESX 3.5x hosts with PMP 8.x

sandeep_raman — Thu, 09 Oct 2008 07:10:49 GMT

http://communities.vmware.com/thread/159728?tstart=0

/SRH

Re: Zombie process on VMWare ESX 3.5x hosts with PMP 8.x

Chris Hasler — Thu, 09 Oct 2008 19:21:22 GMT

Thanks Sandeep for the link to the discussion thread on the VMWare Communities site.

Good to know that others are having the same issues...bad to discover there is no solution yet.

We believe that the issue seems to be related to the use of the WBEM protocal. When the HP CIM server intiates an inventory to the ESX host using the WBEM protocal the cimserver zombie seems to get created on the ESX host.

Problem is that the WBEM protocol needs to be enabled on the configuration for the ESX host on the HP SIM server to be able to manage and inventory all the VM's on the ESX host.

Re: Zombie process on VMWare ESX 3.5x hosts with PMP 8.x

Lukas.valica — Thu, 06 Nov 2008 09:35:22 GMT

hi,
is there any solution for this issue.
i see that many customers facing the same issue with ESX update2 and hp agents 8.1
OR any workaround until the fix came out?

Re: Zombie process on VMWare ESX 3.5x hosts with PMP 8.x

Chris Hasler — Thu, 06 Nov 2008 14:29:55 GMT

We have not found a solution to this issues. As a workaround we have created a cron job on the ESX hosts which restarts the cimserver service every 2 hours.

Not very elegant or clean, but it helps...kind of like duct tape.

Re: Zombie process on VMWare ESX 3.5x hosts with PMP 8.x

Lukas.valica — Wed, 12 Nov 2008 15:36:16 GMT

for my csutomer we found a solution.

-----------------------------------------
On the SIM console, for this ESX server, under tools and links>system protocol settings â Is WBEM enabled? If yes what credentials are chosen? Is it the global default or customer specified his serverâ s credentials manually?

If WBEM is not selected, select it now and choose custom option of providing credentials and provide the root and password for root of the ESX server in the respective fields and save. (No port numbers are required).

Restart the SIM service here and the pegasus service on the ESX server.
------------------------------

At the customers SIM server, WBEM wasn't selected. after selecting, restarting the pegasus service no more cimservera zombies occure on the ESX server.

Re: Zombie process on VMWare ESX 3.5x hosts with PMP 8.x

Chris Hasler — Wed, 12 Nov 2008 15:51:04 GMT

We have WEBEM enabled as a protocol for the ESX servers in the SIM server database. We have found that when we use the credentials for an account located on the ESX server (by choosing the custom option) WEBEM is valid but the SIM server inventory job fails when quering the ESX host.

When we use the global default credentials the SIM server bypasses using the WEBEM protocol since the account is not valid on the ESX host but the inventory job works.

Currently, the inventory job working is more critical to our SIM server database manager.

Re: Zombie process on VMWare ESX 3.5x hosts with PMP 8.x

Karl Brenner — Wed, 20 May 2009 13:49:25 GMT

Hi,

did anybody find a fix for this?

Thanks,
Karl

Re: Zombie process on VMWare ESX 3.5x hosts with PMP 8.x

Wouter Wolkers — Wed, 20 May 2009 14:01:54 GMT

This issue has been fixed

see VMware ESX 3.5, Patch ESX350-200901407-BG: Updates Pegasus
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006657

Invalid CIM authentication can result in a large number of defunct processes from cimservera

So you can also fix this by correcting your CIM authentication (you're trying to log in with an invalid username/password combi) which will also result in the host being correctly identified in HP SIM.