VMware vCloud Availability for vCloud Director 2.0 Release Notes

|

VMware vCloud Availability for vCloud Director 2.0 | 19 OCT 2017 | Build 6918495

Check for additions and updates to these release notes.

What's in the Release Notes

These release notes cover the following topics:

What's New

vCloud Availability 2.0 delivers the following key enhancements: 

  • vSphere 6.5 Support: Added support for vSphere 6.5 on the service provider side. The supported vSphere versions on the tenant side remain unchanged. For more interoperability and compatibility information about vCloud Availability, see the Interoperability Pages for vCloud Availability for vCloud Director 2.0.

  • 5-minutes Recovery Point Objective (RPO): vCloud Availability 2.0 delivers an enhanced RPO support of 5-minutes compared to the previously supported RPO of 15 minutes.

  • Enhancements to vCloud Availability Administration Portal: The vCloud Availability Administration Portal, introduced in the vCloud Availability for vCloud Director 1.0.1.2 release, allows service providers to monitor and manage their DR environments. The current release includes usability and performance enhancements to improve the response time on the Inventory page and a new Tenant Impersonation feature. The new feature allows service providers to act as tenant users. Using the Tenant Impersonation feature, service providers can filter tenant organizations and perform DR operations using a tenant role, the same way a tenant user would.

  • Installer Simplification: Service providers can now install vCloud Availability using one single command with an all-in-one appliance. All the vCloud Availability components are now bundled into a single appliance to simplify the installation process.

  • Seamless upgrade: You can now upgrade to vCloud Availability 2.0 from 1.X versions with no impact to protected virtual machines and existing replications. For more information, see the vCloud Availability for vCloud Director 2.0 Upgrade Guide.

Supported Browsers

The vCloud Availability Portal 2.0 is tested against the following Web browser versions. You can use older versions.

Windows 10

  • Microsoft Internet Explorer 11.608.15063.0
  • Microsoft EdgeHTML 15.15063
  • Mozilla Firefox 55.0.3 (64-bit)
  • Google Chrome 61.0.3163.79

OS X Yosemite 10.10.5

  • Mozilla Firefox 55.0.3
  • Google Chrome 61.0.3163.79

CentOS 7

  • Mozilla Firefox 55.0.3
  • Google Chrome 61.0.3163.79

 

The vCloud Availability Administration Portal 2.0 is tested against the following Web browser versions. You can use older versions.

Windows 10

  • Microsoft EdgeHTML 15.15063
  • Mozilla Firefox 55.0.3 (64-bit)
  • Google Chrome 61.0.3163.79

OS X Yosemite 10.10.5

  • Mozilla Firefox 55.0.3
  • Google Chrome 61.0.3163.79

CentOS 7

  • Mozilla Firefox 55.0.3
  • Google Chrome 61.0.3163.79

Product Documentation

In addition to the current release notes, you can use the documentation set for vCloud Availability 2.0 that includes the following deliverables.

Resolved Issues

The following issues have been fixed in this release.
  • The vCloud Availability Portal home page takes too long to load when one or more vSphere Replication Servers are offline

    This issue is fixed.

  • Replicated VMs have guest customization enabled if the target vCloud Director is version 9.0

    As a result, such VMs receive a new identity when they are powered on. You may observe this behavior for Windows versions, for which the cloud system administrator has not provided appropriate Microsoft Sysprep files.
    This issue is fixed with vCloud Director version 9.0.0.1.

  • The vCloud Availability Portal may experience slow initialization on login when multiple tenant accounts access the portal simultaneously

    This issue is fixed.

     

Known Issues

The following known issues have been discovered through rigorous testing and will help you understand some behavior you might encounter in this release.

The known issues are grouped as follows.

Installation and Configuration
  • Installation fails with the following error message

    Cassandra cass.0 () took too long to start after importing the certificate for HCS hcs.1 ()

    The Cassandra server takes too long to become available on the network. Possible reason for the issue is a Cassandra cluster initialization.

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

    • For manual deployment, run the same command again. 
    • For automated deployment, run vcav resume.
  • Configuring a vSphere Replication Server fails with the following error message

    The VR server for HBR-address is not connected

    The cause for this issue is that previously configured instances of vSphere Replication Server are not properly removed.

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

    1. Run the vcav hbr list --vcd=vCD-Registry-Name command.
    2. Identify all vSphere Replication Server instances that use the same address as the vSphere Replication Server that you are trying to configure.
    3. Unregister all conflicting entries by running the vcav hbr unregister --vcd=vCD-Registry-Name --hbr-uuid=UUID-of-the-conflicting-entry command.
    4. Attempt to configure the vSphere Replication Server again.
  • If multiple network profiles are configured in vSphere, deploying vCloud Availability components may fail

    When deploying a vCloud Availability component, if the first network profile for the IP that will be assigned does not have all parameters specified, the vcav script returns the following error:

    The IP Pool Network-Profile-Name definition in DC-Name for IP-Address does not have any DNS servers

    The script does not attempt to use other network profiles.

    Workaround: To work around this issue, update а network profile for the IP to include a DNS server and try to deploy vCloud Availability for vCloud Director components again. 

