VMware VirtualCenter 1.0 Support Documentation

Features | Documentation | Knowledge Base | Discussion Forums


VMware VirtualCenter 1.0 Release Notes

Check back frequently for additions and updates to these release notes.

Latest Version:   1.0.1   | Build:   7770   | Last Updated:   03/31/2004

What's in This Release Note

Version Compatibility for This Release

This Release version requires and/or functions with the listed version of the following:

ESX Server VirtualCenter
version 2.0.1 version 1.0, 1.0.1
version 2.1 version 1.0.1

Revision History of This Release Note

Revision Date Changes
1.0 December 5, 2003 Initial release
1.0.1 March 31, 2004 Support for ESX Server 2.1

What's New in Version 1.0.1?

Changes in VirtualCenter 1.0.1 from version 1.0 include:

  • Management of ESX Server 2.1.
    VirtualCenter 1.0.1 includes agents for management of both ESX Server 2.1 and ESX Server 2.0.1. Administrators needing management support for ESX Server 2.1 will need to upgrade to VirtualCenter 1.0.1.

    Note: ESX2.1 is only supported with VirtualCenter 1.0.1. If you are using VirtualCenter to manage your ESX servers, you MUST upgrade your VirtualCenter installation to VC 1.0.1 BEFORE you upgrade your ESX servers to ESX 2.1.

    Note: VirtualCenter 1.0 or VirtualCenter 1.0.1, beta or RC versions, are not supported with ESX Server 2.1. You must upgrade to the publicly released version of VirtualCenter 1.0.1 for managing ESX Server 2.1.

  • Assorted bug fixes.
    Refer to Resolved Issues in Release 1.0.1 for a description of important items.

Upgrading from Version 1.0 to Version 1.0.1

Updating your VirtualCenter from version 1.0 to version 1.0.1 requires a simple reinstall using the VirtualCenter VMware-VMcenter.exe tool. You do NOT need to uninstall version 1.0, then install 1.0.1.

NOTE:The licensing information must also be updated.

To update your VirtualCenter, to version 1.0.1, follow the instructions below. For more detailed information refer to the chapter, Installing VMware VirtualCenter, in the VirtualCenter User's Manual.

  1. Create a backup of your virtual machines prior to performing a VirtualCenter update.

  2. Download the VirtualCenter installer file from the VMware secure Website to a local drive.
  3. From the appropriate Windows machine, run the installer.
    Double-click the executable.

  4. Proceed with the installation.
    1. Click Yes on the proceed with upgrade prompt.
    2. Click Yes on the proceed with installation wizard prompt.

  5. Select the type of database you are using. The options are:
    • Use Access database VirtualCenter automatically creates a database. To choose this option, click the Use Access database button, then click Next.
    • Use a custom SQL database connection VirtualCenter prompts for DNS information then configures the database.
    • Use a custom Oracle database connection VirtualCenter prompts for DNS information, username and password, then configures the database.

  6. Select to retain your existing VirtualCenter database.
    Click No at the prompt to overwrite your existing database.

  7. Complete the upgrade.
    1. Click Install on the Ready to Install wizard screen.
    2. Click Finish on the Installation Complete wizard screen.
    3. Click Yes on the Restart your Computer prompt.

    The upgraded VirtualCenter component(s) are installed on your Windows machine.

  8. Repeat this procedure on each Windows machine you wish to upgrade.

    Note: If you upgrade the version of an ESX Server, when you start the VirtualCenter client, you may need to reconnect the upgraded ESX Server. This ensures that each ESX Server is running the current version of the VirtualCenter agent. For more information about ESX Server, see http://www.vmware.com/support/esx21.

  9. Refer to the appropriate sections in the VirtualCenter User's Manual, to set up for specific functionality.

Resolved Issues for Release 1.0.1

The following is a partial list of issues that are resolved in release versionn 1.0.1.

Clustering not allowed for various clustering products
VirtualCenter Management Server does not allow clustering using VCS, MSCS, Legato AAM, or any other clustering product.

Issue resolved in VirtualCenter version 1.0.1. Upgrade from VirtualCenter version 1.0 to version 1.0.1.

VirtualCenter now allows the use of multiple networks on the VirtualCenter Management Server, and in particular, the ability to have a network dedicated for making the VirtualCenter Management Server highly available using third party clustering software.

Manipulating large templates times out
When cloning or loading large templates, VirtualCenter times out.

Issue resolved in VirtualCenter version 1.0.1. Upgrade from VirtualCenter version 1.0 to version 1.0.1.

VMotion creates false CPU mismatch error
When attempting a VMotion, a warning displays indicating there has been a CPU mismatch, when there is no such mismatch.

