vSphere Data Protection 5.5.7 (Update 2) | 09 OCT 2014
These release notes include the following topics:
Benefits and Features
Read about the benefits and features of this product at the following
For information on supported environments, see the VMware Interoperability Matrix.
Known Issues in vSphere Data Protection 5.5.7
The following known issues have been discovered through rigorous
testing. The issues below pertain to vSphere Data Protection (VDP)
Bash Code Injection Vulnerability (aka "Shellshock")
- vSphere Data Protection 5.5.7 (Update 2) might use the Bash shell which is part of the Linux operation system.
In case the operating system has a vulnerable version of Bash, the Bash security vulnerability might be exploited through vSphere Data Protection.
After installing VDP 5.5.7, you should immediately apply the patch to address the Shellshock vulnerability as described in http://kb.vmware.com/kb/2091341.
- 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
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 VDP virtual
appliance and snapshots are not removed.
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 VDP appliance.
This is a known proxy issue, which will be fixed in a future release.
- Canceling a manual restore to an existing VM causes
"Consolidation Needed" on the existing VM.
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: From the vCenter, 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.
- Select the existing VM.
- Right-click the VM and select Snapshot >
- 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.
- Failed to import VDP disks stored in the vsanDatastore.
In a VSAN environment, VMware creates two folders in the
vsanDatastore for each VM. One is named after the virtual machine's
name and the other is named after the virtual machine's 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 VDP disks from an old appliance using the
symbolic links in the VM name folder.
Workaround: Storage vMotion the disks out of the vSAN datastore to a
Single VMDK Issues
- Existing thick eager-zeroed disks change to thick lazy-zeroed
disks post expansion.
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:
- A single VMDK restore from a backup of a retired or replicated
client to an existing VM is creating a new VM on the vCenter Server.
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 VDP Appliance
creates a new VM in the vCenter inventory. The expected behavior is the
new disks are added to an existing VM rather than creating a new
- Incorrect behavior of the VDP Advanced Appliance when more disks
are added to the same SCSI slots.
The VDP 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.
General VDP Appliance Issues
- 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.
- vCenter events do not generate during initial configuration if
the user modifies the VDP hostname or IP address.
Workaround: Monitor the reconfiguration events on the VDP
- 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
- 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
- Import Disk: The Initial Configuration wizard always allocates
the default of 4 vCPUs and 4 GB RAM.
Irrespective of imported capacity, which for VDP 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 VDP
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 VDP 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 VDP User Interface
After using the VDP 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
- Initial connection to VDP after logging in to the vCenter
- Creating a new backup job
- Expanding the list of Microsoft Exchange servers on the Backup
- 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 VDP Appliance using the
- 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
This is a known image proxy issue, which will be fixed in a future
- Unable to access destination virtual machines for a single disk
restore when multiple restore points are selected.
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 is not allowed
on the VDP Appliance, even after the vCenter Server password has
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:
- Wait until all the backups and tasks finish in the VDP Appliance
and then change the password.
- 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 Retention Policy name is not updated after editing the backup
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 VDP 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.
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.
- It is not possible to re-enter the Storage Expansion wizard.
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
- Unable to connect to the VDP Appliance from the vShpere Web
Client after changing the VDP Appliance's password and network
Workaround: Wait 1 hour between changing the VDP Appliance's
password and network setting.
- If a large backup job is created (~100 VMs), the backup job can
take up to ten minutes to create.
- 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
- Backup jobs do not display on the Reports tab or the Backup tab.
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.
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 VDP 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
- 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
- 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.
- 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. The VDP 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 VDP event is generated.
In order 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.
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.
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
- Attach existing storage to VDP: Restore pane shows multiple
entries with the exact same name if import is done more than once
against the same vCenter Server.
When a user performs more than one import in a single vCenter Server,
the exact same name appears in the Restore pane for both restore point
- "Set Restore Option" during restore rehearsal is blank if you are
not connected to the VDP Appliance.
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 VDP Appliance.
Workaround: Connect to the VDP 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.
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
- Client cache does not support multiple replication jobs.
Multiple replication jobs for the same MS-App client causes errors
during execution if they are scheduled for the same time.
- 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
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.
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.
After invoking the MS-App Backup wizard, browsing individual
databases on the Backup Targets page takes longer than usual on the VDP
- Client cache does not support multiple replication jobs.
Multiple replication jobs for the same MS-App client causes errors
during execution if they are scheduled for the same time.
- Ensure that the start time for the replication jobs are
- Do not put the same client in multiple replication
- Selecting a folder for SharePoint restore does not select all
existing subfolders in the browsing tree.
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
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.
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.
The Microsoft Exchange client is left registered with two VDP
Advanced Appliances in the vCenter, which is causing this
Storage Management Issue
- Backups to Data Domain systems fail due to the image proxy timing
There is a flag that determines the timeout value. The default
timeout value is 300 seconds (5 minutes). The workaround is to set the
flag to a value different from the default timeout value, but there are
no professional services available for VDP. Contact VMware Global
Support Services (GSS) for assistance with changing this
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.
- ABV: The status of scheduled verification job activity cannot be
determined if the destination is in maintenance mode.
An error message displays, but there is no log activity.
- 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
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.
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.
- For automatic backup verification (ABV) jobs, cancelling a
running ABV task activated from the Web Client does not remove the
VDP_Verification virtual machine from the datastore.
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
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 inventory.
Workaround: Manually delete or unregister the temporary virtual
machines that remain in the vCenter or datastore inventory.
- Loading virtual machine data fails when trying to edit an ABV
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
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 VDP Advanced Plug-in for
Exchange GLR installed.
The GLR operation is now blocked when the VDP 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.
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
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.
Resolved Issues in vSphere Data Protection 5.5.7
The following issues have been resolved since the last release of
vSphere Data Protection:
- Out-of-date sources for a failed or cancelled Application
database backup displays incorrect count.
The difference between the sources count and the out-of-date sources
count is common for Microsoft SQL and Exchange application database
- OpenSSL has multiple vulnerabilities including man-in-the-middle
(MITM) and denial of service (DoS) attacks
All versions of OpenSSL clients are vulnerable to MITM and DoS
attacks. OpenSSL servers are only known to be vulnerable if running
OpenSSL 1.0.1 and 1.0.2-beta1. To fix this issue, the OpenSSL server in
vSphere Data Protection has been upgraded to 1.0.1h. More information
about this issue is available from OpenSSL: