vSphere Data Protection 5.5.11 Release Notes

|
vSphere Data Protection 5.5.11 Release Notes | 17 November, 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 vSphere Data Protection:

VMware Issues

  • Snapshot removal failed even though the "Create Snapshot" task returned a valid snapshot (59450)

    Occasionally, backups may fail with the "Snapshot Removal Failed" error. This is due to a VMware defect where the snapshot removal is denied by 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.
     

  • Canceling a backup job leaves disks attached to the vSphere Data Protection virtual appliance and snapshots are not removed (59792)

    If a request to cancel a running backup is received and the proxy cannot complete the operation within two minutes, the agent kills the proxy (this is by design), which may leave snapshots on the VM and any hot added disks attached to the vSphere Data Protection appliance.

    This is a known proxy issue, which will be fixed in a future release.

vCenter Server Issue

  • Canceling a manual restore to an existing VM causes "Consolidation Needed" on the existing VM (60084)

    Virtual machine disk consolidation is the root of the failure, and this will cause further backups to fail. Clean up needs to be implemented for the canceled restore operations.

    Workaround

    On vCenter Server, select and right-click the existing VM and select Snapshot > Consolidate. Note that it is possible to create a vCenter Server alarm to notify administrators when a VM is running from a snapshot. See VMware KB article 1018029 for details.
    1. Select the existing VM.
    2. Right-click the VM and select Snapshot > Consolidate.

Interoperability Issues

  • In a Virtual SAN 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.
     

  • Failed to import vSphere Data Protection disks stored in the Virtual SAN datastore (60306)

    In a Virtual SAN environment, VMware creates two folders in the Virtual SAN datastore for each VM. One is named after the virtual machines name and the other is named after the virtual machines UUID. All the VM files are saved in the UUID folder. In the VM name folder, symbolic links point to the files in the UUID folder. A failure occurs when a user attempts to import vSphere Data Protection disks from an old appliance using the symbolic links in the VM name folder.

    Workaround

    Storage vMotion the disks out of the Virtual SAN datastore to a regular datastore.

Installation Issue

  • During vSphere Data Protection installation, if the user clicks Previous on the vCenter Server registration screen with no values being entered, the system fails to register with vCenter Server and the installation fails (52385)

    Workaround

    Re-install vSphere Data Protection using the instructions in the "vSphere Data Protection Installation and Configuration" chapter of the vSphere Data Protection Administration Guide.

Upgrade Issues

  • Upgrading the vSphere Data Protection appliance from 5.5.10 to 5.5.11 requires upgrading the kernel (244133)

    Before you upgrade the vSphere Data Protection appliance from 5.5.10 to 5.5.11, upgrade the kernel of the vSphere Data Protection appliance that you want to upgrade. Otherwise, the upgrade fails.

    Workaround

    Perform the following steps to upgrade the vSphere Data Protection appliance kernel:

    1. From the vSphere Data Protection 5.5.11 installation package on the vSphere Data Protection appliance that you want to upgrade, copy the <vSphereDataProtectionHotfix_KernelUpgrade>.tar.gz file to any directory, for example, /root on the same vSphere Data Protection appliance.
    2. Extract the <vSphereDataProtectionHotfix_KernelUpgrade>.tar.gz file by running the following command:

      tar -zxvf <vSphereDataProtectionHotfix_KernelUpgrade>.tar.gz

    3. Go to the <vSphereDataProtectionHotfix_KernelUpgrade> directory.
    4. Add the execute permissions to the <vSphereDataProtectionHotfix_KernelUpgrade>.sh file by running the following command:

      chmod a+x <vSphereDataProtectionHotfix_KernelUpgrade>.sh

    5. Run the <vSphereDataProtectionHotfix_KernelUpgrade>.sh file:

      ./<vSphereDataProtectionHotfix_KernelUpgrade>.sh

      The vSphere Data Protection appliance restarts.

      The kernel is upgraded.

    6. Upgrade the vSphere Data Protection appliance by using the vSphere Data Protection 5.5.11 ISO image.

