vxlicrep ERROR V-21-3-1015 Failed to prepare report for key
Dear all, we got a INFOSCALE FOUNDATION LNX 1 CORE ONPREMISE STANDARD PERPETUAL LICENSE CORPORATE. I have installed key using the vxlicinst -k <key> command. But when I want to check it using vxlicrep I'm getting this error for the given key: vxlicrep ERROR V-21-3-1015 Failed to prepare report for key = <key> We have Veritas Volume Manager 5.1 (VRTSvxvm-5.1.100.000-SP1_RHEL5 and VRTSvlic-3.02.51.010-0) running on RHEL 5.7 on 64 bits. I've read that the next step is to run vxkeyless set NONE, but I'm afraid to run this until I cannot see the license reported correctly by vxlicrep. What can I do to fix it? Thank you in advance. Kind regards, Laszlo
SFHA Solutions 6.2: Symantec Storage plug-in for OEM 12c
Symantec Storage plug-in for OEM12c enables you to view and manage the Storage Foundation and VCS objects through the Oracle Enterprise Manager 12c (OEM), which has a graphical interface. It works with the Symantec Storage Foundation and High Availability 6.2 product suite. The Symantec Storage plug-in allows you to: SmartIO: manage Oracle database objects using SmartIO. Snapshot: create point-in-time copies (Storage Checkpoint, Database FlashSnap, Space-optimized Snapshot, and FileSnap) of Oracle databases using SFDB features Cluster: vew cluster-specific information. You can get the plug-in by downloading the attached file. For more information about installing and using the plug-in, download the attached Application Note. Terms of use for this information are found in Legal Notices.InfoScale 7.1 and large disks (8Tb) with FSS
Hi everyone, I had been successfully running FSS with (thin) 8Tb disk drives on SFCFSHA 6.1 and 6.2.1 (see:http://vcojot.blogspot.ca/2015/01/storage-foundation-ha-61-and-flexible.html) I am trying to reproduce the same kind of setup with InfoScale 7.1 and it seems to have issues with 8Tb drives. Here's the full setup description: 2 * RHEL6.8 hosts with 16gb RAM. 4 LSI virtual adapters, each with 15 drives. c0* and c1* have 2Tb drives. c2* and c3* have 8Tb drives. Both 2tb and 8tb drives are 'exported' and the cluster is stable. Here's what I noticed.. Creating an FSS DG works on 2tb drives but not on 8tb drives (it used to on 6.1 and 6.2.1): [root@vcs18 ~]# /usr/sbin/vxdg -s -o fss=on init FSS00dg ssd_2T_00 [root@vcs18 ~]# vxdg list FSS00dg Group: FSS00dg dgid: 1466522672.427.vcs18 import-id: 33792.426 flags: shared cds version: 220 alignment: 8192 (bytes) local-activation: shared-write cluster-actv-modes: vcs18=sw vcs19=sw ssb: on autotagging: on detach-policy: local dg-fail-policy: obsolete ioship: on fss: on storage-sources: vcs18 copies: nconfig=default nlog=default config: seqno=0.1027 permlen=51360 free=51357 templen=2 loglen=4096 config disk ssd_2T_00 copy 1 len=51360 state=clean online log disk ssd_2T_00 copy 1 len=4096 On the 8Tb drives, it fails with: [root@vcs18 ~]# vxdg destroy FSS00dg [root@vcs18 ~]# /usr/sbin/vxdg -s -o fss=on init FSS00dg ssd_8T_00 VxVM vxdg ERROR V-5-1-585 Disk group FSS00dg: cannot create: Record not in disk group One thing that I noticed is that the 8Tb drives, even though exported, do -not- show up on the remote machine: [root@vcs18 ~]# vxdisk list|grep _00 ssd_2T_00 auto:cdsdisk - - online exported ssd_2T_00_1 auto:cdsdisk - - online remote ssd_8T_00 auto:cdsdisk - - online exported One other thing to note is that the 'connectivity' seems a bit messed up on the 8Tb drives: [root@vcs18 ~]# vxdisk list ssd_2T_00|grep conn connectivity: vcs18 [root@vcs18 ~]# vxdisk list ssd_2T_00_1|grep conn connectivity: vcs19 [root@vcs18 ~]# vxdisk list ssd_8T_00|grep conn connectivity: vcs18 vcs19 That's (IMHO) an error since those 'virtual'drives are local to each of the nodes and the SCSI busses aren't shared vcs18 and vcs19 are two fully independent VMWare machines. This looks like a bug to me but since I don't work for a company with a vx software support contrat anymore I cannot report the issue. Thanks for reading, Vincent
