Solved

Intellisnap Linux Proxy on RHEL 8

  • 6 January 2023
  • 3 replies
  • 144 views

Userlevel 3
Badge +7

Hi,

We are currently having an issue with a Linux Proxy that is running RHEL 8.x.

We used to have a Linux proxy running RHEL 7 that was being used to mount snapshots from other RHEL 7 clients and copy them over to the disk library.

As we rolled out new RHEL 8 clients, we wanted to set up a Linux Proxy running RHEL 8.x.

The Snapshot copy phase works fine and we can see the snapshots on the storage. However, the backupcopy job fails, already during the Scanphase.

In the logs we can see the following:

362266 5871a 01/06 14:22:02 2973716 CVMMSnapAPI::processVolSnapOperation() - Request to MM -- << OpType[2: Mount] SnapJob[2970008] SrcClient[1759] MountHost[1956] VmHostId[0] OpSrc[1: IDA] OpMode[3: HWDB] Flags[2] HopCount[0] Status[0] >>
362266 5871a 01/06 14:22:02 2973716 CVMMSnapAPI::processVolSnapOperation() - VolSnap to MM -- << [V-6: 28431 28432 28433 28434 28435] [MS: 79 79 79 79 79] [S-4: 24640 24641 24642 24643] [MD-14: -1 -2 65695 -3 -4] [M-24: 55236 55237 55238 55239 55240] [C-1: 13] [E-1: 39] >>
362266 5871a 01/06 14:22:29 2973716 CVMMSnapAPI::processVolSnapOperation() - Response from MM -- << OpType[2: Mount] SnapJob[2970008] SrcClient[1759] MountHost[1956] VmHostId[0] OpSrc[1: IDA] OpMode[3: HWDB] Flags[2] HopCount[0] Status[-1] Error[60610] ErrStr[Failure during recreate VG. Error [Failed to update metadata for VG group [nonprdvg_copy_001]: WARNING: Found 7 active volume(s) in volume group "nonprdvg_copy_001".
Do you really want to proceed with restore of volume group "nonprdvg_copy_001", while 7 volume(s) are active? [y/n]: [n]
Restore aborted.

So it is failing to mount the snapshot to the Linux Proxy? We’re a bit stuck now and don’t know where to look further. Any Linux guru’s that would know what’s happening here?

Any help would be appreciated.

Thanks.

Jeremy

 

 

 

icon

Best answer by M Scheepers 9 January 2023, 11:32

View original

3 replies

Userlevel 6
Badge +15

Can you please update as to which version of Commvault you are running, for example 11.28.24.    What is being seen in CVMA.log at the time of the snap mount failure?

Userlevel 3
Badge +7

Hi Orazan,

Thanks for your reply! The environment is running version 11.20.

I can see the same exact error in the CVMA log:

36764 8fca  01/06 14:22:28 2973716 [Huawei-Log]:|-------------------- Completed Map Snaps(4/4/4) --------------------|
36764 8fca 01/06 14:22:28 2973716 CVMMSnapAPI::updateVolumeSnaps() - Completed the updateVolumeSnaps operation.
36764 8fca 01/06 14:22:28 2973716 CVMMSnapAPI::updateVolumeSnaps() - Completed the updateVolumeSnaps operation.
36764 8fca 01/06 14:22:28 2973716 virtual CQiError CVSnapOSUtilUNIX::mountVolumes(SMMetaDataInfo&, std::vector<SMVolumeInfo>&, std::ve The engine type is persistent
36764 8fca 01/06 14:22:28 2973716 CVSnapOSUtilUNIX::mountVolumes(1169) - getSourceClientId 1759 getMountHostId 1956 bAllowSourceVGtoMatchMount 0
36764 8fca 01/06 14:22:28 2973716 CVSnapOSUtilUNIX::mountVolumes(1169) - getSourceClientId 1759 getMountHostId 1956 bAllowSourceVGtoMatchMount 0
36764 8fca 01/06 14:22:28 2973716 CVSnapOSUtilUNIX::mountVolumes(1169) - getSourceClientId 1759 getMountHostId 1956 bAllowSourceVGtoMatchMount 0
36764 8fca 01/06 14:22:28 2973716 CVSnapOSUtilUNIX::mountVolumes(1169) - getSourceClientId 1759 getMountHostId 1956 bAllowSourceVGtoMatchMount 0
36764 8fca 01/06 14:22:28 2973716 CVSnapOSUtilUNIX::mountVolumes(1169) - getSourceClientId 1759 getMountHostId 1956 bAllowSourceVGtoMatchMount 0
36764 8fca 01/06 14:22:28 2973716 CVSnapOSUtilUNIX::mountVolumes(1169) - getSourceClientId 1759 getMountHostId 1956 bAllowSourceVGtoMatchMount 0
36764 8fca 01/06 14:22:28 2973716 CVSnapOSUtilUNIX::mountVolumes(1348) - Can't use source VG GUID 'LdE463-iAGC-fFc8-7ihS-AAWc-OSWW-9VYDdT'. VG is not mounted.
36764 8fca 01/06 14:22:29 2973716 CVSnapOSUtil::mountVolumes() - Volume (28431) mount status is 40 RemOp:2220-0
36764 8fca 01/06 14:22:29 2973716 CVSnapOSUtil::mountVolumes() - Volume (28432) mount status is 40 RemOp:2220-0
36764 8fca 01/06 14:22:29 2973716 CVSnapOSUtil::mountVolumes() - Volume (28433) mount status is 40 RemOp:2220-0
36764 8fca 01/06 14:22:29 2973716 CVSnapOSUtil::mountVolumes() - Volume (28434) mount status is 40 RemOp:2220-0
36764 8fca 01/06 14:22:29 2973716 CVSnapOSUtil::mountVolumes() - Volume (28435) mount status is 40 RemOp:2220-0
36764 8fca 01/06 14:22:29 2973716 CVSnapOSUtil::mountVolumes() - Volume (28436) mount status is 40 RemOp:2220-0
36764 8fca 01/06 14:22:29 2973716 CVSnapOSUtil::mountVolumes(822) - 0xEC02ECC2:{CVSnapOSUtilUNIX::mountVolumes(1631)} + {CVSnapOSUtilUNIX::mountVolumes(1628)/MM.60610-Failure during recreate VG. Error [Failed to update metadata for VG group [nonprdvg_copy_001]: WARNING: Found 7 active volume(s) in volume group "nonprdvg_copy_001".
Do you really want to proceed with restore of volume group "nonprdvg_copy_001", while 7 volume(s) are active? [y/n]: [n]
Restore aborted.
] in [LVM_linux_lvm.cpp:1277]}

Have you seen this error message in Linux?

Jeremy

Userlevel 3
Badge +6

Hi Jeremy,

 

you needs also check the SELINUX configuration, you could see some denies in the audit.log.

 

Michel

Reply