Issue resolved in VirtualCenter version 1.0.1. Upgrade from VirtualCenter version 1.0 to version 1.0.1.

Permissions not allowed to nested domain administrators
VirtualCenter does not grant access privileges to any Domain Administrator users or groups located in nested Domain Administrator tiers.

Issue resolved in VirtualCenter version 1.0.1. Upgrade from VirtualCenter version 1.0 to version 1.0.1.

Permissions broken on VirtualCenter server machine
When the VirtualCenter management server machine name is changed, Windows might not startup the VirtualCenter management server correctly. This is due to a possible mismatch in user names and passwords.

Issue resolved in VirtualCenter version 1.0.1. Upgrade from VirtualCenter version 1.0 to version 1.0.1.

If you are remaining on VirtualCenter version 1.0, restart the VirtualCenter management server through the Windows Services. Refer to the chapter, Getting Started, in the VirtualCenter User's Manual for additional information on restarting the VirtualCenter management server.

IBM NUMA machines experiencing migration problem
Migration with VMotion might fail when the source or destination host is an IBM numa machine (x440, x445)

The failure might appear as one of the following events:

  • Migration failed due to timeout
  • Monitor panics (uncommon)
  • Stalled migrations (uncommon)

Issue resolved in ESX Server version 2.1. Migrate to ESX Sever 2.1.

If you do not migrate to ESX Server 2.1 and depending upon the type of migration error you receive, perform the corresponding action:

  • If the migration failed due to timeout, try migrating again.

  • If the monitor panics with either of the following messages:
    • Unable to read swapped out page PPN(0x23a3) from swap slot(0xf0023a3) for virtual machine(27372)
    • Failed to transfer all changed pages from source

    No action required.

  • If the migration stalled, suspend the virtual machine using either the ESX Server Console or VMware Management Interface. Click through any errors that appear.
    The virtual machine will be in a powered on state and can be migrated again.

SCSI driver conflict when booting a Windows virtual machine
In VirtualCenter when there is a lot of background Vmotion activity, an error might occur when booting a Windows virtual machine.

VirtualCenter utilizes a shared file system called VMFS implemented in the ESX Server product to store the disk files for virtual machines. This file system which can be accessed by multiple hosts is an important enabler for the Vmotion technology. VMFS needs to lock the filesystem for short durations to synchronize metadata changes from multiple hosts. This locking is done through the use of SCSI reservations. When a LUN is reserved I/O to the LUN from a different host will get a SCSI reservation conflict error. Most SCSI drivers are able to just retry in such cases and the condition is invisible to upper level software. However, the windows bootloader is not able to deal with this condition and returns an error believing that its read access to the file that it was loading failed.

Issue resolved in ESX Server version 2.1. Migrate to ESX Server 2.1.

If you do not migrate to ESX Server 2.1, reboot the virtual machine.

Known Issues for This Release

Installation Items

VirtualCenter installer produces registry errors during installation
During installation of the VirtualCenter Server component, a Registry Editor error might appear: Cannot import xxx.reg: Error accessing the registry.

This occurs occasionally if incorrect permissions are set for the registry key HKEY_LOCAL_MACHINE > Software > VMware, Inc. > VMware VirtualCenter. The system must have write permission for this key to proceed with VirtualCenter installation.

Dismiss the dialog and cancel the installation.

Correct the permission:

  1. Run regedt32 (for Windows 2000 systems) or regedit (for Windows 2003 or Windows XP systems).
  2. Open the key, HKEY_LOCAL_MACHINE > Software > VMware, Inc. > VMware VirtualCenter.
  3. Select the security options.
  4. Assign Full Control permission to Administrators and the SYSTEM.
  5. Save the changes to the key.
    A subsequent installation should not show these error messages.

Refer to the Knowledge Base article 1190 for additional information:

VMotion Items

Migration with VMotion does not work if an external Console is open
When a Console that connects directly to the ESX Server of a migrating virtual machine is open, the migration does not complete until that Console is closed. This does not occur when the VirtualCenter Console is open.

Use the VirtualCenter Console to view the virtual machine and close the external Console.

Duplicate IP addresses when configuring VMotion creates an error
A host should not be configured for VMotion if another host with the same IP address is already configured for VMotion. If this is done, VMotion behavior becomes unpredictable and errors can be generated.

Duplicate IP addresses are not supported.

