VMware

vSphere Management Assistant (vMA) 4.1
Release Notes

Released 13 Jul 2010

Build 268837 is the release build of the vSphere Management Assistant 4.1.

Any version numbers referenced in this document are placeholders and do not represent any commitment by VMware to have any specific features in the software included in any specific versions.

These release notes contain the following information:

The vSphere Command-Line interface (vSphere CLI) is included with vMA. See the vSphere Command-Line Interface Release Notes for information about vSphere CLI.

About vMA

vMA is a virtual machine that includes prepackaged software. Administrators and developers can use vMA to run scripts and agents to manage VMware ESX/ESXi 3.5 Update 2 and later, ESX/ESXi 4.x, and vCenter Server 4.x systems. vMA includes the vSphere SDK for Perl and the vSphere Command-Line Interface (vSphere CLI). vMA also includes an authentication component (vi-fastpass) and a logging component (vi-logger). vi-fastpass allows direct connection to established target servers without user intervention. vi-logger allows you to collect logs from ESX/ESXi and vCenter Server systems and store the logs on vMA for analysis.

What’s New in vMA 4.1

vMA 4.1 incorporates the following features to improve manageability and usability:

  • vMA 4.1 is a CentOS-based virtual machine.
  • Developers can programmatically connect to vMA by using the APIs provided with the VmaTargetLib library.
  • Users who are logged in to Active Directory can use vMA without logging in again.
  • Users need not run vifp commands under sudo
  • Users need not provide the root password for vifp server commands except addserver.
  • The vifptarget command replaces the vifpinit command.
  • The upgrade utility vima-update is renamed to vma-update.

vMA Components

vMA 4.0 components are compatible with vSphere 4.0 and VMware Infrastructure 3. vMA 4.1 components are compatible with vSphere 4.1, vSphere 4.0, and VMware Infrastructure 3.

vMA 4.0 vMA 4.1
vSphere CLI 4.0 vSphere CLI 4.1
vSphere SDK for Perl 4.0 vSphere SDK for Perl 4.1
VMware Tools VMware Tools (most recent version)

vMA 4.1 has been tested with up to 100 target servers under normal load conditions.

Hardware and Software Requirements

You can deploy vMA to an ESX/ESXi 3.5 Update 2 or later, or ESX/ESXi 4.0 or 4.1 system. See the vSphere Management Assistant Guide for deployment instructions.

