check-circle-line exclamation-circle-line close-line

vCloud Availability 3.5 | 14 NOV 2019 | Build 15038129

Check for additions and updates to these release notes.

What's in the Release Notes

The release notes cover the following topics:

What's New

vCloud Availability 3.5 introduces the following new features:

  • Integration with VMware vCloud Usage Meter to collect product consumption data and generate reports for the VMware Cloud Provider Program, see Add vCloud Availability in the vCloud Usage Meter documentation.
  • Support for multiple vCloud Availability instances per a vCloud Director instance. The service providers can control the accessible Provider VDCs in each vCloud Availability instance, see Cloud Deployment Architecture and Manage the Accessible Provider VDCs.
  • Cloud to cloud pairing is now possible over private networks, without allowing public administrative access and without providing the remote site credentials, see Pair Cloud Sites.
  • For on-premises to cloud replications, multiple virtual machines can be grouped and managed as a single unit, to specify boot order and boot delay settings, see Grouping VMs in a Replication.
  • Replication of additional vCloud Director settings: vApp networks, VM Guest OS Customization, and VM Guest properties, see Using Replications.
  • Traffic monitoring for each replication and each tenant; exporting of usage and traffic data, see Traffic Monitoring.
  • Datastore evacuation, vCloud Availability Replicator maintenance mode, and rebalancing replications, see vCloud Availability Maintenance.
  • Exclusion or inclusion of virtual machine hard drives in replications, see Selecting Replicated Disks.
  • Configuring the replications network settings in the target cloud site, see Configuring Network Settings of Replications to the Cloud.

Configuration Maximums

For the tested scale and concurrency limits, see VMware Configuration Maximums.

Upgrade

vCloud Availability 3.5 supports an in-place upgrade from vCloud Availability 3.0.x, see Upgrading vCloud Availability in the Cloud and Upgrading vCloud Availability On-Premises.

Caveats and Limitations

For interoperability between vCloud Availability and other VMware products, see VMware Product Interoperability Matrices

vCloud Availability 3.x can not pair with vCloud Availability for Cloud-to-Cloud DR 1.5.x and vCloud Availability for vCloud Director 2.x. You can migrate the protected workloads from vCloud Availability for vCloud Director 2.x to vCloud Availability 3.x, see Migrate from vCloud Availability for vCloud Director 2.0.

Note: The vCloud Availability vSphere Client Plug-In requires vSphere Client support. Use the vCloud Availability Portal if your vSphere does not support vSphere Client.

Supported Browsers

vCloud Availability 3.5 supports the following browsers:

  • Google Chrome 78 and later
  • Mozilla Firefox 69 and later
  • Microsoft Edge 44 and later
  • Safari 13 and later

Known Issues

  • The vCloud Availability vSphere Client Plug-In displays a 503 Service Unavailable screen if the browser session remains idle

    After you perform an operation by using the vSphere Client Plug-In and leave the browser session idle for a longer time, usually more than 30 minutes, the vSphere Client Plug-In times out and returns a 503 Service Unavailable error.

    Workaround: If you log out and log back into the vSphere Web Client the error persists. To renew the vSphere Client Plug-In session, wait for several minutes and refresh the browser. 

  • After the cloud site is upgraded, on-premises tenants running vCloud Availability 3.0.x cannot use the vCloud Availability vSphere Client Plug-In

    When on-premises tenants running vCloud Availability 3.0.x are paired with a cloud site running vCloud Availability 3.5, the attempt to use the vCloud Availability vSphere Client Plug-In results in an  Operation aborted due to an unexpected error.

    Workaround: 

    • Upgrade all on-premises tenants to vCloud Availability 3.5.
    • Alternatively, in the cloud site you can add the following property to the vCloud Availability Cloud Replication Management Appliance:
    1. Open an SSH connection to the Appliance-IP-Address and authenticate as the root user.
    2. In the /opt/vmware/h4/cloud/config/application.properties file, add api.strict.deserialization = false.
    3. Restart the service systemctl restart cloud.service.
  • When selecting virtual machines to group in a vApp, advancing the pagination list clears the selection

    In the inventory list of virtual machines, if you select virtual machines from another page to group in a vApp, the selected virtual machines on previous pages are deselected.

    Workaround: Select to display more items per page and select virtual machines from the same inventory list page.

  • Deselecting a disk for replication removes the disk from the interface

    If you deselect a disk from a replication, you can no longer select this disc as it is removed from the user interface.

    Workaround: None.

  • Test failover intermittently fails, leaving a pending vApp in vCloud Director

    Performing a test failover might not fail over all virtual machines successfully.

    When virtual machine operations fail, the resulting vApp is not cleaned from vCloud Director. This results in inability to import the corresponding virtual machines.

    Workaround:

    • Execute test cleanup.
    • Manually remove any pending vApps in vCloud Director.
    • If you cannot delete the target vApps, change the vApp name in the replication.
  • Cannot use Configure Protection or Configure Migration in vSphere Client 6.7 Update 1

    In vSphere Client 6.7 Update 1, when browsing the inventory of the virtual machines, if you right-click and select Configure Protection or select Configure Migration, the corresponding wizards do not open.

    Workaround: To configure virtual machine protection or migration, use the vCloud Availability vSphere Client Plug-in or the vCloud Availability Portal.

  • The service management interface keeps showing 127.0.0.53 as the DNS server even after modification

    After you modify the DNS servers in the service management interface of the vCloud Availability appliance, the Preferred DNS Server text box always shows the placeholder value of 127.0.0.53 and the Alternate DNS Server text box always shows as not configured. This is a user interface issue and it does not affect the DNS resolution.

    Workaround: When you modify the network settings, always make sure to delete 127.0.0.53 from the Preferred DNS Server text box first. Then enter the correct IP address of your DNS server.

    To verify that the DNS configuration is correct, open an SSH session to the appliance and check the DNS entries in the /etc/systemd/resolved.conf file.
    The DNS servers are listed under Resolve. For example:
    [Resolve]

    DNS = 1.1.1.1 1.0.0.1

    If you modify the configuration, after saving the file, to apply the changes run the following command:

    systemctl restart systemd-resolved

    To verify the DNS settings, run the following command and check the output:

    resolvectl dns

    Global: 1.1.1.1 1.0.0.1

  • Cannot modify the domain name by using the service management interface

    In the Network Settings window, entering a domain name adds it to the Domain Search Path instead.

    Workaround: None.

  • Cannot monitor the traffic of vCloud Availability 3.0.x instances

    In vCloud Availability 3.5, when you click the Traffic tab for replications to vCloud Availability 3.0.x sites, you see a Permission denied error message.

    Workaround: None.

  • Cannot protect or migrate virtual machines or vApps that are incompatible with the destination hardware version

    When migrating or failing over a virtual machine with a hardware version that is incompatible with the ESXi host at the destination site, the vCloud Availability task completes successfully but you cannot power-on the virtual machine at the destination site. For example, at the destination site, after a failover from an on-premises site with vCenter Server 6.7 to a cloud site with vCenter Server 6.0, you cannot start a virtual machine with hardware version 13. For more information on the virtual machine compatibility, see Virtual Machine Compatibility in vSphere Virtual Machine Administration.

    Workaround: Move the virtual machine or vApp to a destination that supports the required hardware version:

    • for a vCloud Director destination, move to an Org VDC that is configured with the compatible hardware version.
    • for a vCenter Server destination, move to a cluster with a hardware version that is equal or higher than the source virtual machine.
  • Seed with excluded disks cannot be used for a new vApp or virtual machine replication

    If you attempt to use an existing seed that has some disks excluded to start a new replication fails with an error message, such as Disks of provided seed VM don't match the disks of the source VM.

    Workaround: None.

  • For on-premises to cloud replications, configuring the network settings of a virtual machine also causes a change in its computer name

    In an on-premises to cloud replication, you can configure the destination network settings of the virtual machine. At the destination cloud site, in addition to applying the network settings, the computer name in the operating system of the virtual machine gets incorrectly changed to xxxxxxx-01, where xxxxxxx is the original computer name. As a result of this computer name change, Windows virtual machines can disjoin from the domain controller.

    Workaround: To prevent vCloud Availability from changing the computer name, set the network settings of on-premises to cloud replications in vCloud Director. If the computer name of a virtual machine changes after a failover or a migration, correct the computer name in vCloud Director.

  • Cannot group virtual machines from on-premises sites running vCloud Availability 3.5.x to cloud sites running vCloud Availability 3.0.x

    In a replication from a vCloud Availability 3.5.x on-premises site to a vCloud Availability 3.0.x cloud site, if you select to group virtual machines in a vApp, on the Ready To Complete page, you see The server responded with an error, but we're unable to create a proper exception. Error code: BadRequest Arguments: [] and you cannot group the virtual machines.

    Workaround: None.