Migrating virtual machines using multi-select is not successful for all virtual machines selected
Pre-migration checks should be performed on any virtual machine as part of the pre-process for a migration. This is automatically performed when a virtual machine is specified for migration. However, when multiple virtual machines are selected, the pre-migration check is not always performed on all selected virtual machines. Consequently, some of the virtual machines might fail to migrate. In addition, a pre-migration message indicating why the migration would fail might not have been issued.

Try to migrate the failed virtual machines individually and note the messages that display. The messages indicate why a virtual machine cannot be currently be migrated.

Migration looks complete to ESX Server, but fails at power on
ESX Server believes a virtual machine has been moved, but the virtual machine fails to power on at the new host.

Refer to the VirtualCenter status logs rather than the ESX Server logs for information regarding the failed power on.

Clone and migrate limitation for virtual machines with more than eight virtual disks
Some operations on virtual machines with more than eight virtual disks are not supported. The unsupported operations are those that need to copy the disk, this includes cloning, migration to a different datastore, and creating templates.

If these operations are used on a virtual machine with more than eight disks, all the disks are also copied, but their name in the configuration file will be incorrect.

Open the virtual machine configuration file and correct the disk names.

Migrating with VMotion Fails with Timeout Error

If migrating running virtual machines with memory greater than 1 GB, you need to disable memory checking.

To disable memory checking, do one of the following:

  • Log in to ESX Server as root and enter the command:
    echo 1 > /proc/vmware/config/Migrate/MemChksum
    Note: You need to run this command after each reboot.

  • Log in to ESX Server as root and edit /etc/vmware/config and add the line:
    migration.dataTimeout = 120
    Note: By adding this variable, networking failures may take longer to detect.

Migrating with VMotion Fails with Memory Error
When migrating virtual machines, you see the error:
Unable to allocate enough memory to power on this virtual machine.

VirtualCenter displays this error message when you try to migrate vitual machines with more than 512 MB of RAM between an ESX Server 2.0.1 host and an ESX Server 2.1 Beta 2 host.

Do not migrate virtual machines between ESX Server 2.0.1 and ESX Server 2.1 Beta 2 with this configuration.

VMotion a Running Virtual Machine from ESX Server 2.1 to 2.0.1
VMotioning a running virtual machine between ESX Server 2.0.1 and 2.1 is supported in both directions. However, VMotion from a ESX Server 2.1 to 2.0.1 is not always recommended. For example if a running Virtual Machine is Vmotioned from ESX Server 2.1 to 2.0.1, it may not have the idler service installed. This may result in adverse performance of the virtual machine on the ESX Server 2.0.1 machine.

ESX Server 2.1 does not require the idler service to be installed. The idler service is automatically de-installed when the ESX Server 2.1 tools are installed in a virtual machine.

No action required.

Management Items

The current state of a virtual machine is not displayed correctly in an external Console
An external Console might not display the current state of a virtual machine when you are running an external Console and the VirtualCenter Console at the same time.

Close one of the Consoles and refresh the remaining Console.

A virtual machine is powered on but the VirtualCenter Console tab displays No Signal
A No Signal message might display in the VirtualCenter Console when a virtual machine is powered on if the VirtualCenter Console is slow to refresh.

Refresh with the F5 key or click on another virtual machine tab then return to the Console tab for the desired virtual machine.

Virtual machine remains registered to VirtualCenter when removed through VMware Management Interface
When a virtual machine is removed through the VMware Management Interface, a refresh of the host in VirtualCenter reregisters the virtual machine to both VirtualCenter and the management interface.

To remove a virtual machine, while keeping the virtual machine files on the host, remove the virtual machine through VirtualCenter and not through the external VMware Management Interface.

Polling intervals show gaps when local time changes occur
When the system clock changes, for example, during daylight savings time, the polling logs appear to have gaps in the polling intervals.

This is a temporal adjustment and does not impact the actual collecting of polling data.

Orphan virtual machines
In VirtualCenter under very rare circumstances, you may find that you have a virtual machine that has an orphan designation.

An orphan virtual machine is one that VirtualCenter discovered previously, but currently is not able to identify the associated host.

An orphan might be created:

  • If you delete the virtual machine's configuration file through ESX Server Console.
  • If VMotion is under extreme stress.
    This occurred once. The virtual machine continued to run on the destination, however VirtualCenter saw it as an orphan because the configuration file had been removed on the source and was in transition to the destination.

