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 NotesThe release notes cover the following topics:
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.
VMware Cloud Director Availability 4.0.1 supports an in-place upgrade from VMware Cloud Director Availability 4.0, 18.104.22.168, or 22.214.171.124.
To upgrade from vCloud Availability 3.x, first upgrade to VMware Cloud Director Availability 126.96.36.199. 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.
- 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 Modeerror message.
- 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 188.8.131.52 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.
1. Open an SSH connection to the
Appliance-IP-Addressand 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
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