VMware Cloud Director Availability™ 4.0.1 | 16 JUL 2020 | Build 16570069

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

VMware Cloud Director Availability 4.0.1 provides cloud side support for NSX-T 3.0 with Cloud Director 10.1.1. This release also includes several resolved issues and updates of third-party libraries that provide security fixes.

What's new in VMware Cloud Director Availability 4.0, see the VMware Cloud Director Availability 4.0 Release Notes document.

Upgrade

VMware Cloud Director Availability 4.0.1 supports an in-place upgrade from VMware Cloud Director Availability 4.0, 4.0.0.1, or 4.0.0.2. 

To upgrade from vCloud Availability 3.x, first upgrade to VMware Cloud Director Availability 4.0.0.2. Then you can upgrade to version 4.0.1.

Upgrading to VMware Cloud Director 4.0.1

Current Version 3.x

Current Version 4.0
Upgrading in the Cloud Site

Upgrade to VMware Cloud Director 4.0 first, by following the legacy Upgrading to 4.0 the Cloud procedures.

Upgrade to VMware Cloud Director 4.0.1 by following the updated Upgrading in the Cloud procedures.
Upgrading in the On-Premises Site Upgrade to VMware Cloud Director 4.0 first, by following the legacy Upgrading to 4.0 On-Premises procedures.  Upgrade to VMware Cloud Director 4.0.1 by following the updated Upgrading On-Premises procedures.

Note: Upgrade the on-premises appliance either by using the management interface or by using the command-line. Attempting to upgrade the on-premises appliance from version 4.0 by using the vSphere Client plug-in, fails with a Permission denied error message.

Resolved Issues

  • Cannot manage the accessible provider VDCs after deleting an enabled provider VDC

    After you delete a provider VDC, that is enabled for access, you cannot manage the accessible provider VDCs.

  • With a selected SLA profile, reversing a cloud to cloud replication, or reprotecting a reversed replication, results in a replication with custom SLA settings and the replication fails if the custom SLA settings are not allowed

    When you perform a reverse task on a replication that is configured with an SLA profile, the resulting replication in the source organization contains custom SLA settings, instead of the selected SLA profile. If Allow custom SLA settings is deselected for the source organization, the reversed replication fails with the error message Replication with custom SLA settings can not be configured because it violates policy "sample policy" configured at site "sample site"

    Similarly, for reprotect configured with an SLA profile, the replication in the destination organization contains custom SLA settings. If Allow custom SLA settings is deselected for the destination organization, the reversed replication fails with the same error message.

  • Failover and test failover fail when in the network settings Connected is deselected, for IP Mode None is selected, and Cloud Director 10.1.1 is running in the destination cloud site

    When Cloud Director 10.1.1 is running in the destination cloud site, and in the network settings for a NIC of a virtual machine in a vApp you deselect Connected and select None for IP Mode, attempting a failover or a test failover fails with the Invalid network parameter: Unknown IP Addressing Mode error message.

Known Issues

  • Cannot deploy the on-premises appliance OVA in vSphere 7.0

    In vSphere 7.0 in the Deploy OVF Template wizard, when you attempt to deploy the 4.0.1 on-premises OVA, in the Select a compute resource page, you see the following error message The provided certificate file is invalid: ...

    Workaround: Deploy the on-premises appliance by using the 4.0.1.1 OVA file.

  • Manually configured static routes do not route the network traffic as expected

    In the management interface or in the command-line interface, you see the manually configured static routes, while they do not route the network traffic as expected.

    Workaround:

    1. Open an SSH connection to the Appliance-IP-Address and authenticate as the root user.

    2. Verify that the routing table is not updated.

    /usr/sbin/ip route show

    3. For each network adapter, create a symlink.

    /usr/bin/ln -s /lib/systemd/network/ens160.network.d /lib/systemd/network/10-ens160.network.d

    For example, ens160.network.d -> 10-ens160.network.d

    4. After creating all symlinks, restart the network service.

    /usr/bin/systemctl restart systemd-networkd

    5. Verify that the routing table is updated.

    /usr/sbin/ip route show

check-circle-line exclamation-circle-line close-line
Scroll to top icon