We strongly recommend that you back up your configuration files on a regular basis to recover from accidental loss of the configuration file. If you have a backup copy of your configuration file, please use the following procedure to recover an orphan:

  1. Locate the host running the virtual machine.
    If the virtual machine was being migrated with VMotion, look at both the source and the destination.

  2. On that host, copy the configuration file to the directory for the virtual machine. You can usually find it at /vpx/vms/[vmname]_[uuid]. The configuration file is perhaps the only file in that directory with the extension of .vmx or .cfg.

  3. Register the virtual machine on the host using the ESX Server command:
    vmware-cmd -s register /vpx/vms/[vmname]_[uuid]/[cfgfilename]

  4. From VirtualCenter disconnect and reconnect the host.
    VirtualCenter now maps the orphan virtual machine in its database to the configuration file that you registered for the running virtual machine.

VirtualCenter Server must be on same side of firewall as monitored ESX Servers
The VirtualCenter Server connects to the VirtualCenter Agent on the ESX Server for management purposes. For certain operations, such as, installing the VirtualCenter-enabled Agent, deploying a template, etc., the VirtualCenter Agent connects back to the VirtualCenter Server through a random port number. A firewall present between the VirtualCenter Server and the VirtualCenter Agent may block these connections, thereby preventing the VirtualCenter from managing the host.

This restriction does not apply to the VirtualCenter Client.

All monitored ESX Servers must be on the same side of a firewall as the monitoring VirtualCenter Server.

Template Items

Template configuration files are not locked
When a virtual machine is imported as a template, the virtual machine configuration files can be modified after the template is created.

Do not use a source virtual machine with the Store In Place option if the virtual machine will continue to be used.

Cannot concurrently deploy multiple virtual machines from the same SAN-based template
When you try to deploy new virtual machines to two different hosts, only the virtual machine specified first is created.

This issue has been corrected in ESX Server version 2.1.

Operations requested on multi-selected templates do not work
All operations are disallowed when more than one template is selected.

Multiple-select of templates is not supported. Select one template at a time to perform a task.

Cannot select the location when cloning a template
The Clone a Template wizard displays a screen to select where to store the new template, but it is dimmed and not accessible.

The screen indicates where the new template is going to be stored. The screen is for information only.

Customization Items

Cannot enter blank password for the Domain Administrator during customization
When using the Guest Customization wizard you specify the domain the new virtual machine is to join. A password is required in the wizard. The wizard does not accept a blank password or a password with spaces only.

Specify a password that is acceptable for the designated domain.

Hardware and Device Issues

The same disk can be configured with different modes
A virtual disk is allowed to be shared between two virtual machines. Each virtual machine can configure the same virtual disk differently. For example, vm1 configures the disk in persistent mode while vm2 configures the disk in undoable mode. When vm1 is powered on a message appears: "Redo logs are present. Do you want to commit or discard?" When vm2 is power on no message appears.

Do not use the same virtual disk for more than oe virtual machine.

IBM x445 is not listed as a Known Manufacturer or Model
VirtualCenter finds but might not identify an IBM x445 by manufacturer and model number.

No action required. VirtualCenter references system information from a different location than the IBM x445 registers expect.

Browse button is not enabled when CDROM or floppy as ISO image is selected
From the Virtual Machine Control Panel, when you change the CD-ROM or floppy drive to connect to "Use ISO Image", the browse button is disabled.

Type the literal address to the ISO image.

Permissions Issues

Client does not remove permissions entries if a username is changed
If a logged user's username are changed through their Windows accounts, the username changes are not reiterated in VirtualCenter. Even after a log off and relog on, the permissions assigned to the old usernames still apply.

Through VirtualCenter, add permissions for the new usernames and remove permissions for the old usernames.

Failed to list users in secured, trusted domain
When you are logged in as a local user on a system, you are not able to browse the user/groups even though you can authenticate against them. When you are logged in as a domain user on the machine, you can browse the user/groups.

This is a known Microsoft issue when accessing Windows domains through Active Directory servers.

The workaround for the problem is to run the VirtualCenter service using a domain user account instead of local system. The domain user account must be setup with the following permissions on the local system:

  • Member of the Administrators group
  • Act as part of the operating system
  • Log on as a service

If these permissions are not granted to the user, VirtualCenter might fail to start or fail to authenticate users.

Your user account is likely already a member of the Local Administrators group. Please confirm that this is the case.

To configure the Act as part of the operating system and Log on as a service, you must access the Local Security Policy of the system that is running VirtualCenter server.

  1. Open the Windows Control Panel and select Administrative Tools. Double click on the Local Security Policy.

  2. In the Local Security Settings dialog box expand the Local Policies tree and select the User Rights Assignment.

  3. Right click on each of Act as part of the operating system and Log on as a service and select Properties or Security (depending on the Windows opearting system being used).

  4. Double clicking on either of these items provides the same dialogs needed to add the user.

  5. In the available dialogs, add the Domain account that is being used to adminster the VirtualCenter server.