To set up vMA, you need the following hardware:

  • ESX/ESXi host. Because vMA runs a 64-bit operating system, the ESX/ESXi host on which vMA is to be deployed must support 64-bit virtual machines. The host must have one of the following CPUs:
    • AMD Opteron, Rev E or later. AMD-V hardware virtualization is not required.
    • Intel processors with EM64T support with VT enabled.
    Note: Opteron 64-bit processors earlier than rev E and Intel processors that have EM64T support but not VT support enabled, do not support a 64-bit guest operating system. For detailed hardware requirements, see the Hardware Compatibility List on the VMware Web site.

    • By default, vMA uses one virtual processor, and requires 5GB of storage space for the vMA virtual disk. The recommended memory for vMA is 512MB.

    You must have the following software to deploy vMA:

    • vSphere 4.1/vSphere 4.0 – You can deploy vMA to ESX/ESXi systems using a vSphere Client connected directly to the
      ESX/ESXi system or using a vSphere Client connected to a vCenter Server 4.0 system.
    • ESX/ESXi 3.5 Update 2 and later – You can deploy on ESX/ESXi 3.5 Update 2 or later using a vSphere 4.0 Client.
    • vSphere Client – You need a vSphere Client for deploying vMA.
    • You can use vMA to target ESX/ESXi 3.5 Update 2 or later, ESX/ESXi 4.0 and 4.1, and vCenter Server 4.0 and 4.1 systems.

    For some information on setting up vMA for a non-English keyboard or a non-default time zone, see KB 1007551.

    Installing vMA

    You can deploy the vMA OVF from your vSphere Client connected to a vCenter Server or ESX/ESXi system, as described in the vSphere Management Assistant Guide.

      1. Download and unzip the vMA ZIP archive.
      2. In the vSphere Client, choose Virtual Appliance > Deploy.
      3. When prompted by the wizard, click Deploy from File and select the OVF in the folder to which you have extracted the ZIP file.
    When you start vMA, proceed as follows:
    • When prompted, specify custom network settings, or accept the defaults.
    • When prompted, supply a host name for the vMA virtual machine or accept the default.
    • When prompted, specify a password for the vi-admin user for logging in to vMA. The vi-admin user has root privileges on vMA. The root user is disabled.

    Important: You can use the vima-update utility to update VIMA 4.0 to vMA 4.1 GA. You cannot, however, use the vima-update utility to upgrade VIMA 1.0 to vMA 4.1.

    Prior Releases of vMA 4.1

    Features and known issues from prior releases of vMA 4.1 are described in the release notes for each release. To view release notes for prior releases of vMA 4.1, go to the following links:

    Resolved Issues

    The following issues that were reported in previous releases of vMA have been resolved:

    • vSphere CLI or vSphere SDK for Perl commands fail against fpauth targets if targets are specified by --server and vi-fastpass is not initialized.
      After you add targets using the fastpass authpolicy to vMA, if you call a vSphere CLI or vSphere SDK for Perl command with the --server option before running vifptarget first, vMA does not prompt you for username or password for that server. The command fails with the error that the username or password is incorrect. The issue is resolved in vMA 4.1.

    • When /var/log partition fills up, vMA might display unpredictable behavior.
      When the /var/log partition on vMA fills up, typically because a large amount of log data has been collected, vMA behaves in an unpredictable manner. vMA might exhibit the following symptoms:
      • vilogger commands fail because vilogd is stopped and cannot be restarted.
      • vifp commands display logs on the screen instead of saving the log output in the log files.

      • The issue is resolved in vMA 4.1.

    • vi-user cannot run vifp listservers and vifp help.
      In VIMA 1.0, a user logged in as vi-user can run any vifp command that does not require sudo. In vMA 4.0, vi-user can run only the vilogger help and vifpinit commands. The issue is resolved in vMA 4.1.

    • svmotion does not support vi-fastpass.
      The svmotion commands do not support vi-fastpass. The issue is resolved in vMA 4.1.

    • vilogger and vSphere CLI commands fail because of credential store corruption.
      If a call to vifp rotatepassword is interrupted, for example, because network connectivity is lost or the user presses Ctrl+C at the command prompt, the local credential store file (vicredentials.xml) might become corrupted. The issue is resolved in vMA 4.1.

    • vMA Linux prompt shows target server after removal.
      If you add a target server, and then call vifpinit, the server becomes the default target, and the vMA Linux prompt changes to show that server. Even when you remove the server, the default target does not change and the prompt continues to display it. The issue is resolved in vMA 4.1.

    • Illegal stack size warning in vifp.log.
      The vifp.log files include the following messages: 'ThreadPool' 46912592633456 warning] Illegal stack size value '256' in configuration file, setting to default = 256. The issue is resolved in vMA 4.1. In this release, vifpd.log replaces vifp.log.

    • Incorrect association for RDM snapshots
      The SMI-S CIM Server that runs inside vMA incorrectly handles a storage configuration that contains an RDM linked to a snapshot of the virtual disk. The issue is resolved in vMA 4.1.

    • Issue when running SMI-S using WSMan from vMA when Virtual RDM has snapshots.
       The SMI-S CIM Server that runs in vMA incorrectly handles a storage configuration that contains an RDM linked to a snapshot of the virtual disk. The VMware_StorageExtent instance that represents the LUN of the RDM is linked by a VMware_RDMBasedOn association to the VMware_RDMStorageVolume instance that represents the virtual disk. In the presence of a snapshot, a traversal of the RDMBasedOn association from the RDMStorageVolume to the StorageExtent reports the correct result, but a traversal in the reverse direction reports an incorrect result. When the client traverses RDMBasedOn from the StorageExtent instance to the RDMStorageVolume instance, the CIM server incorrectly returns a reference to the associated SnapshotStorageVolume. The issue is resolved in vMA 4.1.

    • Cannot use --username if vi-fastpass has been set up.
      If you add target servers, initialize vi-fastpass with vifpinit, and then you call a vSphere CLI or vSphere SDK for Perl command specifying --username <username>, vMA does not prompt you for a password for that user. The command fails with the error incorrect username/password. The issue is resolved in vMA 4.1.

    Known Issues

    The vMA 4.1 release has the following known issues:

    • WSMan-based programs do not support vi-fastpass. If you add one or more targets to vMA, initialize vi-fastpass by running the command vifptarget -s <target>, and then run any WSMan-based program in /usr/share/doc/vmware-vcli/samples/WSMan for any target, the program fails with one of the following errors: 401 Unauthorized or 500 Can't connect to localhost:80 (connect: Connection refused)
      Workaround: Perform the following steps:
      a. Clear the vi-fastpass environment by running the command vifptarget -c.
      b. Run the WSMan-based program again by specifying any target.
    • The command vifp addserver fails with the error message Failed to add users. After you join vMA to an Active Directory domain, and then add targets with adauth policy by running the command vifp addserver <server> --authpolicy adauth, if you have not restarted vMA after joining the domain, and if you are using the Active Directory domain account for adding targets, the vifp addserver command might fail with the error Failed to add users.
      Workaround: Reboot vMA after joining it to domain.
    • If vifptarget is initialized, the vmware-toolbox-cmd -v command displays the message 2.4+ kernel w/o ELF notes? -- report this. You add one or more targets to vMA and run vifptarget using vifptarget -s. If you call the vmware-toolbox-cmd -v command, the command displays the message 2.4+ kernel w/o ELF notes? -- report this before displaying the usual output.
      Workaround: None. You can just ignore the error message.

    • resxtop requires username/password in vi-fastpass environment. You add one or more targets to vMA, initialize vi-fastpass using the command vifptarget -s <target>, then you call resxtop against any target, vMA still requires you to provide the credentials for the target.
      Workaround: Provide target's username/password for resxtop command manually.

    • Cannot move or clone vMA. Moving or cloning vMA is not supported.
      Workaround: No workaround.

    • When vi-user runs the vicfg-snmp vSphere CLI command, incorrect error message appears. If you log in to vMA as vi-user and run vicfg-snmp, the following error message is displayed: System does not have SNMP agent configuration supported. This error message is incorrect. It should explain that vi-user does not have privileges for running the command.
      Workaround: There are two workarounds:
      • Log in to vMA as vi-admin to run the command.
      • Log in to a different shell as vi-user and run the command without vi-fastpass by specifying the target using the --server option.
    • Poor vSphere Client performance because of vMA log collection. On a vSphere Client connected to an ESX/ESXi host, performance is poor. If vMA is collecting logs from that ESX/ESXi host, check the vMA vilogd log file for authentication failure errors. Errors might occur because the authentication credentials for the ESX/ESXi host might have become out of sync with the vMA credentials, and the vMA connection attempts to slow down the vSphere Client.
      Workaround: Remove the ESX/ESXi host from vMA by using vifp removeserver, and then add the server again using vifp addserver.

    • Deploying vMA on ESXi 3.5 Update 2 hosts is slow. When you deploy vMA 4.0 on an ESXi 3.5 Update 2 host, expect slow performance during deployment.
      Workaround: This issue is resolved for later versions of ESXi 3.5. You might also consider deploying on an ESX/ESXi 4.0 or on an ESX 3.5 Update 2 host.

    • No error when deploying vMA on unsupported hardware. When you deploy vMA on unsupported hardware, no error appears. An error is displayed only when you attempt to start the virtual machine.
      Workaround: Deploy vMA on a supported platform. See Hardware and Software Requirements.

    • Cannot disable time synchronization on vMA. When you resume a suspended vMA instance, reboot vMA, or take a checkpoint, the vMA system time is synchronized with the ESX/ESXi system on which vMA runs, even if tools.syncTime is set to false in the VMX file. The tools.syncTime option controls only whether time is periodically resynchronized while the virtual machine is running.
      Workaround: See VMware KB 1189 for information on disabling time synchronization completely.

    • vima-update does not update VMware Tools. After you upgrade vMA 4.0 to vMA 4.1 by using vima-update reboot vMA, VMware Tools is not updated.
      Workaround: Perform the following steps to update VMwareTools manually:

      1. Update vMA 4.0 to vMA 4.1 by using vima-update.
      2. Reboot vMA and then log in as vi-admin.
      3. Remove the old version of VMware Tools by running sudo rpm -e VMwareTools.
      4. Install the latest version of VMware Tools on vMA using the instructions provided in the VMware Tools Installation Guide.


    Last updated 13-July-2010