VMware

vSphere Data Protection (VDP) 6.0.2 Release Notes

vSphere Data Protection (VDP) 6.0.2  | 02 JULY 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 VMware Interoperability Matrix.

Known Problems and Limitations

The following are the known problems and limitations in this release of VDP:

VMware Issues

  • Image backup fails for powered-on virtual machine running on VSAN datastore (1281041)

    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 (1292848)

    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 (1294581)

    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 (1309755)

    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 by 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:

    TMOUT=900

    export TMOUT

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 (222475)

    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.

    Workaround:

     Edit the VM settings, set the network connection to the network adaptor, and then power on the VM.

  • VMware Proxies Appliance are vulnerable to a man-in-the-middle-attack (222547)

    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.

      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"
      --ssl_server_authentication_file=/usr/local/avamarclient/bin/rui-ca-cert.pem

      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:

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

      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:

      --ssl_server_authentication_file=/usr/local/avamarclient/bin/rui-ca-cert.pem

      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:

      vixDiskLib.linuxSSL.verifyCertificates=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 (222670)

    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 (222957)

    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 (223217)

    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 (223246)

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

  • User must disable vMotion during backup window and before running restores to new (224181)

    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:

      https://<IP_address_vCenter_Server>:9443/vsphere-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 (224280)

    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 (225343)

Interoperability Issues

  • 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 (58839)

    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.

VMDK Issues

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

    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 (59497)

    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 (59784)

    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 (197873)

    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.

    Workaround:

    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.
  • Though the Automatic Backup Verification (ABV) jobs succeed, VDP always shows the ABV jobs as "never" under the "Completion" column on the Reports tab or the Backup Verification tab (233385)

Workaround:

Restart the emwebapp.sh service by running the emwebapp.sh -restart command.

Backup Issues

  • Loading clients takes a significant amount of time when editing or cloning a backup job (60249)

    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 (207375)

    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. (35110)

    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 (45699)

    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 (53004)

    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.

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

    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 (197652 CLONE: 197437)

    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 (194669)

    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 (195196)

    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 (196573)

    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 (56723)

    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 (191795)

    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 (55790)

    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 (55795)

    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 (56619)

    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.

Fixed Problems

The following table lists the problems that have been fixed in this release of VDP:

Defect Number Description
229809 The browsers that end trust for SHA-1 SSL certificates for VDP require update.
235851 GNU C Library (glibc) update for VDP 6.0.2.