VMware Release Notes for VMware Scripting API Version 2.3
These release notes cover the following topics:
- Changes Since the VMware Scripting API 2.1.5 Release
- Features Not Fully Implemented
- Miscellaneous Issues
Changes Since the VMware Scripting API 2.1.5 Release
This release includes an updated manual (VMware Scripting API 2.3).
Support for ESX Server 3.0 hosts.
The Scripting API now supports remote operations to an ESX Server 3.0 host from a Windows or Linux machine.
Updated snapshot feature.
ESX Server 3.0 does not support per-disk redo logs. The Scripting API has been updated with the capability to use the ESX Server 3.0 snapshot feature instead.
The default port number for ESX Server 3.0 is 443 (previous products used 902).
Some system and virtual machine statistics are not supported in ESX Server 3.0. Refer to the Scripting API User's Manual for more information.
The getid functions are supported differently for ESX Server 3.0. For ESX Server 3.0, a unique ID is returned for a running virtual machine. Previous versions of ESX Server returned the world ID of the virtual machine. As the world ID is not meaningful in ESX Server 3.0, the unique ID that is returned is generated from the Managed Object Reference ID (moRef).
ESX Server 3.0 does not support calls that return the pid of the virtual machine.
For ESX Server 3.0, performing a GetResource query on the net.adapters variable with a virtual machine object returns a space-delimited list of numeric IDs. Each numeric ID identifies a virtual adapter belonging to the virtual machine.
Features Not Fully Implemented
The following features are not fully implemented in this release:
The VMware Scripting API does not support the full feature set of the Virtual Infrastructure SDK but is provided solely to update the existing functionality of the Scripting API to support ESX Server 3.0.
The VMware Scripting API cannot access a Virtual Center Server as a target host. All operations must be directed to a GSX Server host or an ESX Server host only.
vmware-cmd stop returns success too early. (KB 2164514)
The virtual machine may still be running when VmPerl::VM::stop or 'vmware-cmd
The VmPerl::VM::stop and 'vmware-cmd
stop' operations return right after the power off request is sent to the virtual machine. This means there will be some delay after the operations return before the virtual machine is completely stopped.
WorkaroundScripts that require the virtual machine to be off can either introduce a short delay, or poll for the virtual machine's power state or heartbeat before continuing.
Standalone installer cannot upgrade after master installer.
The Scripting API installer is unable to upgrade the API package if the original installation was done from the master installer of GSX Server or VMware Server. This is a limitation of the Windows Installer Service. The installer displays the following message:
The system administrator has set policies to prevent this installation.
WorkaroundThere are two ways you can work around this problem and upgrade your Scripting API installation.
Uninstall GSX Server or VMware Server. Reinstall (using the master installer) as before but with this exception: Select a custom installation and deselect the Scripting API components. After GSX Server or VMware Server has installed, use the standalone Scripting API installer to install the API packages as a separate step.
If you don't need GSX Server or VMware Server installed, there is no need to do the reinstallation. Just use the standalone installer for the Scripting API.
Select a different machine that has no GSX Server or VMware Server installation. Install only the Scripting API, using the standalone installer.