Article Number: 528766

printer Print mail Email

RecoverPoint for Virtual Machines: VMWare upgrade to vCenter 6.7 may cause disruption to replication

Summary: Upgrading VMWare vCenter to 6.7 with RecoverPoint for Virtual Machines may causes disruption to replication

Primary Product: RecoverPoint for Virtual Machines

Product: RecoverPoint for Virtual Machines more...

Last Published: 23 Mar 2020

Article Type: Break Fix

Published Status: Online

Version: 8

RecoverPoint for Virtual Machines: VMWare upgrade to vCenter 6.7 may cause disruption to replication

Article Content

Issue


Following an upgrade to vCenter 6.7, RecoverPoint for Virtual Machines may stop replicating VMs

Errors accessing Repository and Journal volumes:
ERROR: repository volume can't be accessed by any RPA 
ERROR: Journal volume [CG1, prod, RPVS_Lun00003] cannot be accessed by: RPA 1, RPA 2 
ERROR: Journal volume [CG1, copy1, RPVS_Lun00004] cannot be accessed by: RPA 1, RPA 2 
ERROR: Journal volume [CG2, prod, 60,00,c2,98,e6,70,31,71,e2,0c,46,61,4a,xx,xx,xx] cannot be accessed by: RPA 1, RPA 2 
ERROR: Journal volume [CG2, copy1, 60,00,c2,9f,dc,f4,e6,8f,52,57,a6,93,1f,xx,xx,xx] cannot be accessed by: RPA 1, RPA 2 


RecoverPoint for Virtual Machines events (in GUI and command get_events_log) may show events 16059 and 16038:

Topic: RPA
Scope: NORMAL
Level: ERROR
EventID: 16059
Cluster: RP_cluster
SummaryBrief connectivity problem between all group volumes and RPA

Topic: RPA
Scope: NORMAL
Level: ERROR
EventID: 16038
Cluster: RP_cluster
Summary: Brief group(s) journal volumes accessibility error corrected
Details: All journal volumes in the consistency group (or groups) were not accessible. Problem has been corrected.
 

RecoverPoint for Virtual Machines Splitter logs on the ESX hosts (/scratch/log/kdriver.log.00000xxx) may show errors such as:
krnl:[12:35:39.804] 0/0 #2 - parse_vmdk_file: capacity=12000000, thinLun=0, flat_filename=RPVS_Lun00001-flat.vmdk, rawguid=0x6000c2963030eb6c2edf8694b30cxxxx
krnl:[12:35:39.804] 0/0 #0 - handle_discovered_rpvs_device: Couldn't get current timestamp of VMDK-file=/vmfs/volumes/vsan:527bb100ed38d0xx-cf59bd635c21xxxa2/RPvStorage/441f73a13f1feaxx/RPVS_Lun00001.vmdk.
krnl:[12:35:39.805] 0/0 #2 - parse_vmdk_file: called with file /vmfs/volumes/vsan:527bb100ed38d0xx-cf59bd635c2112xxx/RPvStorage/441f73a13f1fexx/RPVS_Lun00004.vmdk
krnl:[12:35:39.811] 0/0 #2 - parse_vmdk_file: capacity=20971520, thinLun=0, flat_filename=RPVS_Lun00004-flat.vmdk, rawguid=0x6000c291a2bc49637aed0b0bc4cc1xxxx
krnl:[12:35:39.811] 0/0 #0 - handle_discovered_rpvs_device: Couldn't get current timestamp of VMDK-file=/vmfs/volumes/vsan:527bb100ed38d0xx-cf59bd635c211xxx/RPvStorage/441f73a13f1fexxx/RPVS_Lun00004.vmdk.
Cause

When upgrading to vCenter 6.7, some file attributes related to file time change, and RecoverPoint for Virtual Machines cannot determine when the files were changed.
This leads to accessibility issues for the volumes RecoverPoint for Virtual Machines needs to use and replication disruption occurs.

This issue is expected to occur on upgraded RecoverPoint for Virtual Machines clusters (upgraded from 5.1).

Resolution

Workaround:

The new JAM mechanism of RecoverPoint for Virtual Machines 5.2 can work well with vCenter 6.7. 
However the new mechanism requires a newly installed cluster at 5.2.0.x and later. upgrade from 5.1 will use the old mechanism (Juke) and will have the issues seen above.
Removing and configuring a new RecoverPoint for Virtual Machines at 5.2.0.3 and later will resolve this issue

Resolution:

This issue is resolved in RecoverPoint for Virtual Machines 5.2 P4 as well as 5.2 SP1.
Customers hitting this issue can upgrade to the 5.2.0.4/5.2.1 version, by upgrading the ESX splitters to the 5.2.0.4/5.2.1 version first.
The upgraded splitters should allow storage access for the vRPAs, the errors will clear and then the vRPAs may then be upgraded.

