VMware

VMware vCloud Automation Center 5.2.3 (5.2.6 Build 82) Release Notes

vCloud Automation Center 5.2.3 | 28 OCT 2014 | 5.2.6 Build 82

What's in the Release Notes

The release notes cover the following topics:

What's New

  • Accommodating vSWAP during virtual machine allocation operation for vCenter Server endpoint
  • The vSWAP feature tries to check the availability of the maximum size of SWAP file, which is equal to virtual machine memory on the storage where the virtual machine is provisioned during allocation checks for creation and reconfiguration. For more information on the vSWAP feature, see the vCloud Automation Center 5.2.3 Operating Guide.

  • Bulk Import by using command line
  • The import commands enable you to import one or more virtual machines into a vCloud Automation Center deployment.
    Machine-BulkRegisterExport: Creates a CSV data file that is used to import virtual machines to a vCloud Automation Center deployment.
    Machine-BulkRegisterImport: Imports one or more virtual machines to a target vCloud Automation Center deployment.

  • Customizing data rollover
  • Data rollover feature moves the data to archive tables or purges the data permanently. You can decide the maximum number of days of data to be retained and also can configure if you want to permanently remove the data and move the data to archive tables. For more information on the data rollover feature, see the vCloud Automation Center 5.2.3 Operating Guide.

  • Support for Ubuntu 14.04
  • Support for Ubuntu as a guest operating system has been added in this release.

  • Ability to rename an existing provisioning groups or enterprise groups
  • Ability to rename an already existing Provisioning Group or Enterprise Group has been added in this release.

  • Support to add more than 15 disks for each virtual machine

System Requirements and Installation

For information about supported host operating systems, databases, and Web servers, see the vCloud Automation Center Support Matrix.

For additional prerequisites and installation instructions, see vCloud Automation Center 5.2.3 Installation Guide.

Resolved Issues