Single VMDK Issues

  • Existing thick eager-zeroed disks change to thick lazy-zeroed disks post expansion (55363)

    When extending a VMDK which is thick eager-zeroed, the extended part is only thick lazy-zeroed. If you need to grow your VMDK and you require your VMDK to be thick eager-zeroed, then use the parameters outlined in the following VMware blog:

    http://blogs.vmware.com/vsphere/2012/06/extending-an-eagerzeroedthick-disk.html
     

  • A single VMDK restore from a backup of a retired or replicated client to an existing VM is creating a new VM on vCenter Server (59743)

    When a user creates and replicates a backup from a different source appliance to a new appliance, two restore points exist: one from the backup job and the other as a result of the replicated client. If the virtual machine is deleted or removed from the vCenter Server inventory, a timestamp is appended to the backup that was created earlier. The user should now see two restore points: the backup of a replicated client and the backup of the retired (deleted or removed) client.

    Using the Restore Backup wizard, the user selects a single VMDK to be restored to an existing virtual machine. Once the restore job begins, rather than adding a new disk to the existing VM, the vSphere Data Protection appliance creates a new VM in the vCenter Server inventory. The expected behavior is the new disks are added to an existing VM rather than creating a new VM.
     

  • Incorrect behavior of the vSphere Data Protection Advanced appliance when more disks are added to the same SCSI slots (59774)

    The vSphere Data Protection Advanced 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.

vSphere Data Protection Appliance Issues

  • If a thin provisioned vSphere Data Protection reaches datastore capacity, then even after freeing up the datastore and creating more space, integrity check errors occur on the vSphere Data Protection appliance (41005)

  •  
  • vCenter Server events do not generate during initial configuration if the user modifies the vSphere Data Protection hostname or IP address (52677)

    Workaround

    Monitor the reconfiguration events on the vSphere Data Protection appliance console.
     

  • Unable to log in to vSphere Data Protection configuration utility after the first restart (56351)

    There are intermittent instances where the user is unable to log in to vSphere Data Protection configuration utility 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 in to the vSphere Data Protection virtual appliance and use the following commands to manually start and stop the vSphere Data Protection configuration utility services:

    emwebapp.sh --restart
  • The vSphere Data Protection appliance crashes and powers off when a thin-provisioned virtual machine is restored on a datastore with insufficient space (56386)

    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.
     

  • Import Disk: The Initial Configuration wizard always allocates the default of 4 vCPUs and 4 GB RAM (56534)

    Irrespective of imported capacity, which for vSphere Data Protection Advanced can be 2 TB, 4 TB, 6 TB, or 8 TB, by default, the wizard always allocates only 4 vCPU and 4 GB RAM. The import operation completes successfully, the vSphere Data Protection Advanced appliance is up and running, which could cause issues later in terms of being under-provisioned for memory. The expected behavior is the Initial Configuration wizard should set the default to the minimum Memory based on the capacity being imported, as it does when performing a fresh installation of vSphere Data Protection Advanced.

    Adjust the amount of allocated memory based on the information below. The minimum amount of memory per VM depends on the capacity.

    • 2 TB capacity--6 GB memory
    • 4 TB capacity--8 GB memory
    • 6 TB capacity--10 GB memory
    • 8 TB capacity--12 GB memory
       
  • Slow response from the vSphere Data Protection User Interface (56633)

    After using the vSphere Data Protection appliance 5.5.x for several days, the UI performance is significantly slower than when the appliance was first deployed. Specific areas where performance is an issue are as follows:

    • Initial connection to vSphere Data Protection after logging in to vCenter Server
    • Creating a new backup job
    • Expanding the list of Microsoft Exchange servers on the Backup wizard
    • Editing existing backup jobs
    • Refreshing the Restore tab
    • Browsing into a backup on the Restore tab

    In general, the time to load data depends on the number of jobs you are running concurrently.

    Workaround

    Restart the web services on the vSphere Data Protection appliance using the following command:

    emwebapp.sh --restart
     

  • Backups, restores to original location, and restores to new location operations work as expected on datastores with Chinese names. However, if a target virtual machine is on that datastore as a new disk, the restore to new location operation fails on datastores with Chinese names (56877)

    This is a known image proxy issue, which will be fixed in a future release.
     

  • Unable to access destination virtual machines for a single disk restore when multiple restore points are selected (59663)

    Restore points are created for two different virtual machines (for example, VM-1 and VM-2). On the Restore tab, a restore point of VM-1 is selected at the image level and a restore point of VM-2 is selected at the disk level. For the single disk restore point, the VMs are not visible in the hierarchy.
     

  • A password change on a configured vCenter Server instance is not allowed on the vSphere Data Protection appliance, even after the vCenter Server password has expired (59497)

    The vSphere Data Protection configuration utility does not allow a password change for the configured vCenter Server instance if backups are in a Running state on the server. If the user password on the configured vCenter Server instance 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 vSphere Data Protection appliance and then change the password.
       
    2. Restart the vSphere Data Protection appliance in the maintenance window, and then log into the vSphere Data Protection configuration utility and change the vCenter Server password from the vSphere Data Protection configuration utility.
       

  • The Retention Policy name is not updated after editing the backup job name (59708)

    When editing a backup job and modifying the name of the job using the Create Backup Job wizard, the new name is updated in the vSphere Data Protection user interface. When verifying if the group name, schedule, and retention policy name are also updated with the new name, the group name and schedule are updated, but the retention policy name is not.
     

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

    In this scenario, the user opens the vSphere Data Protection configuration utility, 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.
     

  • It is not possible to re-enter the Storage Expansion wizard (59901)

    If you close the browser while storage expansion is running, the application should allow the user to re-enter the Storage Expansion wizard while expansion is taking place and bring the user to the Ready to Complete screen. Currently, the user cannot re-enter the wizard.
     

  • Unable to connect to the vSphere Data Protection appliance from the vShpere Web Client after changing the vSphere Data Protection appliances password and network setting (198580)

    Workaround

    Wait 1 hour between changing the vSphere Data Protection appliances password and network setting.

