Please enter search query.
Search <book_title>...
Veritas™ Resiliency Platform 2.2 Update 3 Release Notes
Last Published:
2017-04-07
Product(s):
Resiliency Platform & CloudMobility (2.2)
- Overview
- System requirements
- Fixed issues
- Known issues
- Disaster recovery (DR) configuration for resiliency group fails if Microsoft Hyper-V Replica is configured after you add a virtual machine in Resiliency Platform
- In the VM Inventory report, instead of allocated memory, Resiliency Platform shows the total memory of the virtual machines
- Certain validations do not work while creating a resiliency group of applications (3721289)
- Rehearsal does not work after being aborted
- The configure DR operation fails if virtual machines in the resiliency group belong to different servers
- For resiliency groups containing VMware virtual machines with NFS datastore mounted from a NetApp volume with substring vol, Migrate or takeover operations may fail
- The license expiry status is inconsistent on Resiliency Managers configured on different time zones
- In the Hyper-V guest environment, the writable disk is shown in the Read-Only state (3785911)
- Long SRDF device group names are not discovered (3786826)
- Multiple repository paths on the same host are not allowed for the repository server (3734149)
- Unknown state displayed for the Resiliency groups of dark sites that are part of VBS (3794650)
- An Oracle custom application is not discovered if the instance names do not match (3796579)
- VBS DR operations fail when an application resiliency group with unconfigured DR is added in VBS (3794105)
- Expired resiliency plan cannot be executed even after editing the schedule (3861955)
- Resiliency groups for Hitachi enclosures are not displayed on dashboard under Top RG by replication lag chart (3861173)
- Snapshot disk is read only after rehearse operation is performed in Hyper-V with SRDF replication (3862088)
- Static IP customization may not work under certain conditions (3862916, 3862237)
- Need to manually refresh all assets after a site recovery (3861929)
- Disk utilization risk not resolved after DR operations
- Migrate operation becomes unresponsive if the operation is initiated from an unavailable site (3862253)
- Remote cluster group dependencies not validated before migrate (3863082)
- VBS migrate operation cannot be performed after failure (3862124)
- Resiliency group state does not get updated when production site is down (3863081)
- Replication information error (5170)
- DNS customization does not work if FQDN is not defined (5037)
- Previously configured network mapping may not work after re-adding a VMware vCenter server
- Some versions of VMware Tools are not supported (4969)
- Login to the Resiliency Manager console fails at times
- Resiliency group and VBS names in charts are displayed incorrectly in Japanese and Chinese (8465)
- Warning message may be displayed for network mapping (8644)
- Cannot edit application discovery frequency for the uploaded application bundles from console (8433)
- Metering report does not work for third-party replication technologies (8617)
- Replication information not discovered for Hyper-V virtual machines configured in Microsoft Failover Clustering environment using Non-English characters in the CSV path (8697)
- An operation may fail if invoked at a time when virtual machine is being migrated using Vmotion (6476)
- vLan mapping compulsory for DRS enabled Vmware virtual machines (10322)
- Known issues: Resiliency Platform Data Mover
- Virtual Machine protection using Data Mover has a few policy related limitations (5181)
- Iofilter bundle not removed from ESX hosts even after unconfiguring virtual machines (5178)
- Storage policy needs to be manually removed after all the virtual machines are unconfigured (5180)
- VMDK and VMX files need to be in the same folder(5167)
- Edit resiliency group operation may fail after rehearsal or cleanup rehearsal (5092)
- Replication gets paused if you perform add disk operation (5182)
- Cannot perform any operation after deleting disk from virtual machine (5182)
- Data Mover virtual machine in no op mode risk cannot be resolved (5183)
- Risks not generated after taking snapshot of virtual machine replicated using Data Mover(6886)
- Known issues: Recovery to Amazon Web services (AWS)
- Some DHCP enabled NICs are not present on Cloud after migrate (7407)
- One or more NICs of a migrated Windows virtual machine may not be visible (7718)
- Cloud IPs get added to on-premise NICs after migrate back to the on-premise site and reboot (7713)
- Migrate or takeover operations fail at the Add Network for AWS task and Create Network Interface sub-task (7719)
- Sometimes network comes up on only one NIC although there are multiple NICs (8232)
- Known issues: NetBackup integration
- MAC address starting with 00:0c:29 not supported for VMware virtual machines (7103)
- A virtual machine backed up by multiple NBU master servers gets mapped with only one master server in the console (7608)
- A transient virtual machine remains in the ESX server in one scenerio (7413)
- Operations for virtual machine do not work if the remote master server gets reconfigured (8600)
- Known issues: Recovery to vCloud
- Limitations
- Rehearsal is not supported if volume is configured using asynchronous replication in IBM XIV enclosure
- Limitations for on-premises Windows hosts for Resiliency Platform Data Mover replication
- Hyper-V hosts having snapshots not supported for recovery to AWS
- Computer name of virtual machine on vCloud differs if the name exceeds permitted character limit
- Localization of adding application type is not supported
- Datastore name with special characters
- Appendix A. Virtual appliance security features
VBS migrate operation cannot be performed after failure (3862124)
If the workflow fails during a VBS migrate operation, then migrate operation cannot be retried for the VBS.
Workaround:
Fix the issue which caused the failure and then bring the VBS online on production site and then perform the Migrate operation. You can also try to perform migrate operation on individual resiliency group after fixing the issue which caused the failure.