vCloud Availability 3.5 | 14 NOV 2019 | Build 15038129
Check for additions and updates to these release notes.
What's in the Release NotesThe release notes cover the following topics:
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.
For the tested scale and concurrency limits, see VMware Configuration Maximums.
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.
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
- 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 Unavailableerror.
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.
- 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-Addressand authenticate as the root user.
2. In the
/opt/vmware/h4/cloud/config/application.propertiesfile, add the following property.
api.strict.deserialization = false
3. Restart the service.
systemctl restart cloud
- 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.
- 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.
- Perform a 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
The DNS servers are listed under
Resolve. For example:
DNS = 188.8.131.52 184.108.40.206
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:
Global: 220.127.116.11 18.104.22.168
- 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.
- 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 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 replication 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.
- 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.
- To prevent this issue, first disable the respective provider VDC(s) in Accessible Provider VDCs in the vCloud Availability management interface. Then you can proceed to remove the provider VDC(s) from vCloud Director.
- If the provider VDC is already deleted, edit the following property in the vCloud Availability Cloud Replication Management Appliance.
1. Open an SSH connection to the Cloud Replication Management Appliance and authenticate as the root user.
/opt/vmware/h4/cloud/config/application.propertiesfile, remove the deleted provider VDC from the pvdc.filter property.
3. Restart the service.
systemctl restart cloud