So in order to prevent this you could change the location of the VPXD log files very easily. Edit “vpxd.cfg”. It’s located here: %AllUsersProfile%\Application Data\VMware\VMware VirtualCenter\.

Add the following lines in the “<config>” section and change the path accordingly:

<log>
<directory>c:\VC_Logs</directory>
</log>

Security Issues

• Updates the Apache Tomcat Server
  This release of VirtualCenter Server updates the Tomcat server package from 5.5.25 to 5.5.26, to address multiple security issues that existed in the earlier releases of Tomcat server.
  The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2007-5333, CVE-2007-5342, CVE-2007-5461, and CVE-2007-6286 to these issues.
  For more information, refer to the Apache Tomcat 5.x Vulnerabilities page.
• Updates the JRE Package
  This release of VirtualCenter Server updates the JRE package from 1.5.0_12 to 1.5.0_15, to address multiple security issues that existed in the earlier releases of JRE.
  For more information about security issues fixed in JRE package version 1.5.0_15 and in earlier versions, refer http://java.sun.com/j2se/1.5.0/ReleaseNotes.html.
  The following advisories by Secunia list the CVE identifiers related to the fixed security issues in JRE 1.5.0_13, JRE 1.5.0_14, and JRE 1.5.0_15:
  • http://secunia.com/advisories/ 27009
  • http://secunia.com/advisories/ 27320
  • http://secunia.com/advisories/ 28795
  • http://secunia.com/advisories/ 29239

Note: These vulnerabilities can be exploited remotely only if the attacker has access to the service console network. Security best practices provided by VMware recommend that the service console be isolated from the virtual machine network. For more information on VMware security best practices, refer www.vmware.com/resources/techresources/726.

• VirtualCenter Server Users Without the Modify Permission Privilege Can No Longer View User Name Details of Other System Users
  Starting with this VirtualCenter Server release, only users with the Modify Permission privilege can view details of other system users. When users with read-only or similar roles attempt to assign permissions to other system users, user name details of other system users are not displayed, instead, a message similar to the following appears:
  Permissions to perform this operation was denied.
  The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2008-3514 to this issue.

Virtual Machine Management Issues

• e1000 Is the Default Network Adapter Driver for Windows Vista Ultimate 32-Bit Guest Operating Systems
  Starting with this release, the Windows Vista Ultimate 32-bit guest operating systems correctly detects the e1000 driver as the default network adapter driver, instead of the vlance driver.
• Multiple Virtual Machines Can Be Scheduled to Power On Simultaneously
  This release fixes an issue where multiple tasks that are scheduled to power on virtual machines at the same time might result in one of the following:
  • The scheduled tasks might fail, with log entries similar to the following in the vpxd.log file:
    [2008-02-25 03:35:04.185 'App' 6708 verbose] [VpxdMoEventManager] Event[12597]: Task <virtualmachine _name>_PowerON on <virtualmachine _name> in Data Center failed: The request refers to an unexpected or unknown type.
  • The VirtualCenter Server might stop responding, with log entries similar to the following in the vpxd.log file:
    Exception: Not reached!
    [2008-02-26 03:35:03.260 'App' 4848 error] Backtrace:
    backtrace[00] eip 0x016dc006 Ordinal788
    backtrace[01] eip 0x0167248a Ordinal400….
• VirtualCenter Server Accepts Suffix Less Domain Entries When Updating the DNS Configuration of an ESX Server Host
  This release fixes an issue where, when updating the DNS configuration of an ESX Server host, the VirtualCenter Server fails to accept valid host domain names that do not have suffixes, and displays an error message similar to the following:
  The Domain name is not in the correct format
