vSphere Data Protection 5.5.5 | 14 NOV 2013
These release notes include the following topics:
Benefits and Features
Read about the benefits and features of this product at the following links:
For information on supported environments, see the VMware
The following known issues have been discovered through rigorous testing. The list of issues below pertains to this release of vSphere Data
- The VDP Advanced plug-in switches back to VDP when the ESX host license cannot be determined.
VDP Advanced switches back to VDP for several reasons:
- The user deploys a VDP Advanced plug-in on an ESX host with an evaluation license. After the VDP Advanced Appliance is running, the license is changed from an evaluation license to an Essentials Plus license and the Switch to VDPA action generates an error.
- The user deploys a VDP Advanced plug-in on a corrupt vCenter and the licensing service does not respond.
- Licensing: The VDP Advanced license expiration date is always None if the VDP Advanced appliance is registered to a non-English vCenter .
When a VDP Advanced Appliance is registered to a non-English vCenter, the plug-in will always display the expiration date as "None" for evaluation licenses. Once the appliance is registered to an English vCenter, the issue no longer exists.
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 Appliance console.
- Upon successful upgrade to VDP 5.5.x, the user will see two plug-ins listed on the left pane of the vCenter.
When the upgrade installs successfully, two plug-ins appear on the left pane of the vSphere Web Client. VDP versions 5.1 and earlier are managed using the vSphere Data Protection plug-in. VDP version 5.5 is managed using the vSphere Data Protection 5.5 plug-in.
NOTE: Two plug-ins also appear if a VDP Appliance version 5.5 is installed and a version earlier than 5.5 already exists.
To remove the vSphere Data Protection plug-in, you must upgrade all VDP Appliances to VDP version 5.5 and use the plug-in manager to disable the VDP plug-in.
Refer to the VMware vSphere Documentation Center web site for information about managing vCenter plug-ins.
- The VDP Appliance plug-in installers cannot be downloaded using the latest Google Chrome browser version.
Workaround: Update the Chrome browser version to 29.0.1547.66. After the download completes, perform one additional refresh action.
- There are broken links on the Getting Started page.
This is a known issue and will be fixed in a future release.
- 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: Use the following commands to manually start and stop the vdp-configure services:
- The VDP Appliances crashes and powers off when a thin-provisioned virtual machine is restored on a datastore with insufficient space.
It does not matter on which datastore the appliance resides, nor does it matter on which datastore the VM is restored. The issue is related to the transport mode. 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.
- Poor performance of 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. The slow performance is inconsistent (for example, an operation may take thirty seconds or five minutes to complete). Specific areas where performance is an issue are as follows:
- 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 wizard
- 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 appliance and note if there are performance improvements with specific tasks.
- If a large backup job is created (~100 VMs), the backup job can take up to ten minutes to create.
- Image backup and VMDK backup job of VM with SCSI bus-sharing enabled is allowed, but fails, and the job task does not appear in the vCenter.
The following VMware knowledge base article states that snapshots are not supported for SCSI bus sharing VMs:
Workaround: If you require bus-sharing, follow the instructions in the Resolution section of the knowledge base article.
- Backups that are 2 TB or larger in size fail silently and falsely report as successful on Windows virtual machines with disk.EnableUUID=true.
This issue is deferred to VDDK 5.5.U1 for a fix. Windows support for VMs greater than 2 TB is dropped from the product until the issue is resolved.
- 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 occurs.
- Backup jobs do not display at all on the Reports tab or the Backup tab.
Workaround: Call Technical Support.
- Scale inventory: Create 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 clients.
- Edit backup job wizard: Unable to locate the VM if the VM name has the same name as its resource pool.
If the virtual machine name has the exact same name as the resource pool in which it resides, the VDP Appliance displays an error message when the user edits the backup job:
The following items could not be located and were not selected: <VM-name-here>. Functionally, the backup jobs continue to run properly.
Workaround: After the error message is received, it is possible to locate and select the VM through the Edit backup job wizard. To avoid the issue entirely, you may rename either the Resource Pool or the virtual machine so that they do not have the same name.
- Moving a VM to a resource pool results in a "VM not found" error when editing the backup job.
The user receives an error message when trying to edit a backup job if a VM was initially in one container, but later moved to a different container. Functionally, the backup job continues to run properly.
Workaround: After the error message is received, locate and select the VM through the Edit backup job wizard.
- 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 names.
This is a known image proxy issue, which will be fixed in a future release.
- Cannot create a user name with more than 20 characters using the VMware VDP Exchange Backup User Tool.
Workaround: Create a user name with 20 characters or less.
- 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 discrete hard 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 already exists.
- 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.
When a user performs more than one import in a single vCenter, the exact same name appears in the Restore pane for both restore point entries.
- "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.
- SCSI ID Restore: Unexpected error occurs when a disk is restored to the same or alternate powered-on VM
The error message when a user restores the disk to its original location (and the disk VM is in a powered-ON state) is as follows:
An unexpected error occurred with the following error code:
More information may be available in the client logs which can be downloaded from the configuration application (https://:8543/vdp-configure).
- The Restore tab does not refresh when connecting to a different VDP Appliance.
On a vCenter with multiple VDP Appliances, when the user connects to the first VDP Appliance and disconnects (All Actions > Disconnect), and then connects to the second VDP Appliance, the backups from the first VDP Appliance display. If the user browses into one of the backups on the first VDP Appliance, an error displays.
Workaround: Click the Refresh button from within the Restore tab.
- SCSI ID Restore: Unable to restore deleted/removed disk to the same VM.
To reproduce this issue, a backup of a virtual machine with two or more disks is taken. After the backup completes, one of the disks is deleted or removed. From the Restore tab, the deleted disk is selected and the user clicks on Restore. In the Set Restore Options, by default, "Restore to original location" is unchecked. The user selects an empty slot and initiates the restore. The restore operation completes successfully, but in the VM, no new disk is added or restored.
- 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.
- A validated VM when restored under a protected container should not be included in a backup job.
A temporary virtual machine (that is, a VM with a prefix of
VDP_Verifying in the name) should not be included in a backup job. Users should not back up virtual machines created by the Automatic Backup Verification (ABV) feaure. For example, if the user creates a backup job on a host and also selects this host as the destination for an ABV job, the result can be erroneous data that is generated on the server and these VMs will show up as replicated sources.
- The SCSI ID that is already assigned to device is listed in the Restore Wizard. The user is allowed to select the assigned SCSI ID when restoring an individual virtual machine disk (VMDK).
Workaround: Do not select the SCSI slot that is assigned to any existing device as the target for disk restores.
- Failure to create disk restore jobs when SCSI Controller ID numbers are not continuous on the target virtual machine (VM).
For example, if the target VM has SCSI Controller 0 and 3, and the user tries to restore a disk to an empty slot on SCSI Controller 3, the operation fails with an error.
Workaround: Either restore the disk to SCSI Controller 0 or make sure the target VM has all the SCSI Controllers starting with 0 to the one you want to restore (0, 1, 2, 3).
- SCSI ID: The disk restore of a retired or a replicated VM onto an existing VM creates a new VM.
When a user initiates a SCSI ID restore of retired virtual machine disks onto an existing VM, instead of adding the disks to the selected VM, it creates a new VM by attaching all the selected disks to it.
Workaround: After performing a restore, manually attach the restored disk to its original (existing) virtual machine.
- 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, if created in a single job, run in series and not in parallel.
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.
- Unable to replicate backups from imported disks.
Imported backups (that is, backups that were created with a previous appliance from where disks were imported to a new appliance) cannot be replicated. You can only replicate VM clients that have a current VM client registration.
This is a known limitation of storage import and will be fixed in a future release.
- 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:
Microsoft Application (MS App) Issues
- 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.
- The "Allow database overwrite" option is not sent to "true" in the Microsoft Exchange server and the restore fails.
Workaround: When restoring databases, set the "Allow Database overwrite" option to "true." For instructions, refer to the "Restoring Backups of Microsoft Exchange Servers" section (advanced options) of the vSphere Data Protection Administration Guide.
- The "Restore into RSG/RDB" option is not sent to "true" in the Microsoft Exchange server and the restore fails.
Workaround: When restoring databases, set the "Restore into RSG/RDB" option to "true." For instructions, refer to the "Restoring Backups of Microsoft Exchange Servers" section (advanced options) of the vSphere Data Protection Administration Guide.
- MS-Apps backups and restore requests do not complete and the jobs fail to start.
The Event Manager does not offer useful details about the request failure. Retrying the operation usually results in a successful backup or restore. The cause of this issue is currently unknown.
- SQL instance warning on Application DB backup wizard should be removed for invalid cases.
When creating an instance-level backup of a Microsoft SQL server, the Create a new backup wizard displays the following error message:
The selection of a SQL server instance as a backup target will result in backing up only the database(s) currently present. Future modification to this instance will require modification of the backup job.
This warning message is not correct. If the user creates an Application database backup without expanding the instance, the backup group automatically picks up the newly-added database and backs it up. Therefore, the above warning is invalid.
- An unregistered client for a SQL server application database backup displaysthe Sources count incorrectly.
The application database backup for a Microsoft SQL server displays the client count of zero for an unregistered client backup, even though an MS-App server has been added to the backup job. For the same unregistered client, a full server backup (rather than a database backup) shows the Sources count correctly.
- Microsoft SharePoint redirected restore job fails for the database if the IP address is used as an alias instead of the server name.
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.
- The loading time of individual databases for an MS-App client is unacceptable.
After invoking the MS-App Backup wizard, browsing individual databases on the Backup Targets page takes longer than usual on the VDP Advanced Appliance.
- On Microsoft Exchange servers, the Location path field is not validated when the entire backup is selected for restore.
Validation is not performed on the Location path field (the text box does not turn red when the field is left empty, nor does a tooltip display). When selecting individual databases for restore, however, the validation works as designed.
- 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 backups.
- Client cache does not support multiple replication jobs.
The cache file locks for an MS-App client when simultaneous replication jobs are started for the same client from different groups. The client cache does not support multiple replication jobs and it reports the cache file as locked.
- Ensure that the start time for the replication jobs are staggered.
- Do not put the same client in multiple replication jobs.
- The "Restore into RSG/RDB" option fails when the user specifies the data path rather than the log path.
Workaround: Specify the RSG/RDB log path (the path where the RSG/RDB log file will be restored; for example, C:\myrdb) rather than the RSG/RDG database path. Refer to "Restoring Backups of Microsoft Exchange Servers" in the vSphere Data Protection Administration Guide for more information.
NOTE: The user can leave both the log path and the database path fields blank. If both fields are left blank, the restore defaults to its original location.
- 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 issue.
System Management Issues
- Backups to Data Domain systems fail due to the image proxy timing out.
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. Therefore, we recommend contacting Technical Support.
- Unable to perform storage expansion unless CPU hotplug is enabled, even if the user decides not to increase the vCPU count.
When expanding disk storage, the CPU hot plug must be enabled on the virtual machine. CPU and Memory hotplug is enabled by default in version 5.5.5. Previously, users could perform storage expansion even if CPU hotplug was disabled.
- 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. 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
Automatic Backup Verification (ABV) Issues
- ABV: The Clients report doesn't filter for "is within the last" 60 minutes.
The minutes filter is not working as expected. Though the Clients report does not filter for "is within the last" 60 minutes, it does report for the last 1 hour. This issue exists for both backup jobs and backup verification jobs.
- The host is not compatible with the virtual machine that it needs to restore and leaves behind orphaned virtual machines in the vCenter inventory.
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.
- 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: 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 not successful:
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.
- 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.
- 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.
- ABV: A plug-in error is received when the destination host is in the Disconnected state.
It is expected for the Verification job to fail if the destination host is disconnected; 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.
- ABV: Scheduled verification tasks get stuck at 92% if the host becomes disconnected during the operation.
If the destination host to which the temporary virtual machine is being restored gets disconnected, the scheduled verification task gets stuck at 92%.
Workaround: Manually cancel the task and, if the task cannot be cancelled, restart the vCenter web services or the VDP Appliance using the following command:
File Level Recovery (FLR) Issues
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 mailbox.
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.
The following issues have been resolved:
- Expiration time for a backup is not consistent for a scheduled backup and an ad hoc backup.
The expiration time for the same backup job is not always the same if the backup job with a custom retention policy executes on demand.
- The Cluster Configuration Tool appears as a shortcut from the Start menu.
Disabled the av_cluster_config_wizard.exe shortcut so that it no longer displays in the Start menu.
- The Restore pane reflects the timestamps as per the time zone of the client machine where the vSphere Web Client is launched.
- ESX host license vCloud Service Provider license returned a "not licensed" for the VDP and VDP Advanced Appliances.
This issue was introduced because the License Edition for this ESX Host license was not checked in the VDP or VDP Advanced Appliance. The logic has been updated to validate the license; therefore, this issue is resolved.
- During VDP installation, VDP fails to show the current free space in the Device allocation screen if the user logs out, frees up space in the datastore, and logs in again to the VDP-Configure wizard.
Workaround: Log out from the VDP-Configure session, clear the browser cache, and log in again. The device allocation should now display the current free space.
This issue is resolved in this release.
- Ad-hoc replication from the Reports tab replicates other VM backups.
If an ad-hoc replication job is performed from the Reports tab, backups for other virtual machines that are present in the replication job are also replicated.
- After an MCS restart, the Last Run Time and Duration values of a previously-executed Replication job changes to the default value.
After restarting the management services for a 5.5 version of the VDP Appliance, the Last Run Time and Duration values on the Replication tab for a previously-executed replication job changes to the default value of Never.
- The VDP Appliance creates a restore point for VM clients on the Restore tab that are associated with cancelled backup tasks.
Backup jobs that are cancelled on the VDP Appliance from the Web Client are not synchronous with reported cancel action results. As a result, the VDP Appliance erroneously creates a restore point for the canceled VM clients in the backup job.
- Image restore as new fails for disks larger than 2 TB.
The restore image as new feature fails only in a thick disk configuration where the disk is backed up to a SAN datastore and then restored to the same datastore, which consumes too much disk space. This issue does not exist on thin disk clients.
- Alarms are raised during second boot.
After finishing the configuration and subsequently restarting the VDP appliance, intermittent alarms are raised during the second boot process. An example of this alarm is "VDP:  File level restore services are not running".
If this occurs, please allow for the boot process to complete and then manually acknowledge and clear the alarm. While these alarms are valid at the time they are raised, the boot process resolves the situation.
- Attach existing storage to VDP: If the integrity check takes a long time to run, the configure task gets stuck at 80 percent and does not mark the task as complete.
The VDP Appliance will complete the configuration successfully, even in cases where the integrity check takes a very long time to run.
- Scalability: Web Client UI loses connection with VDP timing out, while submitting more than 10 restores.
If you restore more than ten backups in a single restore job, the UI times out and loses connectivity with the VDP Appliance.
- Attach existing storage to VDP: Message when trying to import a non-data disk can be reworded.
Attempting to import non-data disk of VDP currently shows the following error message: Selected disk is not a valid disk.
The message should be reworded to the following error message: Selected disk is not a valid data disk.
- Filtering option at Restore page filter fails if user wants to make multiple selections among several backups.
When the user navigates to the Restore page and attempts to restore multiple virtual machines, the back arrow filter functionality fails. After the user clicks the first VM, he must manually navigate back to select subsequent VMs.
- Rollback to a validated checkpoint for the VDP Appliance fails after vCenter change.
When the user changes the hostname or the IP address of the vCenter server and then logs into VDP-Configure to perform a rollback on the VDP Appliance, the rollback fails. This issue is resolved in this release.
As a best practice, after successful vCenter configuration when all the VDP services are up, manually run an integrity check, which creates a valid checkpoint. If required, you can then perform a rollback to that checkpoint.
- Restore at the disk level is failing when the destination is selected as a vApp or a Resource Pool inside a 2-node cluster.
The user is not able to restore a VMDK while choosing the destination as a vApp or a Resource Pool in a 2-node host cluster.
Workaround: Rerun the restore job and choose a standalone ESXi Host or ESXi Host cluster as the destination. After the restore job completes, you can manually add the restored VM into the vApp or Resource Pool.
- During VDP installation, the Add Disk operation silently fails if the datastore is deleted or renamed before clicking Yes on the storage configuration confirmation dialog.
Renaming or deleting the datastore which was selected to store the VDP data disks invalidates the Add Disk operation. Even though the Add Disk operation failed, the system falsely reports a successful operation. The disks do not attach to the VDP Appliance, yet the system prompts the user to reboot.
By default, the option "Store with Appliance" is checked, which deploys the disks on the same datastore when deploying the VDP Appliance. This issue occurs only when the user clears the Store with Appliance option and selects a different datastore.
- During VDP installation, in the Device Allocation screen: VDP allows the user to proceed with an unmounted datastore for storing new disks.
The VDP Appliance allows a user to add new disks to an unmounted datastore. The system does not report an error and allows the user to proceed further. It is only when the user clicks Yes on the Ready to Complete page that the Add Disk operation fails with a fatal error message.
- When the datacenter name is named using a non-Latin alphabet, VDP-initiated backups will fail.
- vCenter HTTP port configured to anything except 80. "Failed to acquire all licenses" error displayed in UI.
If the vCenter HTTP port is configured to anything but 80, then the VDP appliance configuration will fail to communicate with the vCenter when retrieving advanced licensing information. This may present an error during deployment of the VDP Appliance.
After upgrading to or deploying a new VDP 5.5.5 appliance, the vSphere Web Client does not display advanced licensing information and "Failed to acquire all licenses" error is displayed.
To resolve both of these scenarios, perform the following steps:
- SSH or putty to the VDP appliance as the root user.
- Navigate to the path /usr/local/vdr/etc/ and edit the file vdp-options.properties.
- Locate the field "com.vmware.vdp.option.vcenter.http_port". The preconfigured value is 80.
- Modify the value from 80 to the HTTP port for your vCenter configuration.
- Save the changes to the properties file.
- Log out of vSphere Web Client VDP plugin and / or VDP configuration UI sessions if they exist.
- Restart the web services by running the command
Note: This will only work if applied on a VDP 5.5.5 Appliance. Prior to that release, this functionality will have no effect.