vCloud Availability for vCloud Director Administration Portal
  • You cannot perform a storage migration to a cluster datastore by using the vCloud Availability Administration Portal as cluster datastores are not listed as destination candidates in the storage migration wizard

    In the vCloud Director API, the cluster datastore schema is different than the local datastore schema. The datastore field name is not provided for cluster datastores. The vCloud Availability Administration Portal does not account for this interface inconsistency and fails to list the cluster datastores as destination candidates.

    You can perform a storage migration from a cluster datastore to a local datastore, although the datastore name for the present replication is displayed empty in the vCloud Availability Administration Portal.

    Workaround: None.

  • Using Microsoft Edge or Microsoft Internet Explorer, you cannot download report data as a CVS file

    This issue is caused by compatibility problems between the Microsoft Internet Explorer and Microsoft Edge, and the JavaScript version that vCloud Availability Administration Portal uses. 

    Workaround: To work around this issue, use a supported version of Google Chrome or Mozilla Firefox to download the report data.

  • If you use non-alphanumeric characters in the filter search box, the vCloud Availability Administration Portal might become unresponsive

    When you use the filter search box, if you enter an invalid regular expression pattern, the vCloud Availability Administration Portal cannot process the inquiry and might stop responding.

     Workaround: To work around the issue, refresh the page and avoid using non-alphanumeric characters when using the filter search box.

  • Using Microsoft Edge, when you open the Replication table view, the time format in the Transfer Start Time is displayed incorrectly

    This issue is caused by compatibility problems between Microsoft Edge and the JavaScript version that vCloud Availability Administration Portal uses. 

    Workaround: To work around this issue, use a supported version of Google Chrome or Mozilla Firefox to download the report data.

  • The vCloud Availability Administration Portal stops updating report data

    You must manually regenerate reports to reflect latest changes. Restarting the vCloud Availability Administration Portal does not resolve the issue and you get the following warning message in the homepage:

    Instant data updates are not available now due to an error in messaging system. Please make sure the server is properly configured.

    The vCloud Availability Administration Portal does not acknowledge AMQP messages from vCloud Director.  This leads to the AMQP message queue for the vCloud Availability Administration Portal growing significantly. As a result, RabbitMQ becomes unstable and starts failing to serve requests for vCloud Director.

    Workaround: To mitigate the impact on RabbitMQ stability, disable the synchronization feature. If necessary, reset the RabbitMQ app to clean up the AMQP message queue for the vCloud Availability Administration Portal host:

    1. Connect to the RabbitMQ host over SSH.
    2. Check the message queues status by running the rabbitmqctl list_queues command.
      The system returns a list of RabbitMQ message queues. In the list, you can see that the AMQP message queue for the vCloud Availability Administration Portal contains a long list of messages and keeps growing.
    3. Open an SSH connection to the vCloud Availability Administration Portal host.
    4. In the /opt/vmware/conf/vcav-smp/application.yml file, set the config.sync.enabled value to false.
    5. Restart the vCloud Availability Administration Portal service, by running the systemctl restart vcav-smp command.
    6. In the RabbitMQ console, check the message queue again by running the rabbitmqctl list_queues command.
      If the AMQP message queue for the vCloud Availability Administration Portal does not contain the long list of messages anymore, you have worked around the issue and can skip the next step.
    7. If the system returns the long list of AMQP messages for the vCloud Availability Administration Portal again, run the following commands to reset RabbitMQ app and clean up the message queue:
      # rabbitmqctl stop_app
      # rabbitmqctl start_app

    NOTE: With the synchronization feature disabled, the vCloud Availability Administration Portal has the same data processing capabilities as version 1.0.1.2. Other features, such as Scrub Replication and Tenant Impersonation work as expected. For more information about vCloud Availability Administration Portal 1.0.1.2 features, see the vCloud Availability for vCloud Director 1.0.1.2 Release Notes.

  • You receive an Invalid Payload error in the vCloud Availability Administration Portal, if you use the vCloud Availability Administration Portal to migrate a replication VM from a datastore, to which only the default, *(ANY), storage policy is applied, to а datastore which has a different storage policy applied

    When a tenant configures replication to cloud and selects the *(ANY) storage policy, all the replicated VMs are stored to all the shared datastores to which *(ANY) storage policy is applied. In this case, if you try to move the replications to a datastore to which a different storage policy is applied, the vCloud Availability Administration Portal returns the Invalid Payload error.

    This issue affects only datastores to which *(ANY) storage policy is applied. If a storage policy that is different than *(ANY) is applied to the datastore when replicating to-the-cloud, you do not receive the error and the Storage Migration operation completes successfully.

    Workaround: To work around this issue, create a new storage policy in your resource vCenter Server and apply the new policy to the datastore which you wanted to move a replication VM from. Attach the new storage policy to the PVDC in vCloud Director. It can take up to couple of minutes for the newly created storage policy to appear in vCloud Director. Once the synchronization is done, repeat the migration operation.

