VMware

VMware CIM APIs 4.0 Release Notes

Released 21-May-2009

This document contains the following sections:

Requirements

These release notes apply to vSphere 4. You should install the following software to use the CIM APIs.

To use the CIM SMASH/Server Management API, install either of:

  • ESX 4.0 | 21-May-2009 | Build 164009
  • OR
  • ESXi 4.0 | 21-May-2009 | Build 164009

To use the CIM Storage Management API, install:

  • (required) vSphere Management Assistant (vMA) 4.0 | 21-May-2009 | Build 161993
  • (optional) vCenter Server 4.0 | 21-May-2009 | Build 162902
  • AND
  • either of:
    • ESX 4.0 | 21-May-2009 | Build 164009
    • OR
    • ESXi 4.0 | 21-May-2009 | Build 164009

The CIM Storage Management API requires the vSphere Management Assistant as well as ESX/ESXi and optional vCenter Server.

What’s New

This release of the VMware CIM APIs includes:

  • The vSphere Management Assistant (vMA) is now available to help manage datacenter servers remotely. The vMA includes a CIM server with CIM-XML and WS-Man support for the VMware CIM Storage Management API. For information on setting up the vMA to use the CIM Storage Management API, see Chapter 2 of the VMware CIM Storage Management API Programming Guide.

    The vMA can connect to the following servers:

    • Either a single ESX host or a vCenter Server that manages a datacenter.
    • ESX 4.0 or vCenter Server 4.0
    • ESX 3.5 or vCenter Server 2.5

  • The VMware SMASH/Server Management API now supports version 2.19.1 (experimental) of the CIM schema. Previous releases supported version 2.17.

  • The VMware SMASH/Server Management API documentation is now available in a single download. A ZIP file containing the programming guide and the API and profile reference documentation can be downloaded from http://www.vmware.com/support/developer/cim-sdk/4.0/smash/.

    The VMware Storage Management API documentation continues to be available, along with samples, in a single download. See the landing page at http://www.vmware.com/support/developer/cim-sdk/4.0/smi/.

  • Both the CIM SMASH/Server Management API and the CIM Storage Management API have a new format for their reference documentation. Formerly, the CIM SMASH/Server Management API had separate HTML documentation for the API itself and for the SMASH profile support. Both features have been combined into a single HTML set for this release.

    The CIM Storage Management API, which formerly had only the API documentation and no profile support documentation, has adopted the same reference format as the CIM SMASH/Server Management API.

Problems Fixed in this Release

  • (Storage Management API)

    Incorrect parameter in Java samples.   The Java samples available for the CIM Storage Management API incorrectly label the first argument of the script as the "hostname." For the WBEM Services client library, the first argument should be labelled "hostURL."

    This problem has been corrected.

  • (SMASH/Server Management API)

    Unknown State Reported for Some Health Status Sensors.   On some HP servers, such as the BL 465C, certain sensors named "ProcHot for System Board x" can give confusing IPMI data to the CIM provider. These sensors can assert more than one state simultaneously.

    To avoid confusion in these situations, the provider now reports the Health Status for these sensors as Unknown.

Known Issues and Workarounds in SMASH/Server Management API

  • (SMASH/Server Management API)

    IPv6 and WS-Man not supported.   WS-Management will not function in a pure IPv6 environment, although it does function in a mixed IPv4 and IPv6 environment while using IPv4.

  • (SMASH/Server Management API)

    IPMI OEM Extension service incorrect CreationClassName.   Instances of CIM_Service that represent the VMware IPMI OEM Extension service contain an incorrect value for the CreationClassName. The value is "VMware_IPMIOEMExtensionService" but it should be "VMware_IPMIOEMExtensionServiceImpl"

    Workaround:   To avoid this problem, enumerate either CIM_HostedService or the derived class VMware_IPMIOEMHostedService instead.

  • (SMASH/Server Management API)

    Failure to clear the SEL in a multi-node IBM System x3950 M2 for any node except node 0.   On multi-node IBM System x3950 M2 systems, if you invoke the Reset() method to clear the SEL contents, it works for node 0 but not for any other nodes. The invokeMethod() call to clear the SEL appears to succeed on another node but it does not actually clear the log for that node.

  • (SMASH/Server Management API)

    Incorrect state for RAID battery sensor in an IBM System x3950 M2.   A sensor for a RAID backup battery on IBM System x3950 M2 systems can sometimes show an error even when the battery is fully charged. One known case is when the HealthState property shows a value of 30 (Non-recoverable Error), while the BatteryStatus property shows a value of 3 (Fully Charged).

    Workaround:   Updating the firmware on the host might correct this problem, but does not do so in all cases.

  • (SMASH/Server Management API)

    CIM SMASH Server Management API Limitation for DRS Clusters.   When you use the CIM SMASH/Server Management API to shut down or reboot a managed server that is a node in a DRS cluster, virtual machines currently running on the server might end up in unexpected states when the host shuts down. Some virtual machines might successfully migrate to other servers, while some might be left in a suspended state on the server that is shutting down.

    Workaround:   Manually migrate or shut down virtual machines before shutting down or rebooting the host using the CIM SMASH/Server Management API.

  • (SMASH/Server Management API)

    Alert indications depend on SEL.   Alert indications for a managed server rely primarily on the contents of the System Event Log (SEL). If the SEL is disabled, or if it is full and cannot accept new log entries, you will not receive most alert indications for new events.

    System status is shown correctly in response to CIM queries, regardless of indication delivery. To receive indications when the SEL is not accepting new entries, consult your hardware vendor's system documentation or see the CIM SMASH/Server Management Programming Guide for guidance to clear the SEL from a CIM client.

    The SEL can also be cleared with the vSphere Client when connected to a vCenter Server. On the Hardware tab, choose System Event Log from the View menu and click Reset event log.

  • (SMASH/Server Management API)

    Indication subscriptions in Implementation namespace.   The CIM server erroneously activates subscriptions that have been created only in the Implementation namespace.

    The Indications profile published by the DMTF requires clients to create indication subscriptions in the Interop namespace. Optionally, clients may create duplicate subscriptions in the Implementation namespace. The CIM server currently delivers indications in response to subscriptions in either namespace.

    If your CIM client does not create subscriptions in the Interop namespace, you should change your client to use the correct namespace. You should not rely on the current behavior of the CIM server.

  • (SMASH/Server Management API)

    CIM SMASH Server Management API Limitation for DRS Clusters   When you use the CIM SMASH/Server Management API to shut down or reboot a managed server that is a node in a DRS cluster, virtual machines currently running on the server might end up in unexpected states when the host shuts down. Some virtual machines might successfully migrate to other servers, while some might be left in a suspended state on the server that is shutting down.

    Workaround:   Manually migrate or shut down virtual machines before shutting down or rebooting the host using the CIM SMASH/Server Management API.

  • (SMASH/Server Management API)

    ESXi Lockdown mode not handled correctly   The CIMOM on an ESXi host shows these problems while the host is in Lockdown mode:

    • The PowerManagement.Reboot() method reports success but does nothing. It should report an error.
    • The RecordLog.ClearLog() method succeeds. It should fail with an error message.
    • During Lockdown mode, the CIMOM makes system calls in a loop, which can increase CPU utilization to 100%.
    • The repeated system calls cause authentication failure messages to be written to system logs.

    Workaround:   You can work around these problems by restarting Management Agents on the ESXi host after entering Lockdown mode. After the agents restart, the CIMOM correctly handles method calls and does not flood the system logs. However, subsequent attempts to access VMware_Role or VMware_Privilege instances will cause the CIMOM to log permission errors.

  • (SMASH/Server Management API)

    Simple Identity Management profile not supported   The reference documentation for the SMASH/Server Management API shows partial support for the Simple Identity Management profile, but this is incorrect. The Simple Identity Management profile is not enabled in this release.

Known Issues and Workarounds in Storage Management API

  • (Storage Management API)

    CIMOM failure with large configurations.   In very large datacenters, certain operations in the CIM Storage Management API can cause the CIMOM in the vSphere Management Assistant to fail. The failures can occur when enumerating VMWARE_VMComputerSystem or CIM_StorageVolume instances.

    If the Management Assistant is bound to a vCenter server that manages more than 1000 virtual machines, the CIMOM can fail when enumerating VMWARE_VMComputerSystem. Failures can also occur when enumerating instances of CIM_StorageVolume, if the datastores managed by the vCenter server contain more than 2000 virtual machines, even when fewer than 1000 virtual machines are registered. In the latter case, the total number of virtual machines present on all managed storage volumes is more significant than the number of managed virtual machines.

    Workaround:   In these large vCenter environments, you should avoid enumerating CIM_StorageVolume and VMWARE_VMComputerSystem if your datacenter contains more than 1000 virtual machines. If your datacenter contains fewer than 2000 virtual machines, you can obtain instances of VMWARE_VMComputerSystem from related association instances. Larger configurations cannot be managed by the CIMOM in this release.

  • (Storage Management API)

    Performance problems with large configurations.   In very large datacenters, the CIMOM can have performance problems. VMware has tested configurations up to 100 hosts, 1000 virtual machines, and 100 storage volumes, with acceptable performance.

    At this time, VMware does not recommend using the Management Assistant with datacenters larger than 100 hosts, 1000 virtual machines, and 100 storage volumes.

  • (Storage Management API)

    CIMOM in vMA may not restart   The CIMOM in the vSphere Management Assistant can fail to restart if the CIMOM is not shut down cleanly. If you 'kill' the Pegasus server in the vMA, it may leave behind an orphaned PID file that prevents restarting Pegasus.

    To recover from this situation, do the following:

    1. Become root in a shell window in the vMA.
    2. Determine whether the Pegasus CIMOM is running (or not):
      ps auwx | grep -i cim

      Examine the output, looking for any Pegasus process. If the only output from the command is the grep command itself, Pegasus is not running, and you should proceed with these remaining steps:
    3. Delete the orphaned PID file:
      rm /var/run/vmware/watchdog-cimserver.PID
    4. Start Pegasus:
      /etc/init.d/pegasus start

  • (Storage Management API)

    Incorrect association for RDM snapshots   The SMI-S CIM Server that runs in the 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, if you traverse the RDMBasedOn association from the StorageExtent instance to the RDMStorageVolume class, the CIM server returns incorrect data. The RDMStorageVolume instance returned by the CIM server incorrectly reports data for the Snapshot, instead of data for the original RDM. However, if you traverse the RDMBasedOn association from the RDMStorageVolume instance to the StorageExtent class, the CIM server returns the correct StorageExtent.

  • (Storage Management API)

    Java samples incompatible with JDK1.6   The Java samples provided in the CIM Storage Management SDK do not work with version 1.6.x of the JDK. You need JDK 1.5.x to run the samples.

Last updated 05-Nov-2009 18:00 pm