|vSphere Data Protection (VDP) 6.0.1 Release
Notes | 19 MAY 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 the
VMware Interoperability Matrix.
Known Issues in VDP 6.0.1
The following known issues have been discovered through rigorous
testing. The issues pertain to vSphere Data Protection (VDP) 6.0.1.
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
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.
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 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
- 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:
- For Linux vCenter Appliance:
scp file /etc/vmware-vpx/ssl/rui.crt
and /etc/vmware-vpx/ssl/rui-ca-cert.pem from vCenter
appliance into /usr/local/avamarclient/bin on the proxy
- For Windows vCenter:
VirtualCenter\SSL\rui.crt and c:\ProgramData\VMware\VMware
VirtualCenter\SSL\cacert.pem into /usr/local/avamarclient/bin
on the proxy.
NOTE: If a chained SSL certificate is used for the
vCenter, copy the chain.pem file, which contains all
certificates in the chain, to /usr/local/avamarclient/bin on
- 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"
vix.sslCertificateFile = "/usr/local/avamarclient/bin/rui-ca-cert.pem"
- 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 (222670)
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
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
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
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
- 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 the
- 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.
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)
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)
Either restore the entire VM with an image-level
backup or restore the disk level backup as a new disk on the
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)
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
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
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
To work around this issue, perform one of the following steps
before you run a manual backup of the VM:
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)
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.
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
Restore backup of
secondary replica failed or aborted with log gap error (197652 CLONE:
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
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.
replicated clients under a particular tenant on the target server
The replication of replicated clients from a source to a target
server under a particular tenant account fails with the following
Specified account ( ) does not fall within the current
In addition, the failure occurs with the following source/target
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
partition and not to the
Manage the replication logs in the
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
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
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
Automatic Backup Verification (ABV) Issues
ABV: Verification job fails after renaming the
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
Resolved Issues in VDP 6.0.1
The following table lists the issues that have been resolved in VDP 6.0.1:
||The delete and edit operations on a VDP appliance that has more than
15 backup jobs take more than 10 minutes each to complete.
||CPU consumption does not decrease after an email schedule has been
triggered for longevity scale setup.
||VDP takes a long time to open jobs such as, backup, automatic backup
verification, and replication for editing.
||The browsers that end trust for SHA-1 SSL certificates for VDP
||The backup job status incorrectly appears in VDP on the vSphere web
client and the email summary report.
||VDP crashes while creating or performing backup jobs.