ViPR Controller : Block Consistency Group not created after a Recoverpoint CG ingestion.


   Article Number:     540261                                   Article Version: 2     Article Type:    Break Fix 




ViPR Controller,ViPR Controller Controller 3.6 SP2





VIPR Controller is unable to create the block consistency group in its database when ingesting all volumes associated to a Recoverpoint Consistency Group.   
    The ingestion orders for the source, target and Journal volumes (performed in that sequence) are all successful but once the last journal volume is ingested VIPR-C does not create the Block CG to match the RP CG  being ingested and therefore none of the volumes ingested are bound to any CG.






At least one of the volumes being ingested was exported to a host that was not in VIPR Controller.   
    If volumes are exported to more than one host/cluster (regardless of whether the host is VIPR-C Managed or not), each export of that volume needs to be ingested into VIPR before the Block CG can be created.   
    Once all data volume exports are ingested, VIPR-C will create the Block CG after the last journal volume is ingested.   







      Workaround: (If all Journal volumes are ingested)     
      A solution exists for this issue, but intervention from EMC technical support personnel is required.     
      Support personnel must access your storage system to fix this issue.     
      Contact the EMC Customer Support Center or your service representative for technical assistance and quote this article ID.     
      Include the ViPR Controller Order History text as well as logs covering the time frame when you contact EMC for technical assistance.     
Resolution(Recommended procedure to ingest RP CG volumes)     
1. Review all the hosts/clusters that the RP CG volumes (source & target) are exported to (VIPR-C managed and non VIPR managed hosts).         
          2. Ingest all exports for the source volumes.         
          3. Ingest all exports for the target volumes.         
          4. Ingest the Source Journals         
          5. Ingest the Target Journals         
          6. Verify the block consistency group is created in VIPR-C and all ingested volumes are linked to it.








      Note: After all exports for a volume are ingested, the UnManagedVolume entry for that volume in the UnManangedVolume CF is deleted.       
        If there are still existing exports not ingested for the volume, the UnManagedVolume entry remain and you will find the following entry in the VIPR-C logs.       
        ViPR Controller APIsvc logs:
      vipr1 vipr1 apisvc 2020-01-06 12:15:50,380 [AsyncTaskExecutorService_4266] INFO (line 66) 3 of 4 unmanaged export masks were ingested       
        vipr1 vipr1 apisvc 2020-01-06 12:15:50,380 [AsyncTaskExecutorService_4266] INFO (line 2953) cannot delete unmanaged volume [ volume_name ] (urn:storageos:UnManagedVolume:11b0629e-6767-45c1-a8f2-dea7c431e5eb:vdc1) because these unmanaged export masks are remaining to be ingested: [urn:storageos:UnManagedExportMask:cdfc6495-6f54-4332-b938-8cbe423b068c:vdc1]       
        vipr1 vipr1 apisvc 2020-01-06 12:15:50,381 [AsyncTaskExecutorService_4266] INFO (line 1751) Updating operation 7b6fc0af-3669-4e5f-811f-4fd5f147904c for object urn:storageos:UnManagedVolume:11b0629e-6767-45c1-a8f2-dea7c431e5eb:vdc1 with status ready       
        vipr1 vipr1 apisvc 2020-01-06 12:15:50,384 [AsyncTaskExecutorService_4266] INFO (line 2008) Completed task urn:storageos:Task:4caa3b34-5144-4339-9bdb-e863d6b951d4:vdc1 (7b6fc0af-3669-4e5f-811f-4fd5f147904c), ready       
        vipr1 vipr1 apisvc 2020-01-06 12:15:50,387 [AsyncTaskExecutorService_4266] INFO (line 254) persisting RecoverPoint backend for volume [volume_name] (urn:storageos:UnManagedVolume:11b0629e-6767-45c1-a8f2-dea7c431e5eb:vdc1)