Setup cannot create vCenter Server Directory Services instance. Error 28038

This error is caused by the fact that the “Network Service” does not have enough permissions on the root of the drive you’re installing vCenter on. The solution is pretty straight forward and has been described in the KB article.

1. Right-click the root drive and click Properties.
2. Click the Security tab.
3. Under Group and user names, click Add.
4. Enter Network Service and click OK.
5. Check Allow for the Read permission for the Network Service account in the Permissions for Administrators pane.
6. Click Apply and OK.

If this does not resolve the issue look into the following KB articles: 1015887 , 1013822.

KB Article 1016070

Issue
Upgrading ESX 4.0 to 4.0 U1 fails or times out and rebooting the host results in a purple diagnostic screen

Who is affected
Customers using VMware vSphere 4 upgrading to Update 1 with 3rd party management agents running.

To identify whether you have a 3rd party management agent installed:

1. Log into the ESX host as root.
2. Run the esxupdate query command.
3. Anything listed under New packages: may be a 3rd party management agent in the service console.

Note: Consult your hardware vendor documentation for specific package names that are installed in the service console.

Solution

To avoid this issue, prior to the update, disable all 3rd party management agents running on the ESX 4.0.0 server before applying the update.

Note: The 3rd party management agents can be enabled after the upgrade is completed.

If you have already updated the ESX host, do not reboot the ESX host. Open a support request with VMware support. For more information, see How to Submit a Support Request.
WARNING: Rebooting the host means the host has to be reinstalled because it is not recoverable after a reboot.

WARNING: If you have virtual machines running on local storage, they may not be retained if you reinstall ESX 4.0 as a result of this issue. Contact VMware Support for assistance in recovering those virtual machines.

http://kb.vmware.com/kb/4223326

To resolve this issue:

1. Disable VMware High Availability (HA). Otherwise, the virtual machines might be forcibly powered down by step 2.
2. At the service console, issue the command:

   service mgmt-vmware restart

3. At the service console, runthe command:

   service vmware-vpxa restart

4. Reconnect the virtual machines to VirtualCenter.Attempt to re-enable VMware High Availability (VMware HA) within VirtualCenter. If this doesn’t work, this means that vpxa did not install properly.
5. At the service console, run the command:

   rpm -qa | grep vpxa

6. At the service console, run the “rpm -e” command on the rpm file that displayed in the previous command.

   rpm -e <rpm from step 6>

7. This uninstalls the agent from the ESX host. Reconnecting the host to VirtualCenter re-installs the agent.
8. Reconnect the virtual machines in the usual manner within VirtualCenter.
9. Re-enable VMware HA.

• Adding a static route to ESX host for extra service console
• Identifying Symmetrix devices using the esxcfg-mpath and symdev commands

The first one will come in handywhen you added a secondary service console and the second one will come in handy when you need to identify LUNs…

1. ESX350-200903412-BG – PATCH – KB 1009232 – General
   Updates Kernel Source and VMNIX
2. ESX350-200903411-BG – PATCH – KB 1009231 – Critical
   Updates the bnx2x Driver for Broadcom

Download them now!

Diskeeper is a 3rd party defragmentation product that has the ability to defragment unmounted NTFS volumes that are presented to the VMware Consolidated Backup proxy. This means that it can defragment RDM LUNs. Unfortunately, this creates the possibility of inconsistencies in the file system if there is a virtual machine running on that RDM.

The Automatic Defragment option causes the defragmentation to take place.

Consult your Diskeeper documentation to obtain instructions for disabling this feature in the version of the product that is installed on the VCB Proxy server.

Be aware to not use Diskeeper on your VCB proxy!

• ESX disconnects randomly from VirtualCenter
• ESX disconnects when performing VI Client tasks from VirtualCenter.
• Tasks randomly timeout after a long idle time
• “An error occurred communicating to the remote host” pops up.

The article refers to an issue with vCenter Update 3 in combination with firewalls using state-ful inspection. The problem occurs because of SOAP timeouts, and this behavior did not exist in VC 2.0.x or 2.5 GA, as they used a different mechanism to communicate with ESX. The official KB article hasn’t been released yet but a temporary workaround has been published by Richard. If you run into any of the before mentioned issues head over to Richard’s website and try out the workaround until the fix or official KB article is released.

HP’s new Virtual Connect Flex-10 Ethernet module is the industry’s first interconnect that flexibly allocates the bandwidth of a 10 Gb Ethernet network port across four NIC connections. This eliminates the need for additional costly NICs, switches and cables while concurrently increasing bandwidth flexibility.

After checking the compatibility guide the answer was “Yes”. So what’s the point of mentioning it here? Well, although it was fully supported there is a mention in the KB about possible problems with HA and VMotion:

• VI Client does not show NIC connnection is down when the uplink to external switch is down
• VMware HA is not supported with ESXi 3.5 Update 3 (embedded and installable) hosts with uplinks connected to Flex-10 NICs.
• VMotion migration of virtual machine May time out with the default migration timeout value of 20
• ESX Server May fail to respond under the following configuration

I guess the tip of today: Always check the compatibility guide, but also check the KB cause problems like this might influence your implementation time, plan and even your design!

There are many ways to look at ESX host performance. This article focuses on quick assessment of the 4 main resources:

• Disk Space
• CPU
• Memory
• Network

The article refers to different KB articles for pinpointing and solving performance related problems. I suggest you add this article to your bookmarks cause it probably be updated on a regular base!

1. Log in as root to your ESX host with SSH.
2. Open the /etc/vmware/hostd/vmAutoStart.xml file in text editor.
3. Search for a line that reads:

   <enabled>true</enabled>

4. If you find the line, the functionality is enabled. If you do not find the line, the functionality is disabled.
5. If you want to disable autostart for all virtual machines on the host, remove the line.
6. If you want to enable the functionality, add the line immediately after the line ending with:

<dynamicProperty>

7. Save your changes and exit.
8. Restart the management agents on the ESX host:
   service mgmt-vmware restart