vSphere Data Protection (VDP) 6.0 Release Notes

vSphere Data Protection (VDP) 6.0 Release Notes | 09 MAR 2015
Updated 25 MAR 2015

These release notes include the following topics:

Benefits and Features

Read about the benefits and features of this product at the following links:

Supported Environments

For information on supported environments, see the VMware Interoperability Matrix.

Known Issues in vSphere Data Protection 6.0

The following known issues have been discovered through rigorous testing. The issues pertain to vSphere Data Protection (VDP) 6.0.

VMware issues

  • VDP crashes while creating / performing backup jobs.

    After a successful backup of 32 virtual machines using VMware's Virtual Machine File System (VMFS), backup jobs for additional sets of virtual machines causes the vSphere Data Protection UI to hang. This occurs when the user performs incremental backups of a batch of 8 virtual machines (for example: 8, 16, or 32).


    Perform one of the following tasks:

    • Reboot the VDP Appliance. This has proven to be the most successful workaround.
    • Log out and back in to the Next Generation Client (NGC).
    • Restart the NGC UI Client.
  • Image backup fails for powered-on virtual machine running on VSAN datastore.

    An image backup fails for powered-on virtual machines running on a VSAN datastore, where both the VDP Appliance and the virtual machine are running on the same VSAN datastore, but are hosted and powered on by different vSphere hosts. The issue exists only when the virtual machine is in a Powered On state.

  • Support for routed / NAT / Firewall / IDS / TSNR between the VDP Appliance and the vCenter

    When configuring the network for the VDP Appliance and the vCenter, modifying network address information using NAT or other configuration methods (for example: firewall, IDS, or TSNR) is not supported. When those tools are deployed as part of the virtual network, some VDP functionality may not work as designed.

  • Running in secure mode results in users not able to clean up previous failed backups, in which artifacts are left behind.

    Bugs 1293852 and 1294581 are related to enabling the secure mode. Currently in the VDP Appliance UI, we recommend that if users want to secure their deployment, they should run with the SSL host verification enabled (which is disabled by default). Previously this option did not exist.

  • With 5.8, root login was disabled.

    With 5.8, root login was disabled, as it is not a best practice. An option is needed to enable ssh root login. Additionally, the shell is set to time out after 15 minutes, if no activity occurs in the shell. An option is needed to disable the shell timeout. These improvements will help with the customer support experience during troubleshooting and while using the shell.

    Workaround: Log in using the admin account. Then, use the sudo command to perform root functions.

    The bash shell (in the /etc/profile directory) is set for a 15-minute timeout if no activity occurs in the shell. You can add the console timeout value using the hardening script. For example:


    export TMOUT

Compatibility issue

  • VDP versions prior to 6.0 are not compatible with vCenter 6.0

    Earlier versions of VDP (5.8.x, 5.5.x, and 5.1.x) are incompatible with vCenter 6.0 for the following reasons:

    1. The VDP plug-in, regardless of its version, shows in the vSphere 6.0 user interface only when VDP 6.x exists in the environment.
    2. VDP 5.5.x cannot connect to the vSphere 6.0 UI.
    3. If VDP 6.0 and VDP 5.8.x exist in the same vCenter, you can connect to the VDP plug-in for VDP 5.8, but you cannot perform hot add backups.

    These are known isues and there are no workarounds. For lower versions to be compatible with VDP 6.0, you must upgrade to version 6.0

