大多数情况下，顺着报错顺藤摸瓜很快就能找出原因，但总有例外，有些报错信息或者日志恰恰让我们南辕北辙。让我们看看这些案例最终是如何处理的……
案例1：图省事，搞出来个大麻烦
生产中心有几套VIOS环境，正常运行了1-2年，今日发现有2套进行健康性检查，发现执行命令就hang在哪里不动了，又是内存不够用了。
"0403-031 The fork
function failed. There is not enough memory available."
好奇怪，到底内存被谁用了，vios好端端的就这样了。都这个样子，重启vios分区吧。重启完，vios顺利登陆，执行健康性检查没啥问题，可是用nmon看了一下内存使用分配了4个G，使用1个多G,慢慢慢慢的就看到内存使用越来越大，不一会4个G就用完了，重启其他vios分区一个样子，连换页空间都用了。顿时一头雾水。到底发生了什么呢？
生产中心有几套VIOS环境，正常运行了1-2年.突然出现这种问题，首先想到的是变更。梳理了近期变更操作，近期新部署了PowerVC,VIOS进行了补丁升级。VIOS2.1升级到VIOS2.2.3.
首先，重启vios分区，在内存没有用完前赶紧检查那个进程使用的内存.
排名第一的是vio_daemon,观察了一会发现内存一会就被他占用完了
第二，元凶找到了，vio_daemon到底是干啥的，问问IBM800吧，IBM回复问我收集一下系统信息。
- ioslevel
- /etc/security/limits的输出
反馈后，IBM告诉我，我遇到了bug
vios版本和 /etc/security/limits stack = -1完全符合这个bug特征。
其实这个bug是可以避免的，我们大多数实施AIX的时候,很容易顺手把 /etc/security/limits.都改成-1，在大多数情况下，没啥问题，但是就是在这个版本下就容易遇到这个问题。
default:
fsize = -1
core = -1
cpu = -1
data = -1
rss = -1
stack = -1
nofiles = -1
The problem can be due to a known issue inVIOS 2.2.3.0 thru 2.2.3.3 with vio_daemon having a memory leak that was fixedat 2.2.3.4 with IV64508,or it could be due to incorrect VIOS settings.
Answer
To check your VIOS level, as padmin, run:
$ ioslevel
If your VIOS level is 2.2.3.4 or higher, the problem may be due to the VIOShaving incorrect system settings in /etc/security/limits. If the"stack" size is set to "unlimited" (stack = -1),this exposes a condition where the system can be allowed to pin as much stackas desired causing vio_daemon to consume a lot of memory.
$ oem_setup_env
vi /etc/security/limits ->check thedefault stanza
default:
fsize = -1
core = -1
cpu = -1
data = -1
rss = -1
stack = -1
nofiles = -1
In some cases, the issue with vio_daemonconsuming high memory is noticed after a VIOS update to 2.2.3.X. However, aVIOS update will NOT change these settings. It is strongly recommended not tomodify these default values as doing so is known to cause unpredictableresults. Below is an example of the default values:
default:
fsize = 2097151
core = 2097151
cpu = -1
data = 262144
rss = 65536
stack = 65536
nofiles = 2000
To correct the problem change the setting back to "default" values.Then reboot the VIOS at your earliest convenience.
案例2：装个AIX，却装出了信任危机
某制造业用户，一个新项目着急要上线，让维保厂商工程师赶紧抓紧准备一个AIX资源，装AIX系统按说对ma工程师来讲应该轻车熟路，可是这次装了好几遍，AIX系统就是进不去。
1 怀疑光盘问题，更换好几张重装未果，依旧进不去
2 怀疑AIX版本，更好了两个未果
3 怀疑硬件，进入asm里也没啥报错
首先说下用户设备的背景信息，设备采购于2012年，“天工计划”中的一款产品Power710 和Power730 中的一款，Power710设备特点：定位应用服务器，价格便宜，也就是不需要HMC管理，使用串口安装的IVM部署管理虚拟化环境。
之前这台710用作应用服务器。串口部署过IVM环境，这次重装需要注意串口输出问题。
所以一定要进行如下配置才可以顺利进入系统
第一步：进入维护模式 如果进入 Maintenance Mode 步骤就省略了
第二步：#export TERM=vt100
- # smit chtty
红色标注的两行，增加clocal.
- sync
- sync
- sync
- reboot
之后就能顺利进行系统了。
案例3：安装AIX报出这个错，新手老手绝对没见过
相信社区大多数人都安装AIX几十遍甚至上百遍了，但是今天安装AIX报出这个错，新手老手绝对没见过
安装AIX停在了这里。
其实我也经过了很多各位的排查工作，最终梳理了一下发现AIX安装出问题，排除硬件介质问题，多半是配置问题，那就按照这个思路往下走
首先，既然是配置就去profile文件里看看。不查不知道，一查问题果然找到了
有人会说，你居然犯这么低级的错误。冤枉啊，这是PowerVC干的怪我背景没说清楚。这是PowerVC部署aix出现的问题.
第二，问题找到了，那么为什么会出现问题，部署分区profile配置是在Powervc设置的，那就去Powervc里找答案吧。
问题出在了这里.PowerVC纳管了很多主机，每台主机配置不尽相同，当初为了省事就配置了vary计算模板，最大cpu配置成了32。
实际部署AIX时候，选择了一台低配的power服务器，CPU配置没有32，只有20个，结果被PowerVC配置成25.6.就这样出现了问题。
反思这个问题，PowerVC,规划配置模板，尽量多配置几个计算模板，与服务器相匹配.避免此类问题的发生。
通过这个问题还有第二种解法：
kdb模式下 输入 f，查看堆栈信息，也可以顺势查到profile配置信息
案例4：执行lsrep，诡异报出Insufficient memory
执行lsrep，诡异报出Insufficient memory
检查vios分区内存使用情况
似乎跟内存毫无关系。
首先检查了其他vios有没有这个问题，发现均没有此现象发生。对比vios版本及其lsrep输出，发现vios版本。都一样，唯一不同的是出问题的这个vios /var/vio/VMLibrary没有iso。把几个AIX ISO传到有问题的
这个vios /var/vio/VMLibrary下后，再次执行lsrep，成功了
案例5：PowerHA给Oracle新增表空间，遭遇memory croedump
通过PowerHA给Oracle新增表空间，使用C-SPOC在线添加LV,开始给Datavg添加，很顺利，添加了10个很成功，在继续添加新的lv后，居然报错了. memory croedump.
1，内存不够用了吗.看了一下确实有点紧张
hostA:
hostB:
2，仔细看了一下Powerha日志
也没啥有价值的信息
难道真的是内存快用完了导致的。
3，由于还要给其他vg新增lv，所以又尝试了一下给其他vg添加一下lv试试。
居然成功了。
这个问题从内存报错开始容易给人内存不足假象，实际环境确实也是内存利用率很高，但是定位最终问题不是内存不足造成的。
首先，刚开始新增的几个lv都顺利，后几个就失败了，然后新增其他vg的lv也成功了，这个时候就开始怀疑遇到bug了。
第二，一般裸奔的powerha，遭遇bug的可能性比较大，检查一下powerha补丁情况吧
果然，基本上就是一个裸奔的Powerha环境，遇到bug也就不足为奇了
第三，既然怀疑是bug，那就找点说服力的东西出来.如下所示
IV36992: CLPASSWDREMOTE CORE DUMPS DUE TOMEMORY FAULT
A fix is available
Obtain the fix forthis APAR.
Error description
The clpasswdremote utility is core dumping due to
segmentation
fault.
The problem occurs when the user is missing in
/etc/passwd
in one of the nodes in the cluster.
The cspoc.log will log the following:
[========== C_SPOC COMMAND LINE==========]
/usr/es/sbin/cluster/sbin/cl_chpasswd -cspoc-f -r
-cspoc -grg1 test3
hacmp13: success:
/usr/es/sbin/cluster/etc/clpasswd/usr_bin_passwd.orig
test3
hacmp14: FAILED: eval clpasswdremote -u test3 -p
'raCYOSMwhoJU.' -f 2 -l 0
hacmp14: cexec[54]: 3735594 Memoryfault(coredump)
hacmp14: RETURN_CODE=139
hacmp14: cl_rsh had exit code =139, see cspoc.log
and/or clcomd.log for more information
The error report will log a CORE DUMP error with the
following stack trace:
main 94
main 88
__start 6C
The following symptom code is logged as well:
PIDS/5765E6200 LVLS/520 PCSS/SPI2 FLDS/clpasswdr SIG/11
FLDS/main
VALU/94 FLDS/__start
Local fix
Ensure that the user exists in /etc/passwd file in all of
the nodes in the cluster.
Problem summary
If a user is not created using cspoc so that it exists on
all nodes in the cluster, then if you try to change that
user's password cluster wide using cspoc, clpasswordremote
will core dump on nodes where the user is not configured.
The smit output will look like:
Changing password for "tstuser"
hack2: cexec 54 : 8781858 Memory fault(coredump)
Problem conclusion
A check was added to clpasswdremote to avoid attempting to
change the password on a node where the user is not defined.
案例6：V7000紧急的状态，"紧急"的处理
使用PowerVC,部署AIX分区，结果无法部署，报了一堆莫名其妙的错误。怪了前几天还能正常部署.今天就不能了检查PowerVC服务都正常.登录HMC看看有没有建立分区profile，发现没有.无功而返，返回PowerVC继续排查，到了存储器发现了端倪，不过看样子挺吓人。
V7000存储卷运行状况变成了紧急。登录V7000查看，发现V7000没有问题。那就怪了。
其实PowerVC里的关于V7000的状态 紧急不能反映V7000真正的状态，而是通信出现了导致。至于通信出现问题，事后问网络的人，我部署的期间，网络正在变更，导致PowerVC不能下发命令给V7000，PowerVC就把V7000标记成紧急了。
案例7：一次先入为主的异常故障处理！！
一台P740服务器通过SAN交换机链接一台DS4700存储，在硬件维保商更换一次存储电池（A控）后，业务中断了。
我司负责数据库以及系统维护，被客户CALL到现场检查问题，在一番查看后发现A控上面所有LUN都找不到了，问题找到后开始排查问题。
询问硬件维保商在更换电池时有没有动到其他东西，得到了很准确的回答，我们就换个电池其他啥也没用动。于是连接存储SM把A控所有LUN切到B控，系统内能看到所有盘，OK 问题在A控上面，SM中看到的存储无报错无问题，继续把原来A控的LUN切到A控中，系统又找不到了……
开始删除所有硬盘然后重新识别……还是不行……
忙来忙去 两三个小时过去了，客户在旁边一直说啥时候能搞好啊，硬件维保商的人没事似的在旁边坐着……
我要去机房看一下，必须看一下。客户带着我们下了机房，然后看了主机以及HBA卡连接线，一切看起来都那么美好。然后看到了存储A控出的那条光纤线……
你妈的插错了！！！ 客户用异样的眼光看着硬件维保商……
处理问题切勿先入为主，任何事要自己确定一下以免有误！！！
案例8：varyonvg报错(LVM相关)的分析及处理
AIX操作系统在做计划内升级操作系统版本变更时，发现对于VG的varyon和varyoff命令有告警信息，经分析这只是一个告警信息，不影响使用，具体告警信息如下：
系统环境：AIX 5.3 TL12 SP7
首先，分析当时的报错内容，从操作内容来看，可以看到在执行varyoffvg命令时底层调用lqueryvg子命令时报错，而lqueryvg是一个查询类的命令，从这个命令的返回内容说明VG的定义信息与VGDA描述不一致。对于这类型的告警信息，重启操作系统时便会自动更新VG的相关信息进行自动修正。而当时计划内的变更是升级操作系统并修改磁盘的reserve_policy属性，因此打完补丁后直接重启操作，在这个过程中已经把VG信息进行了更新。
然后，分析当时的操作步骤及LVM的日志进行验证对应。
当时的操作记录如下，从操作日志来看，在重启操作系统前执行过两次varyoffvg和一次varyonvg的操作：
分析当时的LVM的日志，可以看到第一次varyoffvg时出现读取VG信息不一致的报错。
在第一次varyonvg时出现现样的信息。
在第二次varyoffvg时也现现同样的信息。
上面信息是操作系统重启前的信息，下面分析操作系统重启后LVM相关的信息，从日志中来看，当操作系统重启后，VG在varyon时返回值为0，说明重启过程已经更新了VG的信息。
综上所述，在重启操作系统后已经自动更新VG信息，告警信息已经自动消除。
处理建议：继续监控。
案例9：执行lspv lsvg -o 等命令时候报错，odm库修复方法
某公司4台机器，在执行lspv lsvg -o 等命令时报错如下：
用strings命令查看CuAt文件，发现前两行内容不正常，确定为系统的ODM库损坏所致，通过查看ODM库文件的修改时间，某月某日10点20分左右有多个ODM库文件被修改，可能被损坏的文件包括CuAt,CuAt.vc,CuDvdr三个文件。
尝试修复ODM库文件：
方法1：
1、用UE打开CuAt文件，发现该文件的头信息被篡改，与正常机器的CuAt对比，损坏的文件体现为该文件的前7行内容跟其他CuAt文件不一致。
2、如果要手动修复该文件，可以将这七行信息按照正常的CuAt文件修改，对于正常的CuAt文件来说，CuAt条目数应该是32位long int型变量，第一行4、5、6、7列的值表示CuAt文件中现有的条目数，odmget在取值时会参考该数值的大小，即如果该值为1，则只会取到一条记录。
因此如果要修复该文件的话需要知道CuAt的确切条目数，如果将其设置为一个很大的值，那么在执行odmget CuAt之后，多余的条目会以如下空条目形式显示，根据该方法可以判断确切的条目数，再转换为16进制写到相应的位置。
方法2：
1、对于HA环境来说，每次verify成功后，HA都会保留一份ha所用到的odm库文件的备份，位于/var/hacmp/odmcache/<nodename>/_etc_objrepos目录，该备份文件为最后一次有效的odm库文件。
2、我们可以直接找到该文件进行还原，在备份好odm库之后，可以对涉及到被损坏的文件CuAt和CuAt.vc，CuDvDr进行在线替换，替换完之后执行lspv,lsvg -o即恢复正常。
