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
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, VincentPatch error
I have installed SFHA and I'm trying to apply patch Symantec Storage Foundation HA 6.2.1 Patch 300 (https://sort.veritas.com/patch/detail/12486) but I'm receiving error. I already have installed Veritas Storage Foundation High Availability 6.2 Maintenance Release 6.2.1.000 (https://sort.veritas.com/patch/detail/10105) and Symantec Storage Foundation HA 6.2.1 Patch 200 (https://sort.veritas.com/patch/detail/12255) on the system. Error message: The following errors were discovered on the systems: CPI ERROR V-9-0-0 VRTSglm(6.2.0.100) can only be installed on VRTSglm(6.2.0.000). Installation of VRTSglm(6.2.0.100) on top of VRTSglm() is not supported on SERVER01 CPI ERROR V-9-0-0 VRTSdbac(6.2.0.100) can only be installed on VRTSdbac(6.2.0.000). Installation of VRTSdbac(6.2.0.100) on top of VRTSdbac() is not supported on SERVER01 CPI ERROR V-9-0-0 VRTScavf(6.2.1.100) can only be installed on VRTScavf(6.2.0.000). Installation of VRTScavf(6.2.1.100) on top of VRTScavf() is not supported on SERVER01 CPI ERROR V-9-0-0 VRTSglm(6.2.0.100) can only be installed on VRTSglm(6.2.0.000). Installation of VRTSglm(6.2.0.100) on top of VRTSglm() is not supported on SERVER02 CPI ERROR V-9-0-0 VRTSdbac(6.2.0.100) can only be installed on VRTSdbac(6.2.0.000). Installation of VRTSdbac(6.2.0.100) on top of VRTSdbac() is not supported on SERVER02 CPI ERROR V-9-0-0 VRTScavf(6.2.1.100) can only be installed on VRTScavf(6.2.0.000). Installation of VRTScavf(6.2.1.100) on top of VRTScavf() is not supported on SERVER02 The following warnings were discovered on the systems: CPI WARNING V-9-0-0 SF 6.2.1.300 and VCS 6.2.0.000 are installed on SERVER01. Only SF 6.2.1.300 will be upgraded. CPI WARNING V-9-0-0 SF 6.2.1.300 and VCS 6.2.0.000 are installed on SERVER02. Only SF 6.2.1.300 will be upgraded.Having issues attempting to reduce the size of a disk group.
I am attempting to reduce the size of my disk group as an excersize and unable to do so. I believe the issue to be that my plex is in a DISABLED REMOVED state and my volume is in a DISABLED ACTIVE state. Doing research I did not do a vxresize before doing a vxdg rmdisk and now trying to get it back and I keep seeing different suggestions but nothing exactly on a DISABLED REMOVED state. Any assistance would be appreciated... bash-3.2# vxprint -g dg_acpdev TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0 dg dg_acpdev dg_acpdev - - - - - - dm dg_acpdev_d01 emc1_3ac1 - 35281408 - - - - dm dg_acpdev_d02 - - - - REMOVED - - dm dg_acpdev_d03 emc1_3a7c - 70640128 - - - - dm dg_acpdev_d04 - - - - REMOVED - - dm dg_acpdev_d05 emc1_3860 - 35281408 - - - - pl dgacpdev-01 - DISABLED 141201408 - REMOVED - - sd dg_acpdev_d01-01 dgacpdev-01 ENABLED 35281408 0 - - - sd dg_acpdev_d03-01 dgacpdev-01 ENABLED 70640128 35281408 - - - sd dg_acpdev_d04-01 dgacpdev-01 DISABLED 35279872 105921536 REMOVED - - v dgacpdev fsgen DISABLED 141201408 - ACTIVE - -Detect more space on existing LUN
Hi, I am using Veritas Foundation 6.1 on SLES. We have a LUN aleady in a diskgroup with a volume. SAN have increased the LUN from 200GB to 300GB. How can we get Veritas to see the additional 100GB? Tried "vxdg free" but this just shows the existing size not the new size Tried rescanning scsi paths but no changes. Tried "vxdisk list LUN_NAME" but that gives old size. Thanks