"Unable to apply DRS resource settings on host 'zzz' in yyy' (Reason: The name 'xxx' already exists.).This can significantly reduce the effectiveness of DRS"

[dagn46]

Hi all,

I've got this warning in my VC 2.5:

"Unable to apply DRS resource settings on host 'zzz' in yyy' (Reason: The name 'xxx' already exists.).This can significantly reduce the effectiveness of DRS"

I'm trying to delete the resource pool xxx directly on the host, but can't: "the request refers to an object that no longer exists or has never existed"

I've tried this too:

/etc/init.d/mgmt-vmware restart

/etc/init.d/vmware-vpxa restart

I don't want to remove my host from the VC :smileysilly:

Info: ESX 3.5 U3 / VC 2.5 U4

Thanks for your help

Regards

[Jabadakkas]

Have you tried restarting the Virtual Center service?

[dagn46]

at least 100 times :smileysilly:

[Jabadakkas]

I opened a case with VMware, so I'll keep you posted when I have a fix.

[dagn46]

thanks

[admin]

To delete the resource pool manually, you will have to remove the host from inventory or uninstall vpxa from the host. Once this is done, remove the resource pool and add the host again to VC.

Hope this helps

-Sandeep

[dagn46]

i know that ... but it's a "bug" ... there's no other way to solve that ??

thanks anyway

[Jabadakkas]

Hi Sandeep,

In our case we did not delete any pools at all, the error appeared out of the blue. So deleting pools just to get rid of this error is not an acceptable solution for me. Unless VMware support can convince me otherwise.

[admin]

I don't think there is another way. Because VMware does not recomment connecting directly to the ESX host when they are already being manged by a VC, especially in a cluster. So I dont know if you can call this a bug

-Sandeep

[Jabadakkas]

Bad news, the problem resolved itself after a reboot of our ESX hosts. So root cause analysis is not an option anymore.

The pegasus service on our ESX hosts caused excessive COS memory usage, resulting in a PSOD. If you are using a recent version of ESX3 you should take a look at the following KB article: http://kb.vmware.com/kb/1009525

[mrjlturner]

Good thread! This link that was provided at the bottom of the thread fixes the issue:

Pegasus (cimserver) memory leaks reported in ESX 3.5 Update 2 and later

I putty'd into the affected server, and ran this command: /etc/init.d/pegasus restart

This fixed the issue instantly

Thanks!

jason

[Teiva]

This might be old news, if so, ignore it;

This is the way i resolved these DRS issues when they occured

1) I enter the affected host in maintenance mode to evacuate all active VMs

2) I perform a "/sbin/service mgmt-vmware stop"

3) Then I clear the esx.conf configuration from resource pool information using

3.0) make a note of the number of entris (if you want)

grep -i resourceGroups /etc/vmware/esx.conf | wc
     8770   26310  668981

3.1) Backup the esx.conf

cp /etc/vmware/esx.conf /root/backups/esx.conf

=> Validate that the backup is available

3.2) Remove all resourceGroups entries from /etc/vmware/esx.conf using

grep -v resourceGroups /etc/vmware/esx.conf > /tmp/esx.conf.clean

3.3) Re-import the configuration back in using

cat /tmp/esx.conf.clean > /etc/vmware/esx.conf

4) Restart management service

/sbin/service mgmt-vmware start

5) monitor the hostd.log file for the following that ends with "BEGIN SERVICES" which signifies that the agent has started correctly which is GOOD!, then watch the logs

Example:

"[2011-04-02 05:24:29.114 'App' 3076449184 info] BEGIN SERVICES"

To monitor the file, use

tail -f /var/log/vmware/hostd.log

6) Remove host from maintenance mode

7) Login directly to the ESX host using the VI Client and when vCenter installs the HA agent (towards the last 90%) you should see the resource pools being created

you can also re-run the following command an see the different line count of 0

grep -i resourceGroups /etc/vmware/esx.conf | wc

   0    0    0

Note: You should not see the wc cound exceeding 0 until you place a VM onto the host (off or on).

I hope this helps.

Teiva