VMware CIM SMASH API 5.0 Release Notes

Released 24 Aug 2011

This document contains the following information:

About the VMware CIM SMASH API

The VMware Common Information Model (CIM) SMASH API allows you to view and to manage hosts using the System Management Architecture for Server Hardware (SMASH) standard.


These release notes apply to vSphere 5.0. You should install the following software to use the CIM SMASH API.

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

  • ESXi 5.0 | 24 Aug 2011 | Build 469512

What’s New in This Release?

This release of the VMware CIM SMASH API includes the following new features:

  • Support for CIM schema version 2.26.0 Final
  • Support for the SMASH PCI Device profile on ESXi
  • Improved support for blade servers in ESXi
  • Support for CIM upgrade of ESXi host from offline bundles has been added. Support for on-line depots has been removed.
  • The CIM Storage Management API is deprecated in this release.
  • The StubObs module of the Perl WS-Management client library is deprecated in this release.
  • Removal of third-party providers: ESXi 5.0 no longer ships with pre-installed providers from third-party vendors. ESXi now contains only VMware-supplied providers. Vendor providers must be installed separately.
  • The Power State Management profile is deprecated in this release.

Resolved Issues

This release of the VMware CIM SMASH API resolves the following issues:

  • Ws-Eventing "Filtering Not Supported" error.   The WS-Management server returned a "Filtering Not Supported" error when a subscription request correctly included a Filter element in the WS-Eventing namespace. The server incorrectly accepted a Filter element in the WS-Management namespace.

    This problem has been corrected. The Ws-Management server now accepts Filter elements only in the WS-Eventing namespace.

  • Ws-Man "Invalid Message Information Header" error.   The WS-Management server returned the error "Invalid Message Information Header" when a request contained an xs:duration value.

    This problem has been corrected.

  • Limit on number of log records.   Enumerating CIM_LogRecord produced only 512 log records. This was a limit imposed by resource constraints that no longer apply.

    This problem has been corrected.

  • File descriptor leak in CIMOM.   The CIMOM would leak memory in certain error cases. As a result, the CIMOM would eventually become unable to process new requests.

    This problem has been corrected.

Known Issues and Workarounds

  • StubOps.pm deprecated.   The StubOps module in the VMware vSphere SDK for Perl has been deprecated. The StubOps module is one of three Perl libraries available for CIM WS-Management operations using Perl clients.

    Workaround:   VMware recommends using the GenericOps module instead of the StubOps module.

  • Power State Management deprecated.   The Power State Management profile has been deprecated. Power State Management included the RequestPowerStageChange() method, which could be used to reboot the managed server.

    Alternative ways to reboot the server include the Vicfg-hostops utility, which is described in the vSphere Command-Line Interface reference documentation. You can also reboot the server by accessing the vSphere API directly.

  • CIM Software Upgrade feature does not install from online depot.   Software upgrade using the CIM extrinsic method InstallFromURI() behaves differently in this release. In vSphere 4.0, InstallFromURI() was designed to install VIBs from a depot. In vSphere 5.0, InstallFromURI() has been changed to install VIBs from an offline bundle.

    Package the necessary VIBs in an offline bundle that is hosted on a local partition on the ESX host machine, then pass the path to the offline bundle as URI to the InstallFromURI() method. The offline bundle is a compressed file that needs to be expanded before installation. VMware recommends against installing an offline bundle from a system partition or a temporary partition of limited size.

    Information about creating offline bundles is available in the ImageBuilder as well as vib-tools documentation

  • WS-Man fails when multiple CIM VIBs are installed.   WS-Management requests fail when directed to an ESX/ESXi system that has more than one CIM provider VIB installed. This problem does not occur when only one VIB containing CIM providers is installed. This problem occurs when installation of a second VIB containing CIM providers corrupts the WS-Man configuration,

    Workaround:   To correct the WS-Man configuration, modify the file /etc/init.d/wsman.

    1. Open a shell window connected to the ESX/ESXi server.
    2. Set the sticky bit on /etc/init.d/wsman.
           chmod +t /etc/init.d/wsman
    3. Open /etc/init.d/wsman with a text editor and find the following line:
           local oem_lines=$(cat /etc/cim/openwsman/*.conf 2>/dev/null | sed -e 's-\n-,-g')
      Replace the line with the following:
           local oem_lines=$(awk '{ printf "%s,", $0 }' /etc/cim/openwsman/*.conf 2>/dev/null \
                           | sed -e 's-,\{2,\}-,-g' -e 's-,$--')
    4. Restart the WS-Man server.
           /etc/init.d/wsman start

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

  • IPv6 not supported by SLP.   SLP advertisement for CIM providers does not support IPv6.

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

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

  • SNMP trap for a change in VMKernel IP address is not available.   When you change the IP address assigned to the VMKernel, no SNMP trap is generated.

    Workaround:   You can use the CIM API to monitor VMKernel IP Change Notifications. To get notification of a change in the VMKernel IP address, use the CIM SMASH/Server Management API to subscribe to CIM_InstModification indications on the VMware_KernelIPProtocolEndpoint class. A change in VMKernel IP address will cause an indication of type VMware_KernelIPChangedIndication.

  • Indication issued for scanning disabled sensor.   The CIMOM incorrectly issues indications related to sensors that have scanning disabled. These indications are confusing because the CIMOM cannot enumerate such sensors in response to a client request.

  • winrm on Windows XP not compatible with vSphere 5.0 WS-Man support.   ESXi 5.0 no longer supports WS-Management communications from the Windows Remote Management (winrm) client running on Windows XP. Versions of winrm on more recent Windows hosts are supported.

    ESXi 5.0 has been upgraded to more secure encryption algorithms that are incompatible with older versions of winrm.

    Workaround:   To configure ESXi 5.0 to use encryption algorithms compatible with winrm on Windows XP:

    1. Edit the file /etc/vmware/hostd/config.xml.
    2. Locate the <vmacore>...</vmacore> tags in the file.
    3. Within the vmacore element, locate the <ssl>...</ssl> tags.
    4. Within the ssl element, add the following element:
    5. Save the file and restart hostd.

  • CIMOM reported an error for some InstallFromURI() invocations.   The Small Footprint CIM Broker (SFCB) reported a CIM_ERR_TYPE_MISMATCH error when a client sent a CIM-XML request to invoke the InstallFromURI() method. This happened only when the method invocation included a value for the InstallOptions parameter.

    Third-party providers that implement software update might accept a value for the InstallOptions parameter. In these situations, the SFCB CIM-XML parser would reject the request if it did not contain PARAMTYPE attributes.

Last updated 24-Aug-2011 06:00 am