Backup Issues

  • If a large backup job is created (~100 VMs), the backup job can take up to ten minutes to create (39456)
     
  • No proper error handling when running scheduled disk backup job of a VMDK which was migrated to another datastore (53880)

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

  • Backup jobs do not display on the Reports tab or the Backup tab (55105)

    Call Technical Support.
     

  • Scale inventory: Create backup job fails to include all clients when creating a job for a large number of virtual machine clients (56542)

    Intermittently (approximately one out of five attempts), when the user attempts to create a backup job of a container holding a large number of virtual machines, the vSphere Data Protection Advanced appliance reports back that a few clients could not be added to the backup job.

    Workaround

    Manually edit the backup job to add the few missing clients.
     

  • 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.

Restore Issues

  • If a virtual machine is deleted during a vSphere Data Protection restore operation, the virtual machine is not properly removed from the vSphere Data Protection inventory (35110)

    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.
     

  • When a larger size VM (with multiple disks) is restored over an existing smaller size VM (with one disk), the restore job completes but only one disk is actually restored (42560)

    The vSphere Data Protection appliance does not display this activity with an error message (for example: "not enough destination disks"). As a result, there is a possibility of data loss if all the disks are not restored and the user is not aware of it because no vSphere Data Protection event is generated. As a result, there is a possibility of data loss if all the disks are not restored and the user is not aware of it because no vSphere Data Protection event is generated.

    To perform the disk compatibility check, the disk size on the target machine and the size of the disks in the backup being restored must be known.
     

  • 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.
     

  • Restore fails when attempted to restore as new VM using previous name of the renamed VM (53712)

    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.
     

  • Attach existing storage to vSphere Data Protection: Restore pane shows multiple entries with the exact same name if import is done more than once against the same vCenter Server instance (53841)

    When a user performs more than one import in a single vCenter Server instance, the exact same name appears in the Restore pane for both restore point entries.
     

  • "Set Restore Option" during restore rehearsal is blank if you are not connected to the vSphere Data Protection appliance (54279)

    On the Set Restore Options page of the Restore a backup wizard, you can specify to where you want the backup restored (Restore to Original Location or Restore to New Location). The Set Restore Options page is blank, however, if you are not connected to the vSphere Data Protection appliance.

    Workaround

    Connect to the vSphere Data Protection appliance to use the Restore a backup wizard and its options.
     

  • Five to eight manual restores take 10 minutes or longer to submit and a client is missed (56707)

    Consistently, it takes 10 minutes to submit 5, 6, and 8 manual restores. In addition, the Web client fails to include one client from the overall number of restores. As a result, it is not possible to collect rates for 8 manual restores in parallel, since one of the jobs does not get submitted or times out.