• Viewing the Event Tab Page No Longer Causes the Japanese Version of VirtualCenter Server to Stop Responding
  This release fixes an issue where, if an event that writes multi-byte characters to the ARG_DATA column of VPX_EVENT_ARG database table, such as accessing the console of a virtual machine, is followed by viewing the Event tab page, the Japanese version of the VirtualCenter Server might stop responding. Entries similar to the following are logged in the vpxd.log file:
  [2008-03-05 17:12:18.161 'App' 5012 verbose] [VdbStatement]Executing SQL: SELECT EVENT_ID, ARG_ID, ARG_TYPE, ARG_DATA, OBJ_TYPE, OBJ_NAME, VM_ID, HOST_ID, COMPUTERESOURCE_ID, DATACENTER_ID, RESOURCEPOOL_ID, FOLDER_ID, ALARM_ID, SCHEDULEDTASK_ID FROM VPX_EVENT_ARG WHERE (EVENT_ID IN (?,?,?,?..........)
  [2008-03-05 17:12:18.302 'App' 5012 error] An unrecoverable problem has occurred, stopping the VMware VirtualCenter service. Check database connectivity before restarting. Error: Error[VdbODBCError] (-1) ODBC error: () -
  [2008-03-05 17:12:18.302 'App' 5012 verbose] Backtrace:

Installation Issues

• VirtualCenter Server No Longer Fails to Start When Japanese Version of VirtualCenter 2.0.2 Update 2 is Upgraded
  The VirtualCenter Server might fail to start when the Japanese version of VirtualCenter 2.0.2 Update 2 is upgraded to VirtualCenter 2.0.2 Update 3, or VirtualCenter 2.0.2 Update 4, with entries similar to the following in the vpxd.log log file:
  [2008-05-07 15:56:59.953 'App' 5840 error] [VpxdVdb] Database version value
  'VirtualCenter Database 2.0.2u1' is incompatible with this release of VirtualCenter.
  [2008-05-07 15:56:59.953 'App' 5840 error] Failed to initialize VMware
  VirtualCenter. Shutting down...
  This release fixes the issue. The VirtualCenter Server is capable of starting, when the Japanese version of VirtualCenter 2.0.2 Update 2 is upgraded to VirtualCenter 2.0.2 Update 5.

Maybe it was just me, or this one VM so I decided to give another one a try, I powered up LNX02. Same happening here, within a second the VM was renamed to PS01(1) and booted fine. The settings were pointing out to PS01. I checked a couple of VM’s but could not find anything weird. I restarted the VirtualCenter service just to be sure. I started the VM LNX03 and again it was renamed… Than I decided to restart the “mgmt-vmware” services on all of the ESX hosts and the problem never returned again. It seems like VirtualCenter had a different view than the ESX hosts had. But I can’t think of a logical reason what could cause this. I searched the knowledge base but could not find any related problems, well besides an old article based on VirtualCenter 1.2.

Resolved Issues include:
Virtual Machine Management Issues
PR:219126 – Virtual Machine Alarms Not Triggered This release fixes an issue where VirtualCenter alarms are not triggered when the alarm conditions are met.

PR:225357 – Host and Virtual Machine Alarms Stop Updating Over Time This release fixes an issue where some alarms that are configured for a virtual machine can fail to update. This issue is usually encountered after the virtual machine has changed power state.

PR:163019 – Virtual Machines Do Not Show Correct Status This release fixes an issue where the status indicators of some virtual machines do not accurately reflect the virtual machine’s status. This issue usually occurs after a restart of the VirtualCenter Server.

Licensing Issues
R:229629 – VirtualCenter Does Not Correctly Display New License Format This release fixes an issue where earlier versions of VirtualCenter are not able display licenses from license files issued since the release of VirtualCenter 2.5. On versions of VirtualCenter before 2.0.2 Update 3, the license files appear to install normally but log warnings such as “Chunk ‘desc=ESX Server Enterprise’ was not well formed, skipping” in the log files when license files of the new format are displayed in VirtualCenter.

The release notes aren’t online yet, so we will have to wait for a more detailed view on what has changed in this release.

I checked the server but the patch was installed, so I rebooted the machine to be sure the installation of the update was completed but no luck. I reinstalled the patched and tried to install VC but again no luck. Next thing to do was check the VMTN forum and luckily someone already encountered the same weird problem and they received the following fix from VMware support:

************ Problem ***********
Update from VC 2.0.0 to VC 2.0.1 not possible.
Error message that “Update Rollup 1” is not installed.

************ Root Cause (if known) ***********
Wrong registry check of installer.

************ Solution ***********
Replace NTDLL.DLL by KERNEL32.DLL in the registry:

HKLM\SOFTWARE\Microsoft\Updates\Windows 2000\SP5\Update Rollup 1\Filelist\0]
“FileName”=”NTDLL.DLL”
“Version”=”5.0.2195.7006″
“BuildDate”=”Thu Jan 13 10:09:36 2005″
“BuildCheckSum”=”77ecb”
“Location”=”C:
WINNT
system32″

1. Shutdown the VM
2. Rename the VM in VirtualCenter
3. Migrate the VM and move it to another Datastore
4. done!

And from the service console:

1. vmware-cmd -s unregister /vmfs/volumes/datastore/vm/vmold.vmx
2. mv /vmfs/volumes/datastore/vm-old /vmfs/volumes/datastore/vm-new
3. cd /vmfs/volumes/datastore/vm-new
4. vmkfstools -E vm-old.vmdk vm-new.vmdk
5. find . -name ‘*.vmx*’ -print -exec sed -e ‘s/vm-old/vm-new/g’ {} \;
6. mv vm-old.vmx vm-new.vmx
   for every file that hasn’t been renamed (.vmsd etc.)
7. vmware-cmd -s register /vmfs/volumes/datastore/vm-new/vm-new.vmx
8. done!