vSphere Management Assistant (vMA) 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.
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.
Whats 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
- Users need not provide the root password for
vifpserver commands except
vifptargetcommand replaces the
- The upgrade utility
vima-updateis renamed to
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.
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.
- 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.
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:
For some information on setting up vMA for a non-English keyboard or a non-default time zone, see KB 1007551.
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.
- Download and unzip the vMA ZIP archive.
- In the vSphere Client, choose Virtual Appliance > Deploy.
- 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 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.
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:
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
--serveroption 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.
/var/logpartition 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:
viloggercommands fail because
vilogdis stopped and cannot be restarted.
vifpcommands display logs on the screen instead of saving the log output in the log files.
- vi-user cannot run vifp listservers and vifp help.
In VIMA 1.0, a user logged in as vi-user can run any
vifpcommand that does not require
sudo. In vMA 4.0, vi-user can run only the
vifpinitcommands. The issue is resolved in vMA 4.1.
- svmotion does not support vi-fastpass.
svmotioncommands 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 rotatepasswordis 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.
vifp.logfiles 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,
- 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_StorageExtentinstance that represents the LUN of the RDM is linked by a
VMware_RDMBasedOnassociation to the
VMware_RDMStorageVolumeinstance that represents the virtual disk. In the presence of a snapshot, a traversal of the
RDMBasedOnassociation from the
StorageExtentreports the correct result, but a traversal in the reverse direction reports an incorrect result. When the client traverses
StorageExtentinstance to the
RDMStorageVolumeinstance, 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.
The issue is resolved in vMA 4.1.
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/WSManfor any target, the program fails with one of the following errors:
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
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
adauthpolicy 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 addservercommand might fail with the error
Failed to add users.
Workaround: Reboot vMA after joining it to domain.
vifptargetis initialized, the
vmware-toolbox-cmd -vcommand displays the message 2.4+ kernel w/o ELF notes? -- report this. You add one or more targets to vMA and run
vifptarget -s. If you call the
vmware-toolbox-cmd -vcommand, the command displays the message
2.4+ kernel w/o ELF notes? -- report thisbefore 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-snmpvSphere 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
- 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
vilogdlog 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
- 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.syncTimeis set to
falsein the VMX file. The
tools.syncTimeoption 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-updatereboot vMA, VMware Tools is not updated.
Workaround: Perform the following steps to update VMwareTools manually:
- Update vMA 4.0 to vMA 4.1 by using
- Reboot vMA and then log in as
- Remove the old version of VMware Tools by running
sudo rpm -e VMwareTools.
- Install the latest version of VMware Tools on vMA using the instructions provided in the VMware Tools Installation Guide.
Last updated 13-July-2010