VMware Cloud Director Availability 4.6.1 Release Notes

VMware Cloud Director Availability 4.6.1 | 31 AUG 2023 | Build 22347688 (Product version: 4.6.1.7681624-a5359f8567) Check for additions and updates to these release notes.

What's new

VMware Cloud Director Availability 4.6.1 includes important resolved issues and third-party libraries.

In Cloud Director sites, as a provider or as a tenant you can now register a Simple Mail Transfer Protocol (SMTP) server directly in VMware Cloud Director Availability and Set custom SMTP settings as an alternative of Configure in Cloud Director. For more information, see Events and notifications.relative

Upgrade

VMware Cloud Director Availability 4.6.1 supports an in-place upgrade directly from versions :

• 4.4.x, 4.5.x, or 4.6.0 in Cloud Director sites. To upgrade to version 4.6.1 from earlier versions, first upgrade to either version 4.4.x, or 4.5.x.

• 4.5.x or 4.6.0 in vSphere DR and migration sites. To upgrade to version 4.6.1 from version 4.4.x, first upgrade to version 4.5.x.

For information about the upgrade process, see Upgrading in the Cloud Director site and Upgrading on-premises and provider site.

Configuration maximums

For information about the tested and verified uptime, concurrency, and scale limits, see VMware Configuration Maximums.

Caveats and limitations

For replications using the Classic data engine, VMware Cloud Director Availability 4.6.1 uses vSphere Replication module called Host-based Replication (HBR) version 8.7.0.3. For more information, see under the vSphere Replication 8.7 Release Notes.

Resolved issues

The following issues have been resolved in this release.

• In Cloud Director sites with dual Tunnel appliances, the administrative sessions access cannot be restricted

  When using two Tunnel Appliance instances in an active-active mode, if Security settings > Restrict Admin APIs by source IP is set to Allow admin access from anywhere, the restriction would not apply.

• Test cleanup cannot delete the test virtual machine due to any failing task of that virtual machine

  After performing a test failover, in case any task of the destination virtual machine fails, it leaves the virtual machine in an inconsistent state as the Test Cleanup task cannot delete it, showing the error message: failed to delete failover test VM: <vmid>

  For example, this issue can be caused by attempting to manually power on the test virtual machine while the destination environment does not allow it.

• Applying the Recovery Settings for replicated virtual machines with no consecutive indexes fails when selecting networks

  For a virtual machine with two network adapters, by deleting the first one, the second network adapter keeps its index, for example, NIC 2.

  After configuring such virtual machine for replication, clicking its All actions > Recovery Settings and selecting a network for the first network adapter, displayed as NIC 1 does not apply the selected network.

• RPO interval filtering in VM perspective status tab ignores the max value with no min value entered

  By not entering a minimum value, the RPO interval filtering in the VM perspective status tab does not respect the maximum value.

Known issues

The following known issues are currently identified in this release.

• New - When using the default online repository, upgrading VMware Cloud Director Availability might fail

  The default online repository of VMware Cloud Director Availability changed to https://packages-prod.broadcom.com/vcav/. When VMware Cloud Director Availability tries to access the legacy repository, the upgrade process might fail. 

  Workaround: Perform one of the following tasks.

  • When upgrading in an on-premises and provider site, upgrade by using a specified repository.

  • When upgrading in a Cloud Director site, upgrade by using a specified repository. 

• For vSphere DR and migration, attempting to repair the Replicator instances fails after upgrading to 4.6.1

  In vSphere DR and migration sites only, once upgraded to 4.6.1, you cannot repair the Replicator Service, for example, after changing an SSL certificate, or after changing the SSO credentials of the vCenter Server Lookup Service. 

  Workaround:

  1. Open an SSH session to the local appliances in the site and log in by using the root user credentials.

  2. On the vCenter Replication Management Appliance and all the Replicator Appliance instances, or the On-Premises to Cloud vCenter Replication Appliance, edit the application.properties files and set the value of admin.allow.from to "admin.allow.from=0.0.0.0/0".

  3. For the changes to propagate, restart the services in the following order :

     1. Restart the Manager Service.

     2. Restart all Replicator Service instances, local or dedicated.

  4. Repair the local Replicator Service, or repair all dedicated Replicator Appliance instances, if using any.

  5. Revert the changes on the vCenter Replication Management Appliance or the On-Premises to Cloud vCenter Replication Appliance, by setting the admin.allow.from back to an empty value: admin.allow.from=