This section describes issues resolved in vCloud Automation Center 5.2.3.

  • Blueprints get disabled in the vCloud Automation Center and you cannot provision machines out of the blueprint
    If a vApp template record has IsMissing set to True, the next data collection deletes the vApp. As a result the blueprints get disabled in the vCloud Automation Center user interface, and you cannot provision machines out of a blueprint.

  • This issue has been resolved in this release.

  • Linux Gugent RPM installation sets umask to 0, hence the files or directories created by the guest agent becomes world-writeable
    This issue has been resolved by changing the Gugent install script. You can use the noumask argument during Linux Gugent install to prevent files and directories from becoming world-writable.

  • Executive Summary or Dashboard reports are not populated with information
    Executive Summary Cloud, Capacity Usage by Blueprint, Capacity Usage by Compute Resource, Capacity Usage by Group, Capacity Usage by Owner are not getting populated when you select the Machine Type Cloud.

  • This issue has been resolved in this release.

  • Adding a component to an existing multi-machine leads the componnent to stuck intermittently
    During the creation of a multi-machine or after the creation of a multi-machine, if you add a new component machine, sometimes this component machine gets stuck in InitializingRequest state and the only way to unblock it is to dispose the machine.

  • This issue has been resolved in this release.

  • Machine state does not change to Power Off or Expired State after the expiry date

    A multi-machine and its components gets deleted after the expiry date is reached. This issue has been resolved and the state of the machine is changed to Power Off or Expired State after the expiry date is reached.

    Hotfixes

    This section describes issues resolved in previously released hotfixes. All of the following resolved issues are included in this release.

    Hotfix 3

    • Error condition occurs with .NET workflow execution engine in the DEM workers causing a failure when attempting to load a workflow for execution. The failure is displayed through error System.Xaml.XamlObjectWriterException: Failed to create a 'PointCollection' from the text … System.ComponentModel.Win32Exception: Not enough storage is available to process this command. This error causes reduced performance in workflow execution including provisioning. After the error occurs, all the scheduled workflows is completed and the new workflows are not started in the corresponding DEM worker until you restart the DEM worker. A hotfix has been provided for this issue.

    Hotfix 2

    • Some AWS virtual machines are not deleted even after the expiry of the virtual machines. A hotfix has been provided for this issue.

    Hotfix 1

    • New machine request notifications are not sent out until the machine is cloned. The Email notification for the machine requested is sent from BuildingMachine activity during StartCreatingMachine in the core workflow. This machine request notification is sent only when the machine build starts and not immediately after the machine is requested. If external workflows starts before BuildingMachine activity, it further increased the delay for machine request notification. The Email behavior has been modified so that the machine request notifications are sent immediately when the machine is requested and also before approval request notification. Hence, if some component machines are rejected during approval, the final list of component machines is not same as listed in the machine requested Email. Also, a new notification, MachineBuildStarted, is added and it is sent before the machine build starts. A hotfix has been provided for this issue.

    Known Issues

    The following items are known issues in this release.

    The known issues are grouped as follows:

    Installation

    • Remote DEM worker service does not start after installation
      The default port for the vCloud Automation Center server is 443. If the vCloud Automation Center server is installed on a different port and the installation certificate for the DEM Worker does not specify the port where the vCloud Automation Center server is installed, the DEM worker does not start.

    • Workaround: Perform one of the following tasks:

      • Install the vCloud Automation Center server using the default port 443.
      • Install the vCloud Automation Center using a port that is different from the default, and install the certificate for the DEM Worker specifying that port.

    • vCloud Automation Center reports page displays an error in French Operating System
      After installing vCloud Automation Center in French Operating System, if you view the vCloud Automation Center reports page, an error message is displayed.

    Upgrade

    • Windows Preinstallation Environment (WinPE) does not support upgrade from vCloud Automation Center 5.2, 5.2.1, 5.2.2 to vCloud Automation Center 5.2.3
      Workaround: You must uninstall WinPE before upgrading to vCloud Automation Center 5.2.3. You must reinstall WinPE after the upgrade process is complete. See the "Rebuild WinPE Images," topic related to Upgrading to vCAC 5.2.3 in the vCloud Automation Center Installation Guide.

    Server Configuration

    • AppServiceState fails with a message: Not enough storage is available to process this command
      Error conditions might occur when the .NET workflow execution engine in DEM workers attempts to load a workflow for execution.
      Workaround: Three configuration properties provide a way to fine tune DEM workers to respond efficiently to workflow problems. A DEM worker can be configured to detect when an error condition occurs and to automatically restart so that the work does not stop. A DEM worker can be configured to wait a specified time period for running workflows to finish. Workflows still running when the timeout period ends are cancelled. A DEM worker can also be configured to unclaim a workflow if it fails and return the failed workflow to the DEM orchestrator queue. For this functionality to work, the following properties need to be configured in the DEM worker configuration file located at vcac_install_dir\VMware\vCAC\Distributed Execution Manager\%WorkerInstance%\DynamicOps.DEM.exe.config.

    • Name Display Name Description Value Format
      DEM.FailureExceptions Failure Exceptions The exceptions specified to trigger a DEM stop <add key="FailureExceptions" value="[ExceptiontypeName1]:[MaxFailureCount1]:[ShouldUnclaim1][;ExceptiontypeNameN]:[MaxFailureCountN]: [ShouldUnclaimN]"/>

      Where:

      ExceptiontypeName1. The name of the exception type seen in an error message. Cut and paste the exception type name here, for example, System.Xaml.XamlObjectWriterException. You can specify multiple exception type names. Valid value: Name of the exception type as it appears in the error message.

      MaxFailureCount1. The maximum number of times the exception occurs before the DEM stops. For each exception type name, you can specify a MaxFailureCount number. Valid value: A positive integer.

      (Optional) ShouldUnclaim1. Indicates whether the DEM returns the failed workflow to the queue for the next available DEM to execute. For each exception type name, you can enter a value for ShouldUnclaim. Valid values TRUE for the failed workflow to return to the queue, or FALSE for the failed workflow not to return to the queue. Valid values: TRUE or FALSE. The default value is FALSE.

      Example:
      <add key="FailureExceptions" value="System.Xaml.XamlObjectWriterException:1" />
      DEM.ClosedownTimeoutSeconds Closedown Timeout Seconds The number of seconds after a specified exception occurs before the DEM stops <add key="ClosedownTimeoutSeconds" value="[TimeoutInSecondsBeforeDEMClosesDown]"/>

      Where:

      TimeoutInSecondsBeforeDEMClosesDown is the number of seconds after the specified exception occurs before the DEM stops. Specify a time interval long enough to ensure that all running workflows are completed before the DEM stops. Valid values: A positive integer. The default value: 0.

      Example:
      <add key="ClosedownTimeoutSeconds" value="30" />
      DEM.RestartOnFailure Restart on Failure Trigger a full restart of the DEM <add key="RestartOnFailure" value="[WhetherToRestartDEMonFailure]"/>

      Where:

      (Optional) WhetherToRestartDEMonFailure specifies whether the DEM stops or performs a full restart when one of the exceptions specified in the FailureExceptions occurs. To specify a full restart, the DEM service account must have administrative privileges on the machine hosting the DEM. Specify TRUE for the DEM to perform a full restart. Specify FALSE for the DEM to stop. Valid values: TRUE or FALSE. The default value is TRUE.

      Example:
      <add key="RestartOnFailure" value="FALSE"/>

    Virtual Machine Management

    • Unable to dispose of a virtual machine that has pending work items after upgrade to vCloud Automation Center 5.2.3
      Upgrading to vCloud Automation Center 5.2.3 does not make it possible to dispose of previously undisposed virtual machines. Contact Customer Support for information about disposing these undisposed virtual machines manually.

    • Expire operation does not power off a vApp or virtual machine
      When you manually expire a vApp or virtual machine that has an archive period defined in vCloud Automation Center, vCloud Automation Center fails to destroy the machine. vCloud Automation Center reports that the machine has powered off, even though the machine is on.
      Workaround: Power off the vApp or virtual machine manually in your hypervisor to prevent errors during deletion, and manually delete the vApp or virtual machine in vCloud Director.

    • Virtual machines or vApps that fail the import process no longer appear in the import wizard
      When importing virtual machines or vApps into vCloud Automation Center are unsuccessful, the machines that are not imported no longer appear in the import wizard. As a result, you cannot attempt to re-import the machines or vApps.
      Workaround: Perform an inventory data collection of vSphere and vCloud Director, and then re-import the machines.

    • Problem results when a vApp with multiple component virtual machines fails to import one or more component machines
      If a vApp with multiple component virtual machines is imported into vCloud Automation Center, but the import process fails for one or more component machines, each virtual machine that failed the import process cannot be imported into vCloud Automation Center.

    • Destroy operation is unsuccessful in deleting multi-machine provisioned using multi-machine service
      The destroy operation in the vCloud Automation Center console to delete a multi-machine sometimes might not delete the multi-machine completely.
      Workaround: If clicking Destroy in the vCloud Automation Center console does not remove the multi-machine completely, click Destroy again.

    • vApp creation fails as vCloud Automation Center does not check for case sensitivity of the network name in the Custom Property
      vCloud Automation Center does not check for case sensitivity of the network name that you provide in Custom Property. As a result, vApp creation fails on vCloud Director and an error message is displayed in vCloud Automation Center.

    • Attempts to delete a vApp whose component machine is in reconfigure state results in vApp getting stuck in disposing state
      If you attempt to delete a vApp whose component machine is in reconfigure state, an error message is displayed and the vApp remains in disposing state and does not get disposed.
      Workaround: After all component vApps complete the operations that they were performing, click Destroy again. This removes the vApp component virtual machines and the vApp.

    • Cannot add a component machine to a multi-machine when there are IP addresses available in different network profile, but no available IP addresses in the network profile from which the IP addresses are allocated to multi-machine
      When a multi-machine is provisioned with IP addresses from a network profile, you cannot add a component machine after the IP addresses in the network profile are exhausted. Attempts to add a new component machine are unsuccessful even if another network profile has unallocated IP addresses.
      Attempting to add a new component machine in this situation generates an error message stating that all of the IP addresses in the network profile have been exhausted.