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
Cloud IPs get added to on-premise NICs after migrate back to the on-premise site and reboot (7713)
After the successful migration to the production site (on-premise) and reboot of the Windows virtual machines, the cloud IP addresses get associated with the on-premise NICs.
This is because of some issue in networking script that causes the cloud IPs to be added to premise NICs on reboot after migrate back.
Workaround:
You need to manually remove the additional IPs from the on-premise NIC.