vCloud Availability 3.5.1 | 20 FEB 2020 | Build 15669152
Check for additions and updates to these release notes.
What's in the Release NotesThe release notes cover the following topics:
With vCloud Availability 3.5.1, you can set a global limit for the total incoming traffic from all sites. Throttling the network bandwidth used by vCloud Availability avoids the network saturation and overloading the management connections with the replication traffic that shares the network infrastructure. For more information, see Bandwith Throttling.
vCloud Availability 3.5.1 also includes several resolved issues and updates of third-party libraries that provide security fixes.
You can perform an in-place upgrade directly to vCloud Availability 3.5.1 from vCloud Availability 3.0.5 or from vCloud Availability 3.5.0.
- 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.
- 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.
- Deselecting a disk from a replication results in removing the disk from the user interface
If you deselect a disk from a replication, you can no longer select this disc as it is removed from the user interface.
- Cannot monitor the traffic of vCloud Availability 3.0.x instances
When you click the Traffic tab for replications to vCloud Availability 3.0.x sites, you see a
Permission deniederror message.
- 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.
- Replication seed with excluded disks cannot be used for a new replication
If you attempt to use an existing seed that has some disks excluded to start a new vApp or virtual machine replication fails with an error message, such as
Disks of provided seed VM don't match the disks of the source VM.
- 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.
- Cannot exclude disks from a replication started with a replication seed
If you attempt to exclude any of the disks from an existing vApp or virtual machine replication that is configured with a replication seed, subsequent replication syncs time out.
- Reverse failover and reverse test failover fail for cloud to cloud replications when the name of the vApp or the virtual machine contains spaces and VMware Cloud Director version is 10.1 or later
In a cloud site with VMware Cloud Director 10.1 or later, attempting reverse replication operations on a vApp or a virtual machine with a name containing spaces fails with the
The VMware Cloud Director entity vapp-name (1) already existserror message.
Workaround: Before performing a reverse failover or a reverse test failover, change the name of the vApp or virtual machine.