Documentation issues

  • The SQL Server 2005 section in the "VDP Application Support" chapter of the vSphere Data Protection Guide (versions 5.8 and 6.0) erroneously claims "x64" support
  • The text currently reads as follows:

    SQL Server 2005 SP3 x64 on:

    • Windows Server 2003 SP1 or later, x86/x64
    • Windows Server 2003 R2, SP2 or later, x86/x64
    • Windows Server 2008 SP1 or later, x86/x64
    • Windows Server 2008 R2, x64

    Note the SQL Server should read: "SQL Server 2005 SP3" (remove "x64"). The bullet points are correct.

  • Powering On of VM fails when backed up VM was connected to DVS and restored to other ESX.

    When powering on a VM after you restore it, vCenter returns a PowerOnFailure error similar to the following:

    DRS cannot find a host to power on or migrate the virtual machine. Network interface 'Network adapter 1' uses network '77 d3 02 50 5f 76 ca d7-db f9 42 6c 0f 6f 87 1f', which is not accessible

    This error message occurs when the environment where you restore the VM does not have the network connection that was present when you backed up the VM. For instance, a user backs up a VM that is connected to a distributed vSwitch. Then the user restores the VM to an ESX host that is part of a Distributed Resource Scheduler (DRS) cluster. The vSwitch does not exist in the DRS cluster. Powering on the VM, therefore, fails.

    To work around this issue, edit the VM settings and set the network connection to the network adaptor. Then power on the VM.

  • VMware Proxies Appliance are vulnerable to a man-in-the-middle-attack.

    By default, proxies do not validate SSL certificates when connecting to the vCenter Server. This can leave the vCenter Server vulnerable to a man-in-the-middle exploitation, which might result in unauthorized access to the vCenter Server. Configure each proxy to use an SSL certificate authentication when connecting to the vCenter Server to correct this vulnerability.

    Because of bug 222547, the "Secure External Proxy Communication with vCenter on pages 53-54 in the vSphere Data Protection 6.0 Administration Guide requires updates. The following procedure includes these updates. Use this procedure instead of the one on pages 53-54:

    1. Open a command shell and log in to the proxy as root.
    2. Copy the vCenter Server certificate to /usr/local/avamarclient/bin on the proxy:
      • For Linux vCenter Appliance:

        scp file /etc/vmware-vpx/ssl/rui.crt and /etc/vmware-vpx/ssl/rui-ca-cert.pem from vCenter appliance into /usr/local/avamarclient/bin on the proxy
      • For Windows vCenter:

        scp c:\ProgramData\VMware\VMware VirtualCenter\SSL\rui.crt and c:\ProgramData\VMware\VMware VirtualCenter\SSL\cacert.pem into /usr/local/avamarclient/bin on the proxy.  
      • NOTE: If a chained SSL certificate is used for the vCenter, copy the chain.pem file, which contains all certificates in the chain, to /usr/local/avamarclient/bin on the proxy.

    3. Set the proper operating system permissions on the certificate by typing:

      chmod 600 /usr/local/avamarclient/bin/rui.crt

      where rui.crt is the actual certificate name.

    4. Run the following command against the rui.crt to capture the SSL cert thumbprint:

      openssl x509 -in rui.crt -fingerprint | grep Finger

      The output should look similar to the following:

      SHA1 Fingerprint=C7:35:19:95:9C:3F:56:1D:73:35:52:41:F3:02:46:A3:B9:46:4F:D9

    5. Open /usr/local/avamarclient/var/avvcbimageAll.cmd in a UNIX text editor.
    6. Append the following entries to the end of the file:

      --ssl_server_cert_thumbprint="thumbprint of rui.crt"

      where rui.crt is the actual certificate name and thumbprint is the actual thumbprint for the vCenter Server. The output should look similar to the following:


      NOTE: Use chain.pem for chained vCenter SSL certificates.

    7. Save your changes and close avvcbimageAll.cmd.
    8. Open /usr/local/avamarclient/var/avvmwfileAll.cmd in a UNIX text editor.
    9. Append the following entry to the end of the file:


      where rui-ca-cert.pem is the actual certificate name.

      NOTE: Use chain.pem for chained vCenter SSL certificates.

    10. Save your changes and close avvmwfileAll.cmd.
    11. Open /etc/vmware/config in a UNIX text editor.
    12. Append the following lines to the end of the file:

      vix.enableSslCertificateCheck = "true"

      vix.sslCertificateFile = "/usr/local/avamarclient/bin/rui-ca-cert.pem"

    13. Save your changes and close /etc/vmware/config.
    14. Open /usr/local/avamarclient/var/vddkconfig.ini in a UNIX text editor.
    15. Find the vixDiskLib.linuxSSL.verifyCertificates=0 entry.
    16. Change the vixDiskLib.linuxSSL.verifyCertificates=0 entry to 1:

    17. Save your changes and close vddkconfig.ini.
    18. Ensure that no backup or restore jobs are running on this proxy.
    19. Restart the avagent and vmwareflr services by typing the following commands:

      service avagent-vmware restart
      service vmwareflr restart
  • Service Stop/Start buttons become unavailable on Configuration page, when you run emwebapp.sh --restart from CLI.

    Workaround: You must run emwebapp.sh from a sudo login shell (sudo -i) or as the root user (su - root). Otherwise, there is a chance that the services buttons on the Configuration page will become unavailable.

    The vSphere Data Protection Administration Guide references the emwebapp.sh script three times:

    • On page 32 in "Best Practices," there is a reference to emwebapp.sh --start.
    • On page 36 in "Freeing up space for the upgrade," there are two references. Step 3 includes emwebapp.sh --stop, and step 9 includes emwebapp.sh --start.

  • VMDK Backup Job silently fails when single vmdk is migrated to a different datastore.

    During a migration of an individual VMDK from one datastore to another, VDP attempts to update all backup jobs that contain the disk that was migrated. In some instances, VDP cannot accurately determine where the disk referenced by the backup job was migrated to. In this case, the backup job is not updated. One instance of this issue is when the disk folder name on the new datastore is different than the folder on its original datastore. If VDP cannot determine where the VMDK is migrated to, VDP sends a vCenter alert that the backup job may no longer be accurate.

    If the VDP Appliance is shut down or the emwebapp.sh service is stopped at the time of the VMDK migration, VDP cannot detect the migration. The backup jobs are not updated. If backup jobs are out of sync, no alert is sent to vCenter. If a backup job is out of sync with the location of the VMDK, the backup job continues to complete successfully, but no longer backs up the disk that was migrated.

    To resolve this issue, update the backup job. Then re-add the migrated VMDK to the backup job by using the VDP vCenter plug-in.

  • Disk backups can be deleted, whereas the Admin Guide mistakenly says that you cannot delete disk backups.

    The vSphere Data Protection Administration Guide requires corrections to the following topics:

    • Deleting a Backup Job topic on page 118 - The following statements are invalid and will be deleted in the next version of this guide: "You cannot delete backups that were run on individual disks. You can only delete full image backups."
    • Deleting a Backup from the Restore Tab on page 132 - The statement "You can only delete full image backups" should be restated as, "They can only be deleted along with the deletion of full image backups."

  • Add documentation to the admin guide to indicate that VDP 6.0 will not support VVOL.

    VDP 6.0 does not support backups and restores of VMs on Virtual Volumes (VVOLs).

  • Before restoring to a new virtual machine, you must disable Storage DRS and set it to "Manual"; otherwise, the restore operation will fail.

    During the backup window and before running a restore to a new location, you must disable the vMotion feature at the VM and datastore levels.

    1. From a web browser, access the vSphere Web Client:

    2. Select vCenter > Hosts and Clusters.
    3. Select the DRS tab.
    4. Select the Manual checkbox for all DRS clusters listed in the left menu.
    5. Select Inventory > Datastores.
    6. For each datastore where VMs, proxies, and VDPs reside, do the following:
      1. Select the datastore.
      2. Select Edit Settings.
      3. On the left menu under General, click SDRS Automation.
      4. In the right panel, select No automation (Manual).
      5. Select Virtual Machine Settings.
      6. Ensure that all VMs show Disabled or Manual for the SDRS Automation.
  • Cannot replicate Imported image backups.

    For imported backups, the import process moves the clients and accounts from their current account path to /REPLICATE/VDP_IMPORTS/. The name of the domain at this level includes a timestamp, which is appended to the end of the name. The import process also deletes all jobs. To replicate these backups, you must select replicated backups for the type, and then select imported backups.

  • Customer Experience Improvement Program (PhoneHome) is not supported in a pure IPv6 vSphere Data Protection environment.
  • VMDK issues

    • Incorrect behavior of the VDP Appliance when more disks are added to the same SCSI slots.

      The VDP Appliance initiates a restore operation with the same SCSI IDs on the same existing VM assigned to two different restore points. In addition, the Summary page incorrectly indicates that two new virtual disks will be added. The Restore operation completes successfully without informing the user that only the first single disk was added, and the second disk simply replaced the first disk.

    General VDP Appliance Issues

    • A password change on a configured vCenter Server is not allowed on the VDP Appliance, even after the vCenter Server password has expired.

      The VDP-Configure application does not allow a password change for the configured vCenter if backups are in a Running state on the server. If the user password on the configured vCenter has already expired, no tasks are posted on the task console, and, consequently, the tasks cannot be canceled.

      Workaround: Perform the following steps:

      1. Wait until all the backups and tasks finish in the VDP Appliance and then change the password.
      2. Restart the VDP Appliance in the maintenance window, and then log into the VDP-Configure user interface and change the vCenter password from the VDP-Configure user interface.

    • The Performance Assessment Test (PAT) result changes to Never Run when the datastore name is changed.

      In this scenario, the user opens the VDP-Configure user interface, clicks the Storage tab, selects a datastore, and clicks the Run performance analysis on storage configuration checkbox. The performance analysis test completes successfully and the results of the performance analysis are displayed correctly. If the user changes the name of the datastore, however, the performance analysis results erroneously indicate the status as Never Run.

    • VDP server is prone to man-in-the-middle attack

      After you enable the SSL configuration to secure a connection between vCenter and VDP, a user is unable to connect from the VDP plug-in. As a result, the following error appears in the vdr-server.log:

      javax.net.ssl.SSLHandshakeException:java.security.cert.CertificateException: No subject alternative names matching IP address x.x.x.x found

      Root Cause:

      The vCenter server is registered to VDP by using a vCenter IP address. No subject alternate name is available in the vCenter certificate.

      To address this issue, use one of the following workarounds:

      • Regenerate the self-signed vCenter certificate and add the subject alternate name to include the IP address.
      • Reregister the vCenter with VDP by using the fully qualified hostname that was provided in the vCenter certificate. If you choose to reregister by using a fully qualified hostname, all backup jobs and policies will be deleted. You must re-create the backup jobs and policies after you make changes to the configuration. Restore jobs and backups are not affected.

    Backup Issues

    • If a large backup job is created (~100 VMs), the backup job can take up to ten minutes to create.
    • Loading clients takes a significant amount of time when editing or cloning a backup job.

      The edit or clone action of a backup job for a SharePoint server (upgraded plug-in) takes 5 to 10 minutes to load clients. In addition, some delay occurs when loading clients for Microsoft Exchange and SQL servers that were created before an upgrade.

      This is a known issue that will be fixed in a future release.

    • Backup of a VM fails when ESX is moved from one datacenter to other within same vCenter inventory.

      After you move an ESX host from one datacenter (Datacenter A) to another (Datacenter B), and then perform a manual backup of a VM client in the Datacenter B, the backup might fail. The error log shows that the backup job still refers to Datacenter A instead of Datacenter B.

    • To work around this issue, perform one of the following steps before you run a manual backup of the VM:

      • Wait for 24 hours. This enables the backup job to reflect the correct datacenter.
      • Run the following mccli vmcache sync command:

        mccli vmcache sync --name=vCenter_ipaddress --domain=/vCenter_ipaddress

    Restore Issues

    • If a virtual machine is deleted during a VDP restore operation, the virtual machine is not properly removed from the VDP inventory. This causes an error when editing the backup jobs that included the deleted virtual machine as source. Additionally, if a virtual machine is created with the same name, attempts to add the virtual machine to a backup job will fail.

      Workaround: As a best practice, avoid deleting virtual machines during restore operations. If this error does occur, create the virtual machine with a new name and add it to a new backup job.

    • File Level Restore (FLR): "Error 10007: Miscellaneous error" is displayed for most of the FLR failures.

      The "Error 10007: Miscellaneous error" message is displayed for most of the FLR failures. In addition, FLR does not display any error message in cases where there is a restore failure due to the disk being full or a long file path. Therefore, it is impossible to determine the root cause of the FLR failure.

    • Deleted disks are skipped when restoring to original location.

      If the target VM no longer has the same disk footprint as the original VM that was backed up (if the disks have been removed or deleted from the VM), performing a "Restore to original location" operation, after selecting a restore point timestamp in the Restore pane, will silently fail to restore the missing disk of the VM.

      Workaround: Restore the disk to its original location after manually adding the missing disk to the VM. Ensure the disk is the same size as it was when the VM was backed up. If this workaround fails, restore the disk to a new location to create a new VM. When the restore task completes, detach the restored disks from the new VM and attach them to the required VM using the information in "Detaching and Reattaching Storage" of the vSphere Data Protection Administration Guide.

    • In a VSAN environment, the image-level restore to original location operation is allowed, but the disk-level restore to original location operation is grayed out, after migrating the entire virtual machine to another datastore.

      Workaround: Either restore the entire VM with an image-level backup or restore the disk level backup as a new disk on the original VM.

    • File Level Restore (FLR): Need proper error message for failure to load EXT4 partition tree with internal proxy.

      FLR browsing of an EXT4 partition with an internal proxy is not supported. If the user performs this action, no proper error is prompted.

    • Restore backup of secondary replica failed or aborted with log gap error.

      When restoring an incremental backup of a secondary replica, the restore returned a failed / aborted status and the log indicates the log gap error, though the database has no log gap. Note that this issue has not been observed in restoring a backup of a primary replica.

      The issue is AlwaysOn nodes synchronization-related and occurs during the creation of SQL metadata file in the backup workflow, in cases where the backup is taken on a secondary AlwaysOn replica.

      This issue results in backups with a corrupted metadata file, so users could not perform a Log tail recovery or some additional differential / incremental backup could not be linked to this backup chain.

      There is no data loss.

      Workaround: Perform a full backup. Ensure the "Force incremental backup after full backup" backup option is unchecked.

    Replication Issues

    • Replication of replicated clients under a particular tenant on the target server fails.

      The replication of replicated clients from a source to a target server under a particular tenant account fails with the following error message:

      Specified account ( ) does not fall within the current authorization domain.

      In addition, the failure occurs with the following source/target combinations:

      • Source server: VDP Advanced and Target Server: VDP Advanced / Replication Target Identity (RTI)
      • Source server: RTI and Target Server: RTI / VDP Advanced

    • Replication Recovery: Replication logs are filling up the root partition - need to create a symlink to another partition.

      The replication logs are currently going to the /space partition and not to the root partition.

      Workaround: Manage the replication logs in the /usr/local/Avamar/var/client directory (the space partition).

    • Replication succeeds when there are no restore points.

      Replication jobs run and complete successfully, even after the restore points have been deleted. The replication job, however, does not replicate the backups. The expected behavior is the job should fail as there are no restore points to replicate.

      This is a known issue that will be fixed in a future release.

    Microsoft Application (MS App) Issues

    • On Microsoft Exchange clients, there are many warning messages in the avagent log that print frequently and fill up the logs.

      The Microsoft Exchange client is left registered with two VDP Advanced Appliances in the vCenter, which is causing this issue.

    • Upgrade 2014: The Backup Agent user is reset to Local System after upgrading the Microsoft Exchange client plug-in.

      When upgrading the Microsoft Exchange client plug-in from the previous version of the VDP Advanced Appliance to the current VDP Advanced Appliance, the backup agent service logon user is reset to Local System, rather than Backup User.

      From VDP version 5.5.6 to 5.8, the system resets the credentials to local system credentials without asking for permission, causing the backup job to fail

      Workaround: To edit the Microsoft Exchange backup job or to create a new Microsoft Exchange backup job, the user must manually configure the backup agent service. To do this, the user must enter the username and password using the Backup User Configuration Utility.

    Automatic Backup Verification (ABV) Issues

    • ABV: Verification job fails after renaming the datastore.

      This error can occur if you rename or move the destination datastore outside of VDP.

      Workaround: Edit the verification job and select the renamed or moved destination datastore as the new destination. For instructions, refer to "Editing a Backup Verification Job" in the vSphere Data Protection Administration Guide.

    • ABV: Verification job fails to initiate when destination path for host is changed.

      Workaround: Edit the verification job and select the appropriate destination path when you perform the verification job.

    • Improper error messages are reported if the Verification job failed because of connection issues due to Data Domain.

      The backup cannot be restored and the Verification job fails because the VDP Appliance cannot talk to the Data Domain. It is expected for the Verification job to fail; however, the proper error message does not display and the user does not know the root of the failure.

    Resolved Issues in vSphere Data Protection 6.0

    The following issues have been resolved since the last release of vSphere Data Protection.

    • If a thin provisioned VDP reaches datastore capacity, then even after freeing up the datastore and creating more space, integrity check errors occur on the VDP.

      On a thin-provisioned VDP Appliance with a VM size of 100 GB or more, running the backup job causes a data integrity issue which results in a system fatal error. The probable cause of the error is the datastore reached full capacity and caused the integrity check to fail. Even after freeing some space, the integrity check will fail.

      To disable the alert, either perform a successful, full validation for the most recent checkpoint or contact Customer Support to obtain a code to disable the alert.

    • Clean up is required for canceled restore operations.

      When the user creates a new restore operation on a virtual machine and then cancels the restore operation before it completes, the new virtual machine, which is created in the vCenter, is not cleaned up. The current implementation removes the snapshot of the virtual machine but does not remove the newly-created or newly-registered virtual machine.

      This is by design.

    • The VDP Appliance disconnects and, in many cases, unexpected errors occur.

      Users may occasionally receive the following error message: "An unexpected connection error occurred and the cause could not be determined. Please check your VDP Configuration screen to troubleshoot, or contact an administrator." This is a generic error message and may display for any unexpected error.

      NOTE: The message may occur, however, more frequently with vCenters in the version 5.5 range (including version 5.5u1b).

      If this error occurs and it is a result of the known issue, the user should cancel out of the error message and attempt the action again. If the failure persists, contact Technical Support.

    • During VDP installation, if the user clicks Previous on the vCenter Server registration screen but does not enter any values, the system fails to register with the vCenter Server and the installation fails.

    • vCenter events do not generate during initial configuration if the user modifies the VDP hostname or IP address.
    • Restore fails when attempted to restore as new VM using previous name of the renamed VM.

      When the user creates a backup job for a VM, selects the restore point, and enters the old name of the renamed VM in the Restore to New Location field, the restore fails with the following message: Unable to restore VM for restore point. The datastore path already exists.

    • No proper error handling when running scheduled disk backup job of a VMDK which was migrated to another datastore.

      A scheduled backup job of a VMDK completes without any errors but when the datastore location is changed to another datastore, the error occurs.

    • ABV: An on-demand verification job is not initiated if the last backup was not successful.

      The following error is observed on an ABV job if the last backup was not successful:

      Error: "Unexpected error with NO error code, refer to logs."

      The user is not made aware of the problem and the logs do not contain useful information.

    • Microsoft SharePoint redirected restore job fails for the database if the IP address is used as an alias instead of the server name.

      Backing up to the original location with the overwrite option works correctly. The backup fails only when running a redirected restore when the IP address is used instead of the server name.

      Workaround: Use the server name when creating an alias.

    • Unable to log in to vdp-configure after the first reboot.

      There are intermittent instances where the user is unable to login to vdp-configure after the deploy-reboot cycle. No error is shown in the vdr-configure log. Clearing the browser cache and trying to log in with different browsers does not fix the problem.

      Workaround: Using a console connection, log into the VDP virtual appliance and use the following commands to manually start and stop the vdp-configure services:

      emwebapp.sh --restart

    • A Microsoft SharePoint redirected restore job displays as successful, even when some databases fail to restore.

      When restoring many databases or an entire SharePoint farm, some problematic databases may fail. Even though some of the databases fail, the restore job reports that the job is successful. This could result in lost data. The database backup fails only when running a redirected restore when the IP address is used instead of the server name when creating an SQL alias.

      Workaround: Use the server name when creating an alias.

    • The VDP Appliances crashes and powers off when a thin-provisioned virtual machine is restored on a datastore with insufficient space.

      The appliance crashes because the disk that has been hot-added to the appliance has insufficient space, so placing the appliance on a different datastore would not fix the problem.

      As a best practice, before performing an ABV or restore task, check the free space availability on the datastore to ensure there is sufficient space.

    • When performing a granular level restore (GLR) on a Microsoft Exchange server, the destination mailbox field should be optional.
    • Out-of-date sources for a failed or cancelled Application database backup displays incorrect count.
    • Import Disk: The Initial Configuration wizard always allocates the default of 4 vCPUs and 4 GB RAM.
    • Snapshot removal failed even though the "Create Snapshot" task returned a valid snapshot.

      Occasionally, backups may fail with the "Snapshot Removal Failed" error. This is due to a VMware defect where the snapshot removal is denied by the vCenter Server, even if the snapshot creation was successful.

      Workaround: Manually remove the snapshot from the virtual machine using the Snapshot Manager and then resubmit the backup job.

    • Failed to import VDP disks stored in the VSAN datastore.

    • Failed Replication task with expired or changed destination credentials should display an appropriate error.

    • The VDP Appliance disconnects automatically while selecting any option in the vSphere Web Client.

      If the user clicks on Event or Task options in the vSphere Web Client, and then attempts to return to the VDP Appliance screen, the connection is lost. The user must manually connect to the VDP Appliance.

    • Users cannot run securely if running a non-default vCenter Server port.

      This defect is a side effect of increased VDDK security to protect against OpenSSL man-in-the-middle attacks. If the vCenter is not using the default web service port (443), and VDP is configured in such an environment, do not use the "Configuring Proxy Certificate Authentication" procedure in the vSphere Data Protection Administration Guide, as the result could be unfavorable.

      Workaround: Use the default web service port (443) when configuring proxy authentication.

    • Holes in Change Block Tracking (CBT) data after extending disk to 150G.

      To work around this issue, see VMware Knowledge Base article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2090639

    • Reports: Refresh does not clear the filter options.

    • Replicated workorder on the source VDP Advanced Appliance gets queued up intermittently.

      On a VDP Advanced Appliance with imported disks, the first time an ad-hoc replication job is triggered, the replication client is placed in a disabled state. This causes the replication to become queued. The job waits until the replication client is re-enabled or the job times out.

      Workaround: Disable the replication client and then re-enable it. If the replication client is already disabled, simply re-enable the client.

      As an Admin user, use the following commands to disable and re-enable the replication client:

      To locate the replication client, use the following command:

      mccli client show --recursive=true --domain=/MC_SYSTEM

      To disable and re-enable the replication client, replace with the client name retrieved in the previous command:

      mccli client edit --name=/MC_SYSTEM/ --enabled=false

      mccli client edit --name=/MC_SYSTEM/ --enabled=true

      Note: If the client is already disabled, only the second command is necessary to re-enable the client.

    • Replication Recovery: Recovery logs should be identified separately from ad-hoc replication logs.

      Recovery logs and ad-hoc replication log items are distinguished by workorder IDs (WIDs), which are unique identifiers for virtual machines or clients that have been recovered or replicated. When a user performs replication and recovery on the same VDP Advanced server, the logs-bundler collects logs for both actions under the /REPLICATE/Server_logs directory. The appliance cannot segregate recovery logs from ad-hoc replication logs and this creates a burden for the user when attempting to identify and debug logs.

    • Multi-Tenancy: Replication source server information should be provided on the Recover wizard.

      When the same virtual machine, or a virtual machine with the same name, is replicated from two different source servers under the same tenant node using the same user account, the Clients and Backups page on the Recover wizard displays the virtual machine from the source server, as shown in the following multi-tenancy hierarchy:

      /VDP Advanced-Target
        -VDP Advanced-Source 1
             -Client 1
        -VDP Advanced-Source 2
           -Client 1

      During the recovery action, the Clients and Backups page displays Client 1 from Source 1 and Source 2 with the respective backups. However, other than the date and time stamp, there is no way the user can distinguish between the two clients with the same name and suffix.

    • Error message needs correcting when adding a Data Domain system to the VDP Appliance when the time is not in synch.

      The following error message displays when the Data Domain system time and the VDP Appliance time are not synchronized:

      Unable to add trap host to Data Domain system

    • Replication job erroneously displays a status of 'failed' rather than 'cancelled'.

      On a VDP Advanced Appliance, even when the replication job is cancelled, the job continues to run for some time and eventually the job fails instead of cancels.

      The cancellation request does not reach the source, so the replication tasks keep running on both the replication source (the parent) and the replication target (the child), even when the job is cancelled.

      This is a known issue that will be fixed in a future release.

    • On Microsoft Exchange clients, the system times out and the browse capability fails.
    • The user should be prompted not to deploy an external proxy during a backup job.

      The user is not warned against deploying an external proxy while a backup is in progress. If an external proxy is deployed during a backup, the deployment continues but the process automatically disables the internal proxy. This could cause currently-running backups to fail or the backup session could end unexpectedly.

      Note: If the user attempts to deploy an internal proxy, the currently-running backup job is cancelled.

    • Restore fails or is aborted when the availability group database name contains a Unicode character.
    • Timed-out tasks for the VDP Advanced Appliance should be reported in the Recent Tasks pane or Error Logs.

    • Restoring individual VMDKs to multiple virtual machines results in VMDK restore for only one of the virtual machines.
    • During a VDP or external proxy configuration, the VDP Appliance fails to resolve using the secondary Domain Name System (DNS) service.
    • Replication recovery: The Recover wizard's authentication mechanism does not terminate the authentication process properly.

    • Reports: Rerun failed job runs all the clients in the backup job.

    • Lower-version SQL client configurations are not supported in higher-level vSphere versions.

      When a lower version of an SQL client is installed on a higher version of a VDP Advanced Appliance, the user cannot display or browse the client in the vSphere Web Client. Lower version clients are not supported in the VDP Advanced Appliance.

      This is a known issue. Since we do not intend to support lower-level SQL clients, the issue will be documented in the Troubleshooting section of the vSphere Data Protection Administration Guide.

    • Replication recovery: Action logs are not collected under the log bundler of the source VDP Appliance.

      Recovery logs that are created under a local host source server are not collected by the log collector.

      This is a known issue that will be fixed in a future release.

    • External proxy: The internal proxy is enabled after rolling back to a previous checkpoint.

      The configuration can consist of external or internal proxies; a combination is not allowed.

      If a VDP Advanced appliance is rolled back to a previous checkpoint, internal proxies are enabled and external proxies are still enabled, but in a degraded state.

    • Delay in the availability of the VDP Appliance in the Web Client following an upgrade from 2013 R2 U1.

      There is more than a one-hour delay in the availability of the VDP Appliance in the vCenter Web Client home page (in the plug-in drop-down menu). (The appliance deploys to the vCenter in seconds; however, it does not display in the Web Client at the same time).

      This is an issue with the VMware vSphere plug-in update, and not with the VDP Appliance upgrade.

    • VM backup failed with miscellaneous error 10007: Failed to download VM metadata.

      To determine the cause of the miscellaneous error:

      1. Navigate to the Reports tab of the VDP Appliance.
      2. Click the View Log link to view details for the failed backup job.

      NOTE: To verify virtual machine errors or errors with the virtual machine's metadata, you can browse the VM datastore. The backup job might have failed because the appliance is looking for a .vmx file inside an incorrect VM folder.


      1. Consolidate the VM files into a single VM folder

      2.   or
      3. Keep the VM files in a different VM folder in separate datastores, and then migrate them to different datastores (if the virtual machines are in the same datastore).
      4. Rerun the backup job.

    • After a checkpoint recovery from a Data Domain system, the VDP Appliance cannot run a replication operation.

      This problem is caused when cprestore copies the checkpoint from the Data Domain system. After the checkpoint is restored, the restored replication agent is registered to the old VDP Appliance. Therefore, the replication agent must be re-registered to the new (restored) VDP Appliance.

      Workaround: The following steps resolve this issue:

      1. Configure a new VDP Appliance to be used to restore the checkpoint that is on the Data Domain system.
      2. Type the following command to recover the checkpoint from the Data Domains system to VDP:

        /usr/local/avamar/bin/cprestore --hfscreatetime=avamar_ID --ddr-server=data_domain_system --ddr-user=dd_boost_user_name --cptag=checkpoint_name

        Example command:

        /usr/local/avamar/bin/cprestore --hfscreatetime=1400081761 --ddr-server= --ddr- user=sysadmin --cptag=cp.20140519205933
      3. Copy a checkpoint from the Data Domain system to VDP.
      4. Type the following commands to roll back to the restore checkpoint:

        dpnctl stop
        dpnctl start --force_rollback

      5. Reset the replicate avagent by performing one of the following:
        • Reboot VDP.
        • Run the following commands:

          service avagent-replicate stop
          service avagent-replicate unregister
          mccli client edit --domain=/mc_system --name=vdp_hostname --activated=false
          service avagent-replicate register /MC_SYSTEM
      6. After the rollback completes, connect to the VDP Appliance.
      7. Restart the internal proxy.
    • File Level Restore (FLR): Error observed as 'Failed to get disks: Unable to browse as proxies are unavailable.

    • The vApp > Import permission, which validates during vCenter registration, is missing from the vSphere Data Protection Administration Guide.
    • Disk expansion failing for data disks in VSAN datastore if the VDP OS boot disk of 100GB is residing on non-VSAN datastore.

      When you perform a disk expansion in a VSAN datastore, the expansion process fails with an Expansion failed error. The following errors appear in the vdr-configure.log file:

      A VDP environment that you deploy on a non-VSAN datastore does not support expansion of a data disk that you deploy in a VSAN datastore. VMware does not allow you to manually change the disk size or allocation from vCenter. Because VDP runs the expansion process, VDP cannot shut down the VM without also shutting down the VDP software.

      To work around this issue, migrate all the VDP disks, including the OS boot disk and the data disks, to the same type of datastore. For example, ensure that all of the disks reside on either a VSAN datastore or on a non-VSAN datastore. Retry the disk expansion after the storage migration.

    • Exchange 2013 GLR is mounting the DB but is not browsing it, the backups stored on Data Domain.

      For users who are backing up their Exchange server and targeting a Data Domain system for the backup, Exchange GLR may fail to browse the database during restore attempts.

    • English messages may appear in French or Korean in the vSphere Web Client.

      The vSphere Web Client may display some error message in French or Korean even though the web browser runs in an English locale.

      This is a known issue that will be fixed in a future release.

    • Modify frequency of check for number of VDP appliances in vCenter.

      When you deploy multiple VDPs in a Virtual Center that manages a large infrastructure, the memory usage of the Virtual Center may peak and cause the Virtual Center to become unresponsive.

      Workaround: Decrease the number of VDPs deployed.

      This is a known issue that will be fixed in a future release.