check-circle-line exclamation-circle-line close-line

VMware vCloud Availability for Cloud-to-Cloud DR 1.0 Release Notes

vCloud Availability for Cloud-to-Cloud DR 1.0 | 17 MAY 2018 | Build 8497611

Check for additions and updates to these release notes.

What's in the Release Notes

The release notes cover the following topics:

About vCloud Availability for Cloud-to-Cloud DR

The vCloud Availability Cloud-to-Cloud DR solution provides replication and failover capabilities for vCloud Director workloads at both VM and vApp level and includes the following features:

  • Replicate and recover vApps between two vCloud Director instances for migration, disaster recovery, and planned maintenance use cases.
  • Fully self-served tenant operations for tenant driven disaster recovery and service provider driven workflows for a managed service offering.
  • Symmetric architecture with ability to perform all disaster recovery operations from both local and remote sites. 
  • Support for vCenter Server versions 6.5 U1 and 6.0 U3, and vCloud Director versions 8.20.X, 9.0.X, and 9.1.
  • Single, unified portal for both tenant and service provider users.

Interoperability

vCloud Availability for Cloud-to-Cloud DR interoperability is the same for tenant and service provider users.

VMware products interoperability information is published under the vCloud Availability for Cloud-to-Cloud DR product in the VMware Product Interoperability Matrices.

  1. Go to the VMware Product Interoperability Matrices.
  2. From the Select a Solution menu, select vCloud Availability for Cloud-to-Cloud DR.
  3. Select a Version.
  4. From the Add Platform/Solution select VMware vCloud Director for Service Providers.
  5. Click Add Another Solution.
  6. Repeat steps 4 and 5, selecting VMware vCenter Server and VMware vSphere Hypervisor (ESXi).

VMware NSX for vSphere

The interoperability between vCloud Availability for Cloud-to-Cloud DR and NSX depends on the interoperability between vCloud Availability for Cloud-to-Cloud DR and vCloud Director for Service Providers.

vCloud Availability for Cloud-to-Cloud DR supports all NSX versions that are interoperable with a supported vCloud Director for Service Providers version.

For NSX interoperability details, look up the interoperable vCloud Director for Service Providers versions and then look up the interoperable NSX versions for each supported vCloud Director for Service Providers version.

Operational Limits

The following operational limits are discovered through rigorous testing of different disaster recovery scenarios.

 Scale Limits

Concurrency Limits

  • 60 concurrent Protect, Test Failover, Reverse Protect, Test Failback, and Failback operations
  • 110 Concurrent Failover operations

Coexistence 

vCloud Availability for Cloud-to-Cloud DR 1.0 and vCloud Availability for vCloud Director 2.X can be installed and can operate together in the same vCloud Director environment. You can protect VMs either by using the vCloud Availability for Cloud-to-Cloud DR 1.0 solution or the vCloud Availability for vCloud Director 2.X.

Supported Browsers

The vCloud Availability Portal and the vCloud Configuration Portal are tested against the following Web browser versions. You can use older versions.

Windows 10​

  • Google Chrome 65.0.3325.181 (Official Build) (64-bit)
  • Mozilla Firefox 59.0.2 (64-bit)
  • Microsoft Internet Explorer 11.248.16299.0*
  • Microsoft Edge 41.16299.248.0

macOS Sierra 10.12.6​

  • Google Chrome 65.0.3325.181 (Official Build) (64-bit)
  • Safari 11.1 (12605.1.33.1.3)
  • Mozilla Firefox 59.0.2 (64-bit)

CentOS 7.3

  • Google Chrome 63.0.3239.132 (Official Build) (64-bit)
  • Mozilla Firefox 59.0.2 (64-bit)

*NOTE: vCloud Configuration Portal does not support Microsoft Internet Explorer. To work with the vCloud Configuration Portal, use another supported Web browser.

Product Documentation

In addition to the current release notes, you can use the vCloud Availability for Cloud-to-Cloud DR documentation set at https://docs.vmware.com/en/VMware-vCloud-Availability-for-Cloud-to-Cloud-DR/index.html.

