|vSphere Data Protection 6.0.3 Release
Notes | 10 November, 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
of vSphere Data Protection:
- Image backup fails for powered-on virtual machine running on
Virtual SAN datastore (1281041)
An image backup fails for powered-on
virtual machines running on a Virtual SAN datastore, where both the
vSphere Data Protection appliance and the virtual machine are running on the same
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
vSphere Data Protection appliance and vCenter Server (1292848)
When configuring the
network for the vSphere Data Protection appliance and vCenter Server, 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 vSphere Data
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 vSphere Data Protection 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:
- 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 Server 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.
- Upgrading the vSphere Data Protection appliance from 5.5.10, 5.8.2, or 6.0.2 to 6.0.3 requires upgrading the kernel (244133)
Before you upgrade the vSphere Data Protection appliance from 5.5.10, 5.8.2, or 6.0.2 to 6.0.3, upgrade the kernel of the vSphere Data Protection appliance that you want to upgrade. Otherwise, the upgrade fails.
Perform the following steps to upgrade the vSphere Data Protection appliance kernel:
- From the vSphere Data Protection 6.0.3 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.
- Extract the <vSphereDataProtectionHotfix_KernelUpgrade>.tar.gz file by running the following command:
tar -zxvf <vSphereDataProtectionHotfix_KernelUpgrade>.tar.gz
- Go to the <vSphereDataProtectionHotfix_KernelUpgrade> directory.
- Add the execute permissions to the <vSphereDataProtectionHotfix_KernelUpgrade>.sh file by running the following command:
- Run the <vSphereDataProtectionHotfix_KernelUpgrade>.sh file:
The vSphere Data Protection appliance restarts.
The kernel is upgraded.
- Upgrade the vSphere Data Protection appliance by using the
vSphere Data Protection 6.0.3 ISO image.
- Incorrect behavior of the vSphere Data Protection appliance when more disks are
added to the same SCSI slots (59774)
The vSphere Data
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 Issues
- 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 you cannot cancel the tasks.
Perform the following steps:
- Wait until all the backups and tasks finish in the vSphere
Data Protection appliance and then change the password.
- 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
- The Performance Assessment Test (PAT) result changes to Never
Run when the datastore name is changed (59784)
scenario, the user opens the vSphere Data Protection configuration
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.
- vSphere Data Protection server is prone to man-in-the-middle attack (197873)
After you enable the SSL configuration to secure a connection
between vCenter Server and vSphere Data Protection, a user is unable to connect from the
vSphere Data Protection
plug-in. As a result, the following error appears in the
No subject alternative names matching IP address x.x.x.x found
vCenter Server is registered to vSphere Data Protection by using a
vCenter Server IP
address. No subject alternate name is available in the vCenter
Use one of the following workarounds:
- Regenerate the self-signed vCenter Server certificate and add the
subject alternate name to include the IP address.
- Reregister vCenter Server with vSphere Data Protection by using the fully qualified
hostname that was provided in the vCenter Server 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,
vSphere Data Protection 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 the same vCenter Server 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_Server_IP_address
- If a virtual machine is deleted during a vSphere Data
operation, the virtual machine is not properly removed from the
vSphere Data Protection
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 that 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: vSphere Data Protection Advanced and Target Server:
vSphere Data Protection Advanced
/ Replication Target Identity (RTI)
- Source server: RTI and Target Server: RTI / vSphere Data
- 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 vSphere Data Protection Advanced appliances in vCenter
Server, 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 vSphere Data Protection Advanced appliance to the current
vSphere Data Protection
Advanced appliance, the backup agent service logon user is reset to
Local System, rather than Backup User.
From vSphere Data Protection 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 vSphere Data Protection.
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 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.
The following table lists the problems that have been fixed in this
release of vSphere Data Protection:
The following problems have been fixed as part of this defect: