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
For information on supported environments, see
VMware Interoperability Matrix.
Known Problems and Limitations
The following are the known problems and limitations in this release
- 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
- 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
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)
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.
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:
- 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.
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
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
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
- Open a command shell and log in to the proxy as root.
- 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
- 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.
- 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:
- Open /usr/local/avamarclient/var/avvcbimageAll.cmd in a UNIX
- 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.
- Save your changes and close avvcbimageAll.cmd.
- Open /usr/local/avamarclient/var/avvmwfileAll.cmd in a UNIX
- 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.
- Save your changes and close avvmwfileAll.cmd.
- Open /etc/vmware/config in a UNIX text editor.
- Append the following lines to the end of the file:
vix.enableSslCertificateCheck = "true"
- Save your changes and close /etc/vmware/config.
- Open /usr/local/avamarclient/var/vddkconfig.ini in a UNIX
- Find the vixDiskLib.linuxSSL.verifyCertificates=0 entry.
- Change the vixDiskLib.linuxSSL.verifyCertificates=0 entry to
- Save your changes and close vddkconfig.ini.
- Ensure that no backup or restore jobs are running on this
- Restart the avagent and vmwareflr services by typing the
service avagent-vmware restart
service vmwareflr restart
- Service Stop/Start buttons become unavailable on
Configuration page, when you run emwebapp.sh --restart from CLI
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
- 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
- From a web browser, access the vSphere Web Client:
- Select vCenter > Hosts and Clusters.
- Select the DRS tab.
- Select the Manual checkbox for all DRS clusters
listed in the left menu.
- Select Inventory > Datastores.
- For each datastore where VMs, proxies, and VDPs reside, do
- Select the datastore.
- Select Edit Settings.
- On the left menu under General, click SDRS
- In the right panel, select No automation (Manual).
- Select Virtual Machine Settings.
- Ensure that all VMs show Disabled or Manual
for the SDRS Automation.
- Cannot replicate Imported image backups (224280)
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
- 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.
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 Performance Assessment Test (PAT) result changes to Never
Run when the datastore name is changed (59784)
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
No subject alternative names matching IP address x.x.x.x found
The vCenter server is registered to VDP by using a vCenter IP
address. No subject alternate name is available in the vCenter
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)
Restart the emwebapp.sh service by running the
emwebapp.sh -restart command.
- 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
- 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)
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)
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
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
- 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
- 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
There is no data loss.
Perform a full backup. Ensure the "Force incremental backup after
full backup" backup option is unchecked.
- 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
In addition, the failure occurs with the following source/target
- 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
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
The Microsoft Exchange client is left registered
with two VDP Advanced Appliances in the vCenter, which is causing
- 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
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.
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)
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.
The following table lists the problems that have been fixed in this
release of VDP:
||The browsers that end trust for SHA-1 SSL certificates for VDP require update.
||GNU C Library (glibc) update for VDP 6.0.2.