VMware

VMware CIM APIs 4.1 Release Notes

Released 13 Jul 2010

Build 260247

This document contains the following information:

About the VMware CIM APIs

The VMware Common Information Model (CIM) APIs allow you to view virtual machines and resources using profiles defined by the Storage Management Initiative Specification (SMI-S) or to manage hosts using the System Management Architecture for Server Hardware (SMASH) standard.

Requirements

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

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

  • ESX 4.1 | 13 Jul 2010 | Build 260247
  • OR
  • ESXi 4.1 | 13 Jul 2010 | Build 260247

To use the CIM Storage Management API, install:

  • (required) vSphere Management Assistant (vMA) 4.1 | 13 Jul 2010 | Build 257945
  • (optional) vCenter Server 4.1 | 13 Jul 2010 | Build 258902
  • AND
  • either of:
    • ESX 4.1 | 13 Jul 2010 | Build 260247
    • OR
    • ESXi 4.1 | 13 Jul 2010 | Build 260247
The CIM Storage Management API requires the vSphere Management Assistant as well as ESX/ESXi and optional vCenter Server.

What’s New in This Release?

This release of the VMware CIM APIs includes the following new features:

  • Support for the SMASH Software Inventory profile on ESX
  • Support for the SMASH Software Update profile on ESX

    Note: Software Update on ESX requires you to enable outgoing connections in the ESX firewall. You can use this command at a shell window:
           esxcfg-firewall --allowOutgoing
           
  • Support for Active Directory on ESXi

    Support for Active Directory has been added to ESXi, which allows CIM applications to integrate easily with enterprise security domains using Active Directory controllers. Active Directory was supported on ESX previously, but was not supported on ESXi until this release.

Resolved Issues

This release of the VMware CIM APIs resolves the following issues:

  • (Storage Management API)

    Performance problems with large configurations. In very large datacenters, the CIMOM could have performance problems. VMware did not recommend configurations over 100 hosts, 1000 virtual machines, and 100 storage volumes.

    This problem has been corrected. CIMOM performance now scales up to the maximum size datacenter managed by vCenter.

  • (Storage Management API)

    Incorrect association for RDM snapshots   The SMI-S CIM Server that runs in the vMA incorrectly handled a storage configuration that contained 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 traversed the RDMBasedOn association from the StorageExtent instance to the RDMStorageVolume class, the CIM server returned incorrect data. The RDMStorageVolume instance returned by the CIM server incorrectly reported data for the Snapshot, instead of data for the original RDM.

    This problem has been corrected.

  • (Storage Management API)

    Failure of associators for virtual disks in nested folders.   For virtual disk files that were stored in nested folders, the CIMOM failed to return data for associator classes related to the virtual disks.

    For instance, the associator class VMware_VirtualDiskProtocolControllerForUnit normally connects VMware_VirtualDiskSCSIProtocolController with VMware_FileStorageVolume, but the CIMOM did not report any instances of the VMware_VirtualDiskProtocolControllerForUnit class. This problem existed for virtual disks whose datastore paths resembled [datastore] folder/nested_folder/vm.vmdk. Virtual disks whose inventory paths contained only one folder, such as [datastore] folder/vm.vmdk, were reported correctly by the CIMOM.

    This problem has been corrected. Associator classes are reported correctly regardless of the presence of nested folders in the paths to virtual disks.

  • (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 invoked the Reset() method to clear the SEL contents, it worked for node 0 but not for any other nodes.

    This problem has been corrected.

  • (SMASH/Server Management API)

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

    • The PowerManagementService.Reboot() method incorrectly reported success while the host was in lockdown mode.
    • The RecordLog.ClearLog() method succeeded, but it should have been rejected.
    • During Lockdown mode, the CIMOM made system calls in a loop, which could increase CPU utilization to 100%.
    • The repeated system calls caused authentication failure messages to be written to system logs.

    These problems have been corrected. The CIM extrinsic methods have the following limitations:

    • The CIMOM now rejects extrinsic methods during lockdown mode unless the client authenticates with a 'ticket' acquired from an AcquireCIMServicesTicket() request to the vSphere Web Services API. The ticket can only be issued if the host is managed by vCenter.
    • However, the RequestPowerStateChange() extrinsic method always authenticates with the host rather than accepting 'ticket' authentication. During lockdown, the host does not accept authentication requests, so the PowerManagementService.Reboot() method always fails during lockdown.

  • (SMASH/Server Management API)

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

    The documentation has been corrected.

  • (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.

    This problem has been corrected for the MR_BBU_TYPE_iTBBU3 battery type, but not for all battery types.

  • (SMASH/Server Management API)

    Indication subscriptions in Implementation namespace.   The CIM server erroneously activated 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 would deliver indications in response to subscriptions in either namespace.

    The behavior of SFCB has been changed. Indication subscriptions can no longer be created in the Implementation namespace.

Known Issues and Workarounds in SMASH/Server Management API

  • (SMASH/Server Management API)

    IPv6 not supported for WS-Man. 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)

    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.

Known Issues and Workarounds in Storage Management API

  • (Storage Management API)

    CIMOM limitation 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. If the Management Assistant is bound to a vCenter server that manages more than 1000 registered virtual machines, and many more unregistered virtual machines, the CIMOM can fail when enumerating VMWARE_VMComputerSystem or when enumerating instances of CIM_StorageVolume.

  • (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)

    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 07-Jul-2010 17:30 pm