File Level Recovery (FLR) Issue

  • Post-import, FLR login fails for the virtual machines that were backed up before import (52951)

    File level recovery (FLR) is not supported for the restore points which have been imported from previously-used vSphere Data Protection disks (as described in "Attaching Existing Storage in the vSphere Data Protection Administration Guide). This limitation does not apply to restore points that are created for any subsequent backups performed after the import.

Replication Issues

  • Client cache does not support multiple replication jobs (52052)

    Multiple replication jobs for the same MS-App client causes errors during execution if they are scheduled for the same time.

    Workarounds

    • Ensure that the start time for the replication jobs are staggered.
    • Do not put the same client in multiple replication jobs.

  • Multiple replication jobs for different VMs run in series and not in parallel (53112)

    The replication activity for multiple virtual machines should process in parallel. The sequential behavior occurs only when another replication job with the same clients is already running. In this case, the client replication task waits for the already-running replication job to complete.
     

  • Replicated backups cannot be replicated again (53152)

    The Replication wizard does not support replicating backups that have already been replicated from a different source server. Clients or restore points that have already been replicated from a different source server do not appear as available in the Create | Edit | Clone replication job wizard.

Microsoft Application (MS App) Issues

  • The loading time of individual databases for an MS-App client can take longer than expected (50334)

    After invoking the MS-App Backup wizard, browsing individual databases on the Backup Targets page takes longer than usual on the vSphere Data Protection Advanced appliance.
     

  • Client cache does not support multiple replication jobs (52052)

    Multiple replication jobs for the same MS-App client causes errors during execution if they are scheduled for the same time.

    Workaround

    1. Ensure that the start time for the replication jobs are staggered
    2. Do not put the same client in multiple replication jobs.
       
  • Selecting a folder for SharePoint restore does not select all existing subfolders in the browsing tree (53205)

    When selecting any folder for a Microsoft SharePoint restore, all existing subfolders do not display as available for selection. Although the subfolders do not display as available for restore, the restore process successfully restores all the subfolders in the folder.
     

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

    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.
     

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

    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.
     

  • 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 vSphere Data Protection Advanced appliances on vCenter Server, which is causing this issue.

Storage Management Issue

  • Backups to Data Domain systems fail due to the image proxy timing out (56199)

    There is a flag that determines the timeout value. The default timeout value is 300 seconds (5 minutes).

    Workaround

    Set the flag to a value different from the default timeout value, but there are no professional services available for vSphere Data Protection. Contact VMware Global Support Services (GSS) for assistance with changing this value.

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 vSphere Data Protection.

    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.
     

  • ABV: The status of scheduled verification job activity cannot be determined if the destination is in maintenance mode (55798)

    An error message appears, but there is no log activity.
     

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

    The following error appears 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.
     

  • 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 vSphere Data Protection 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.
     

  • For automatic backup verification (ABV) jobs, canceling a running ABV task activated from the Web Client does not remove the VDP_Verification virtual machine from the datastore (56665)

    When browsing the datastore specified as the destination for the new VM, the VDP_VERIFICATION_xxxx VM is still present on the datastore, even after refreshing the browser.
     

  • The host is not compatible with the virtual machine that it needs to restore and leaves behind orphaned virtual machines in the vCenter Server inventory (58985)

    Automatic backup verification (ABV) jobs that are incompatible with the host will fail, and failed ABV jobs leave behind orphaned virtual machines in the vCenter Server inventory.

    Workaround

    Manually delete or unregister the temporary virtual machines that remain in either the vCenter Server inventory or the datastore inventory.
     

  • Loading virtual machine data fails when trying to edit an ABV job (59834)

    To edit an automatic backup verification (ABV) job, the user launches the Create a new backup verification job wizard. On the Virtual Machines page of the wizard (the first page), when the user attempts to load virtual machine data, the Loading virtual machine data progress bar spins continuously and the VM data does not display.
     

  • ABV job fails to be submitted after the most recent backup has been deleted (59844)

    If the most recent backup (backup-N) is deleted, the user is unable to verify backups that occurred before backup-N.

    Workaround

    Create a new backup. With the new backup, the user will not encounter issues in verifying future backups.

Granular Level Recovery (GLR) Issues

  • A granular level restore (GLR) on a Microsoft Exchange server is allowed for clients that do not have the vSphere Data Protection Advanced Plug-in for Exchange GLR installed (56205)

    The GLR operation is now blocked when the vSphere Data Protection Advanced Plug-in for Exchange GLR is not installed.
     

  • When performing a granular level restore (GLR) on a Microsoft Exchange server, the destination mailbox field should be optional (56439)

    When the user restores to a single mailbox, the default value is to restore to the original location. The user interface does not allow an empty value for this field. If the user selects "restore to alternate location," every mailbox from that backup is restored to a single mailbox.

    Restoring a mailbox to its original location and restoring the original path to a different client is supported and working as designed. The inability to restore multiple mailboxes to their original locations is a known issue.

Fixed Problems

The following table lists the problems that have been fixed in this release of vSphere Data Protection:

Defect Number Description

245435

The following problems have been fixed as part of this defect:

  • DHE key exchange removal
  • Poodle (remove SSLv3)
  • Upgrade the kernel of vSphere Data Protection 5.5.11 appliance to 2.6u19 for fresh OVA build