Notes

This issue prevents VxRail 4.7 support at this time.

Issue


Following an upgrade to vCenter 6.7, RecoverPoint for Virtual Machines may stop replicating VMs

Errors accessing Repository and Journal volumes:
ERROR: repository volume can't be accessed by any RPA 
ERROR: Journal volume [CG1, prod, RPVS_Lun00003] cannot be accessed by: RPA 1, RPA 2 
ERROR: Journal volume [CG1, copy1, RPVS_Lun00004] cannot be accessed by: RPA 1, RPA 2 
ERROR: Journal volume [CG2, prod, 60,00,c2,98,e6,70,31,71,e2,0c,46,61,4a,xx,xx,xx] cannot be accessed by: RPA 1, RPA 2 
ERROR: Journal volume [CG2, copy1, 60,00,c2,9f,dc,f4,e6,8f,52,57,a6,93,1f,xx,xx,xx] cannot be accessed by: RPA 1, RPA 2 


RecoverPoint for Virtual Machines events (in GUI and command get_events_log) may show events 16059 and 16038:

Topic: RPA
Scope: NORMAL
Level: ERROR
EventID: 16059
Cluster: RP_cluster
SummaryBrief connectivity problem between all group volumes and RPA

Topic: RPA
Scope: NORMAL
Level: ERROR
EventID: 16038
Cluster: RP_cluster
Summary: Brief group(s) journal volumes accessibility error corrected
Details: All journal volumes in the consistency group (or groups) were not accessible. Problem has been corrected.
 

RecoverPoint for Virtual Machines Splitter logs on the ESX hosts (/scratch/log/kdriver.log.00000xxx) may show errors such as:
krnl:[12:35:39.804] 0/0 #2 - parse_vmdk_file: capacity=12000000, thinLun=0, flat_filename=RPVS_Lun00001-flat.vmdk, rawguid=0x6000c2963030eb6c2edf8694b30cxxxx
krnl:[12:35:39.804] 0/0 #0 - handle_discovered_rpvs_device: Couldn't get current timestamp of VMDK-file=/vmfs/volumes/vsan:527bb100ed38d0xx-cf59bd635c21xxxa2/RPvStorage/441f73a13f1feaxx/RPVS_Lun00001.vmdk.
krnl:[12:35:39.805] 0/0 #2 - parse_vmdk_file: called with file /vmfs/volumes/vsan:527bb100ed38d0xx-cf59bd635c2112xxx/RPvStorage/441f73a13f1fexx/RPVS_Lun00004.vmdk
krnl:[12:35:39.811] 0/0 #2 - parse_vmdk_file: capacity=20971520, thinLun=0, flat_filename=RPVS_Lun00004-flat.vmdk, rawguid=0x6000c291a2bc49637aed0b0bc4cc1xxxx
krnl:[12:35:39.811] 0/0 #0 - handle_discovered_rpvs_device: Couldn't get current timestamp of VMDK-file=/vmfs/volumes/vsan:527bb100ed38d0xx-cf59bd635c211xxx/RPvStorage/441f73a13f1fexxx/RPVS_Lun00004.vmdk.
Cause

When upgrading to vCenter 6.7, some file attributes related to file time change, and RecoverPoint for Virtual Machines cannot determine when the files were changed.
This leads to accessibility issues for the volumes RecoverPoint for Virtual Machines needs to use and replication disruption occurs.

This issue is expected to occur on upgraded RecoverPoint for Virtual Machines clusters (upgraded from 5.1).

Resolution

Workaround:

The new JAM mechanism of RecoverPoint for Virtual Machines 5.2 can work well with vCenter 6.7. 
However the new mechanism requires a newly installed cluster at 5.2.0.x and later. upgrade from 5.1 will use the old mechanism (Juke) and will have the issues seen above.
Removing and configuring a new RecoverPoint for Virtual Machines at 5.2.0.3 and later will resolve this issue

Resolution:

This issue is resolved in RecoverPoint for Virtual Machines 5.2 P4 as well as 5.2 SP1.
Customers hitting this issue can upgrade to the 5.2.0.4/5.2.1 version, by upgrading the ESX splitters to the 5.2.0.4/5.2.1 version first.
The upgraded splitters should allow storage access for the vRPAs, the errors will clear and then the vRPAs may then be upgraded.

Notes

This issue prevents VxRail 4.7 support at this time.

Article Attachments

Attachments

Attachments

Article Properties

First Published

Mon Dec 24 2018 17:54:08 GMT

First Published

Mon Dec 24 2018 17:54:08 GMT

Rate this article

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters