Yellow Bricks

by Duncan Epping

2.0.x

VirtualCenter log files in your temp directory

· ·

By default your VirtualCenter logfiles are stored in a temp folder(as of 2.5 they are stored in: C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\Logs). VMware Wolf wrote a nice article about all the locations these log files are stuffed. For some reason I don’t get a pleasant feeling when I store my VirtualCenter (VPXD) log files in a temporary windows directory or the profile directory for that matter(thanks for the comment!!). If there’s one thing admin’s clean up first when they tend to run out of diskspace it’s their temp directory… it’s called temp for a good reason!

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>

VirtualCenter 2.0.2 Update 5

· ·

Besides ESX 3.0.3 also a new VC version has been releaded! I did not notice this one yet.

Security Issues

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.

VM’s automatically renamed

· ·

Yesterday evening I witnessed a weird phenomenon. We had to bring down a complete environment to move a 19″ rack to a different location. We switched the SAN on, waited a couple of minutes and switched the ESX hosts on. When the ESX hosts finished booting we booted the VirtualCenter. Everything looked normal in the VI Client. I had all connections to the SAN and all ESX Hosts were up and running. So I decided to power up the first VM, it was a VM named LNX01. Within a second the VM got renamed to LNX05(1). I though I was going nuts. I checked the settings of the renamed VM and indeed it was pointing out to the LNX05 diskfiles/vmx.

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.

Swapping and/or ballooning

· ·

Today a customer called about a problem with the Exchange VM. For some reason the ESX Host where this VM resided was always swapping/ballooning. They checked and double checked the settings but could not find the problem. After a quick scan I noticed that there were limits set on memory for each VM. This particular VM had 1536MB of memory and a limit of 1024MB. After changing the setting back to it’s default setting, “unlimited”, the message was gone. I haven’t got a clue why this setup this way, limitting the memory to the exact amount assigned to a VM… weird, but problem solved.

VirtualCenter 2.0.2 Update 3

· ·

VMware just announced VirtualCenter 2.0.2 update 3:

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.