|vSphere Data Protection 6.0.6 Release Notes | 21 November, 2017|
These release notes include the following topics:
Benefits and Features
The vSphere Data Protection 6.0 Administration Guide provides information about benefits and features of vSphere Data Protection.
For information about supported environments, see VMware Interoperability Matrix.
Note: vSphere Data Protection 6.0.6 supports vCenter Server 6.0 Update 3, and does not support vCenter Server 6.5.x.
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 Virtual SAN 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 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 Protection 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 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.
- Root login to vSphere Data Protection 5.8 is disabled (1309755)
Root login to vSphere Data Protection 5.8 is disabled because it is not a best practice. An option is needed to enable ssh root login. If no activity occurs in the shell, the shell is set to time out after 15 minutes. 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, and then use the sudo command to perform root functions.
If no activity occurs in the bash shell, it (in the /etc/profile directory) is set for a 15-minute timeout. You can add the console timeout value using the hardening script. For example:
- Powering on a VM fails when the backed up VM was connected to DVS and restored to another ESXi host (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 ESXi 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.
- 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)
Either restore the entire VM with an image-level backup or restore the disk level backup as a new disk on the original VM.
- Upgrading the vSphere Data Protection appliance from 5.5.10, 5.8.2, 6.0.2, or 6.0.3 to 6.0.4 requires upgrading the kernel (244133)
Before you upgrade the vSphere Data Protection appliance from 5.5.10, 5.8.2, 6.0.2, or 6.0.3 to 6.0.4, 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.4 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:
chmod a+x <vSphereDataProtectionHotfix_KernelUpgrade>.sh
- 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.4 ISO image.
- Incorrect behavior of the vSphere Data Protection appliance when more disks are added to the same SCSI slots (59774)
The vSphere Data Protection 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 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 configuration utility.
- 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.
- 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 vdr-server.log:
javax.net.ssl.SSLHandshakeException:java.security.cert.CertificateException: 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 Server certificate.
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 following 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 the ESXi host is moved from one datacenter to other within the same vCenter Server inventory (207375)
After you move an ESXi 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 --domain=/vCenter_Server_IP_address
- 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. 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 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 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 prompted.
- 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 chain.
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 authorization domain.
In addition, the failure occurs with the following source/target combinations:
- 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 Protection Advanced
- Replication Recovery: Replication logs are filling up the root partition - need to create a symlink to another partition (195196)
The replication logs are currently going to the
/spacepartition and not to the
Manage the replication logs in the
/usr/local/Avamar/var/clientdirectory (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.
Operating System Issues
- Granular Level Restore (GLR) of any Microsoft application fails on Windows Server 2008 and Windows Server 2008 R2 (243196)
Note: This workaround applies only to Windows Server 2008 R2.
Install the Windows update 3033929 from the following location:
https://support.microsoft.com/en-us/kb/3033929 provides information about the Windows update 3033929.
Microsoft Application Issues
- 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 in vCenter Server, 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 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.
- SharePoint virtual directories are not restored (248324)
Performing a full backup of a web application does not back up the SharePoint virtual directories. So, if you delete the source web application and the SharePoint virtual directories, and restore the backed up web application, the SharePoint virtual directories are not restored. You cannot open the sites that are under the web application.
- Back up the full image of virtual machine.
- To restore the required virtual directories, perform a File Level Restore of the backed up virtual machine image.
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.
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:
|287343||Upgrade the JRE version to 1.8.0_144, that is, JRE 8u144.|
|287342||Upgrade the Tomcat version to 7.0.81.|
|PSRC-3939||Fix GraniteDS vulnerability.|
|288751||Add Q2 2017 OS Rollup to vSphere Data Protection 6.0.6 to fix security vulnerabilities.|
|289102||Results of FLR of the same files are unreliable.|
|287770||On vSphere Data Protection 6.1, SQL redirected restore fails to locate a new folder or drive.|
|289293||vSphere Data Protection restore does not automatically select the hotadd proxy, but selects a non-hotadd proxy.|
|289826||After upgrading vSphere Data Protection from 6.0.4 or 6.0.5 to 6.0.6-27, the vSphere Data Protection plug-in is not visible on vCenter Server.|