Known Issues

  • You cannot see some of the previously received notifications in the vCloud Availability Portal

    Notifications are cleaned up from the vCloud Availability Portal when you log out of the system.

    vCloud Availability Portal stores only the historical operation tasks for vApps and VMs available in the Tasks page of the vCloud Availability Portal.

    The system does not store other notifications, such as but not limited to Component Health notifications.

    A vCloud Director System Administrator can find more information about the performed operations and system activities in the /opt/vmware/h4/cloud/log/cloud.log file.

    Workaround: None.

  • The vApp replication timestamp is not updated when the automatic Delta sync starts.

    Workaround:  You can monitor the RPO violations to detect problems with Delta synchronizations.

  • Powering on VMs with duplicated MAC addresses fails with no error message in the vCloud Availability Portal

    When you perform failover, test failover, failback, or test failback, a new vApp with VMs is created in vCloud Director. If a VM with the same MAC address is present in vCloud Director and both VMs have direct connectivity, the newly imported VM is not powered on, and no notification is generated.

    A vCloud Director System Administrator can find an error message in the /opt/vmware/h4/cloud/log/cloud.log file and in the vCloud Director Tenant Portal.

    Workaround: You can use the vCloud Director Fence vApp option to use same MAC or IP. Fencing allows identical VMs in different vApps to be powered on without conflicts.

  • You cannot deploy vCloud Availability for Cloud-to-Cloud DR using IPv6 IP addresses

    When deploying vCloud Availability for Cloud-to-Cloud DR appliances, selecting to use IPv6 protocol in the Select Networks pane takes no effect in assigning an IPv6 IP address to the appliance. 

    Workaround:  To work around this issue, do the following:

    1. In the Management interface of the affected appliance, navigate to the Network tab.
    2. Select Address.
    3. Expand the NIC that you are configuring.
    4. Select one of the possible networking configurations of the adapter.
      Note: vCenter Server and vCloud Director use IPv6.
    5. Click Save.
  • When you register a new vCloud Availability Replicator to a vCloud Availability Replication Manager, if you enter an incorrect SSO username or password, the registration completes with the following message:

    Replicator is paired successfully.

    Although the system confirms the registration process is successfully completed, you cannot use this vCloud Availability Replicator to perform vCloud Availability for Cloud-to-Cloud DR operations.

    Workaround: Remove and re-register the vCloud Availability Replicator by entering correct SSO username and password during the registration process.

  • You cannot register vCloud Director to vCloud Availability for Cloud-to-Cloud DR by using the IP address of the vCloud Director instance.

    Registering a vCloud Director instance to vCloud Availability for Cloud-to-Cloud DR by using an IP address instead of a host name fails with a Hostname verification failed error message.

    Workaround: To work around this issue follow the steps below: 

    1. Log in to the vCloud Availability vApp Replication Service/Manager appliance over SSH as root.
    2. Open the /opt/vmware/h4/cloud/config/application.properties file with a text editor.
    3. Change the value for the vcd.hostnameverifier.noop to false and save the file.
    4. Restart the vCloud Availability vApp Replication Service/Manager service.
  • Authentication to vCloud Availability vApp Replication Manager by using single sign-on domain administrator credentials is not supported for Organization Administrators.

    Workaround: Use local tenant user credentials to authenticate to vCloud Availability vApp Replication Manager instead of Organization Administrators credentials.

  • Moving protected VMs between vApps is not supported

    You cannot move protected VMs between vApps. After a VM is moved to another vApp, the VM replication gets corrupted. Any subsequent DR operation for the same VM might fail.

    Workaround: To move a protected VM to another vApp, you must first stop the replication for the source vApp, then move the VM to another vApp, and then protect or re-protect the new vApp.

  • Reversing a VM or a vApp replication in a protected vApp powers off the source protected vApp.

    In a protected vApp that contains multiple virtual machines, reversing a particular virtual machine replication undeploys the source vApp and powers off the virtual machines it contains. 

    Workaround: After the reverse operation finishes, power on the virtual machines manually from the vCloud Director Web Console. 

  • Reverse and failback operations fail for virtual machines with multiple disks configured to use different storage profiles.

    You cannot reverse or fail back to a virtual machine if its .vmdk files are on different data stores and are configured to use different storage profiles.

    Workaround: Move all .vmdk files of the VM to the data store where the machine is installed and apply the same storage profile to all of them. 

  • A failover with synchronization operation fails for replications that are in paused or a partially paused state.

    This is the designed system behavior. 

    Workaround: You can ignore this task error or resume the replication, to perform a Failover with Resync (migrate) operation.

  • vCloud Availability for Cloud-to-Cloud DR services crash and restart automatically.

    If an ESXi host cannot allocate a sufficient amount of RAM to vCloud Availability for Cloud-to-Cloud DR appliances, vCloud Availability for Cloud-to-Cloud DR services crash and restart automatically every 30 seconds.

    This issue affects the following services:

    • vCloud Availability Replication Manager
    • vCloud Availability Replicator
    • vCloud Availability vApp Replication Manager
    • Lightweight Data Protocol Service (LWD Proxy)
    • vCloud Availability Tunnel

    Possible cause of the issue is that a host memory balloon occurs when a virtual machine requires more RAM than an ESXi host can allocate. To make sure you are affected by a host memory balloon issue, open an SSH session to the affected appliance and run the following command:
    $ vmware-toolbox-cmd stat balloon

    The command returns a value in MB that represents the amount of RAM that an ESXi cannot allocate to the affected appliance.

    Workaround: To work around this issue, allocate more RAM to the ESXi host, or stop the unused virtual machines on the host to free resources.

  • Failover and Failback operations might fail with the following error message:

    The requested resource was not found

    If you change the storage profile of a source VM, failover and failback operations are not possible.

    Workaround: Even if the failover or failback operation fails, if there is an earlier snapshot available, you can perform a failover or a failback operation to the VM.

  • Protect operation may fail with the following error message:

    The operation could not be completed, because the virtual machine has an active replication enabled.

    If you change the storage profile of a source VM after a replication for the same VM is started, and detach the same replication, any subsequent Protect operation for the same VM fails.

    Workaround: To work around this issue, disable the replication for the affected VM by using ESXi CLI and protect the VM again by using the vCloud Availability Portal:

    1. Open an SSH session to the ESXi host
    2. To retrieve the ID of the affected VM, run the following command:
      $ vim-cmd vmsvc/getallvms
      The system returns details for all VMs that are hosted on the ESXi. Note the VM ID of the affected VM.
    3. To disable the replication, run the following command:
      $ vim-cmd hbrsvc/vmreplica.disable VM-ID
    4. After the replication is disabled, you can protect the affected VM by using the vCloud Availability Portal. For more information, see Protect vApps topic in the vCloud Availability for Cloud-to-Cloud DR User's Guide.
  • Failover and a subsequent Failover Retry operations might fail with the following error

    Operation aborted due to an unexpected error.

    If auto discovery of VMs is enabled in vCloud Director, a race condition may occur causing a VM to be imported into vCloud Director using the auto-import vCloud Director logic instead of using the vCloud Availability vApp Replication Service/Manager logic. 

    Workaround: To work around this issue, stop any active replications for the affected vApp and move the troublesome VM to a vApp that is created by the vCloud Availability vApp Replication Service/Manager appliance by using the vCloud Director user interface.

  • If a Sync operation is in progress, tenant users cannot power on a protected VM 

    VM disks are locked during Sync operations for VMs that are powered off. Locked disks prevent tenant users from powering on VMs until the Sync operation completes.

    Workaround: None. To avoid being affected by this issue, power the VM on before you initiate a Sync operation.

  • Test recovery tasks from a source vCloud Director instance to a vCloud Director 9.1 instance fail when Make Allocation pool Org VDCs elastic is enabled.

    If your VDC is configured with an elastic allocation pool and each cluster in the VDC is configured to use a dedicated storage, any test failover for an existing replication fails with the following error:

    An elastic vDC is used but the primary resource pool does not have access to the datastore that holds the replica files.

    Workaround: Configure a storage profile that includes only data stores that are visible to the primary cluster and use this profile for replications.

  • After you successfully configure replications by using the vCloud Availability for Cloud-to-Cloud DR 1.0 solution, you observe Recovery Point Objective (RPO) violations. The following tasks appears in the vSphere Web Client of your backing vCenter Server instance:

    Task Name : Disable replication of virtual machineInitiater Name --> com.vmware.vcHms 

    When you configure replications by using the vCloud Availability for Cloud-to-Cloud DR 1.0 solution to or from a backing vCenter Server with either a standalone vSphere Replication earlier than 6.5 or vCloud Availability for vCloud Director 1.x, vSphere Replication disables these replications. 

    vSphere Replication versions earlier than 6.5 browse all replications that exist in the source vCenter Server instance and disables any replication that is not available in its database.

    Workaround: To work around this issue, you have the following options:

    • Upgrade your standalone vSphere Replication instance to version 6.5 or upgrade your vCloud Availability for vCloud Director solution to version 2.0.x.
    • Use a different vCenter Server instance for your vCloud Availability for Cloud-to-Cloud DR environment.
    • Use a different vCenter Server instance for your standalone vSphere Replication instance prior version 6.5 or for your vCloud Availability for vCloud Director 1.x solution.
  • When you log in to the vCloud Availability for Cloud-to-Cloud DR portal with vCloud Director tenant Organization administrator credentials, you can see virtual machines and vApps that belong to other vCloud Director Organizations

    If there is a network issue between your local site and remote site, vCloud Director tenant Organization administrators may temporarily see virtual machines and vApps that belong to another vCloud Director Organization.

    Workaround: None