Other
  • Running vcav hcs configure returns an error if there are existing solution users already in the PSC

     

    There was an issue creating the HCS solution user: 
    Did not delete pre-existing solution user with the same certificate as ours due to: com.vmware.jvsl.sso.SsoException: 
    com.vmware.jvsl.sso.SsoException: 
    com.vmware.vim.sso.client.exception.AuthenticationFailedException : 
    Provided credentials are not valid.

     

    Workaround: To work around this issue, update the vSphere Replication Cloud Service Host Certificate and run the vcav hcs configure​ command again. For more information, see Update the vSphere Replication Cloud Service Host Certificate.

  • After you fail back a reversed workload, if you try to power on the VM by using an API call, you receive an error for the status of the task

    To power on a VM after a failback operation, you use the vr/failbackreplications/{replication_id}/action/powerOnVm API call. If VMware Tools is not installed on the target VM, the operation fails.

    The issue affects only the vr/failbackreplications/{replication_id}/action/powerOnVm API call.

    Workaround: It is safe to ignore this error. Although the status of the task is failed, the VM is powered on successfully.

  • The vcav script times out when attempting to update the Cassandra server to trust a vSphere Replication Cloud Service host

    Some Cassandra installations do not respond to service stop or systemctl stop commands because of a missing PID file.

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

    1. Run the following command on each Cassandra server to create a PID file.
      mkdir -p /var/run/cassandra; chown -R cassandra:cassandra /var/run/cassandra
    2. Manually stop and restart the Cassandra process.
    3. Make sure that a PID file exists in /var/run/cassandra.
  • The vcav hcs configure, vcav org *, and vcav org-vdc * commands may time out in large environments with hundreds of vCloud Director organizations

    The scripts pull the full record for each organization in vCloud Director. This can create an extensive delay in deployments where there are hundreds of organizations.

    Workaround: None. 

  • If you are installing and configuring vCloud Availability with an instance of vCloud Director upgraded to version 8.20 or 9.0, you might receive the following error message:

    Unable to update the rights for Organization Name

    There is a bug in the vCloud Director 8.20 and 9.0 upgrade process that does not always clean up roles correctly. You may be impacted by this issue if you configure vCloud Availability for vCloud Director with vCloud Director 8.10, then upgrade to vCloud Director to 8.20 or 9.0, remove the vCloud Availability for vCloud Director solution, and are attempting to install and configure vCloud Availability for vCloud Director with the upgraded vCloud Director 8.20 or 9.0.

    Workaround: To work around this issue, you must clean up vCloud Director roles table in the vCloud Director database. There are two ways to clean up the roles table. 

    • Using the vCloud Director APIs:
      1. Send a GET request to retrieve a list of all existing vSphere Replication roles to the following URL:
        https://vCD-IP-Address:443/api/query?type=adminRole&format=records&filter=name==vSphere Replication Role
      2. The system returns a list with details for all existing vSphere Replication roles.
      3. Send a DELETE request to the following URL.
        https://vCD-IP-Address/api/admin/role/{id}
    • Issuing an SQL DELETE statement
      • (MSSQL) DELETE FROM role WHERE name = 'vSphere Replication Role'

    NOTE: Use vCloud API version 29.0 for vCloud Director 9.0 and vCloud API version 27.0 for vCloud Director 8.20.