Solaris - Emulex HBA WWPN check

Régen blogoltam ide, de úgy gondoltam hogy ez még jól jöhet az utókornak, szóval ...

.. Adott egy ősrégi Solaris szerver (az a fajta ami a múzeumba se való már, olyan régi), aminél azt a feladatot kaptam, hogy a Storage szerverek zónázásakor használt WWPN numbert kinézzem. Tekintve hogy ez számomra alap feladatnak hangzott (AIX adminként), így gondoltam gyorsan végzek is a feladattal.. Hát a francokat..

Na nézzük miért is.
1) Mint mondtam a gép meglehetősen régi:

root@server[] # uname -a                                                 
SunOS server 5.6 Generic_105181-39 sun4u sparc SUNW,Ultra-Enterprise

/* Csak a miheztartás végett - az 5.6ot (aka Solaris 2.6) 1997ben adták ki (bár 2006ig támogatott maradt) */

2) A google jelen esetben nem a barátod
Hiába akad google-n 1-2 használhatónak tűnő tipp*, attól még sajna ez kevés a boldogsághoz ha a tippek közül egyik se működik, mert vagy nem elérhető a parancs amire hivatkozik, vagy nem kapok kimenetet, vagy amit kapok az láthatóan hülyeség.
-> scli, fcinfo, prtpicl, lputil64 nem létezik
-> 'prtconf -vp | grep -i wwn' hülyeséget dob vissza
-> /var/adm/messages* alatt egy bejegyzes sincs amiben a wwn vagy wwpn benne lenne
-> 'luxadm -e port' szerint az összes adapter not-connected state-ben van ami abszolút hülyeség, viszont ez miatt a 'luxadm -e dump_map' se működik.
-> 'iostat -XMzxn' közli, hogy a -X, -z kapcsoló nem értelmezhető

* A leghasználhatóbb talán ez: http://www.sunsolarisadmin.com/hardware/how-to-find-the-wwn-world-wide-name-in-sun-solaris/

3) Nem mindegy hogy milyen adapter van a gépben és hogy milyen driver hajtja
Az egy dolog, hogy csak 1-2 hivatalosan támogatott kártya elérhető, de mocskos módon még az se mindegy, hogy azt a kártyát milyen Storage megvalósításhoz szeretnéd használni, mert mindegyik megvalósításnak más-más driver kell, azok meg hajlamosak meglehetősen válogatósak lenni a támogatott kártyák között. Ehhez jön még hozzá, hogy nincs egységes tool a HBA-k kezelésére, hanem minden driverhez külön-külön utility set van ami így vagy úgy valósítja meg kb ugyan azokat a feladatokat (lscfg, de hiányoltalak én téged..)

4) Az se mindegy, hogy melyik verziójú drivered van fent
Mint utólag kiderült a 2. pontban leírt problémámba ay is erősen közrejátszott, hogz az idők során kiadott különböző driverek/toolok telepítési útvonala hajlamos volt időről időre változni, így ha nincs bent a $PATH-ban az adott tool akkor vagy tudod mi és hol van, vagy keresgélhetsz amíg meg nem találod (már ha tudod mit is kéne pontosan keresni)

Na szóval.. Ha tudni akarod, hogy hogy is kell megtekinteni egy HBA WWPN-jét, akkor:
- Tudnod kell, hogy pontosan milyen kártyáról van szó
- Tudnod kell, hogy az adott kártyát milyen driver hajtja
- Tudnod kell, hogy az adott driver tooljai hol találhatóak
- Tudnod kell, hogz a toolok közül melyik is alkalmazható a te általad megálmodott feladatra, és azt is hogyan.

Hát gyerekek. Aki a Linux alatt sír hogy mennyire össze van gányolva, és hogy mennyire de nem egységes, azt isten bizony odaültetném egy ilyen elé.

Na de vissza térve az én esetemre.
- Milyen HBA van a gépben?

root@server[] # prtdiag -v |grep SBus |grep sd
1   SBus    25     0  lpfs/sd (block)                   LP9002S
1   SBus    25     3  SUNW,fas/sd (block)
3   SBus    25     1  QLGC,isp/sd (block)               QLGC,ISP1000U
3   SBus    25     2  lpfs/sd (block)                   LP9002S
3   SBus    25     3  SUNW,fas/sd (block)
5   SBus    25     1  QLGC,isp/sd (block)               QLGC,ISP1000U
5   SBus    25     2  QLGC,isp/sd (block)               QLGC,ISP1000U
5   SBus    25     3  SUNW,fas/sd (block)

- Lehet is nyomban válogatni, tekintve, hogy 2 is van. Az 1ik ránézésre valami QLogic cucc (sd driver-rel), a másik meg csak annyit mond magáról, hogy LP9002S. Kis google után utóbbiról kiderül, hogy 2Gbps Emulex Fibre channel adapter, míg az első egy sima SCSI vezérlő (így azzal most nem foglalkozok). Annyi segítséget a gép adott, hogy az Emulex kártyát az lpfs driver hajtja, így már csak azt kell kitalálni, a driverhez tartozó segédprogramok hol is találhatóak
- Első körben tudni kell a csomag nevét:

root@server[] # pkginfo |grep lpfs
system      lpfs                 Emulex LightPulse FC SCSI/IP Host Bus Adapter driver

- Ebből kiindulva aztán érdemes megnézni, hogy mi is van a csomagban:

root@server[] # pkgchk -l  lpfs|grep Pathname |egrep "bin|sbin"
Pathname: /usr/sbin
Pathname: /usr/sbin/lpfs
Pathname: /usr/sbin/lpfs/QS_fmw
Pathname: /usr/sbin/lpfs/REV_fmw
Pathname: /usr/sbin/lpfs/dfc
Pathname: /usr/sbin/lpfs/dfc32
Pathname: /usr/sbin/lpfs/dfc64
Pathname: /usr/sbin/lpfs/download_fmw_lpfs
Pathname: /usr/sbin/lpfs/lpsutil
Pathname: /usr/sbin/lpfs/lpsutil32
Pathname: /usr/sbin/lpfs/lpsutil64
Pathname: /usr/sbin/lpfs/resetqdepth

- Oksi. Akkor a /usr/sbin/lpfs mappában kéne körbenézni. Kérdés, hogy mi is használható ezek közül.

Az mondjuk kb tiszta, hogy a QS_fmw és a REV_fmw valami firmware féleség lehet, így azokhoz inkább nem nyúlok. A download_fmw_lpfs hasonló okok miatt esik ki (lekérdezni akarok, nem módosítani). A dfc-ből, illetve az lpsutil-ból a jelek szerint 3-3 file is elérhető: 1 központi, illetve 1-1 32/64 bit specifikus (Ránézésre a fő bináris feladata, hogy megítélje, hogy a rendszer 32 vagy 64 bites rendszeren fut e, és az alapján meghívja a szükséges binárist). Ezen felül van még a resetqdepth, ami a nevéből illetően piszkálni akar valamit, viszont mint kiderül lényegében csak egy script:

root@server[] # cat /usr/sbin/lpfs/resetqdepth 
#!/bin/sh
# $Id: resetqdepth.sh 1.6 2001/03/07 00:12:00 mks Exp $
case $1 in
        [0123456789]*)
                ;;
        *)      echo Usage: resetqdepth adapter_number
                exit 1
                ;;
esac
/usr/sbin/lpfs/dfc > /dev/null <<!
set board $1
rqdepth
exit
!
exit 0

Természetesen ezt lefuttatni nem akarom, viszont a tény hogy a fentebb említett dfc parancsra támaszkodik egy EOF here tag-el ad némi reményt arra hogy esetleg valami belső parancs készletre támaszkodó programmal van dolgunk.

Így hát elindítva a dfc programot az alábbi kimenetben gyönyörködhetünk:

root@server[] # /usr/sbin/lpfs/dfc                                               
LightPulse Engineering Debug Utility                                                        
Copyright (c) 1999, 2000 Emulex Network Systems, Inc.                                       

Do not run this utility unless instructed by Emulex Technical Support

Found 0 PCI 2 SBUS adapters: onmask 3f58f offmask 1e7 Driver:4.21x1
Adapter 0: lpfs1 SBUS id df1095f0 Firmware:3.90A7 (R2F3.90A7)      
Adapter 1: lpfs0 SBUS id df1095f0 Firmware:3.90A7 (R2F3.90A7)      
cmd> 

Szupi.. Szóval kapunk egy belső command line-t.. Nézzük mit lehet benne mókólni (és lehetőleg nem elszúrni :))

cmd> help                                                          
  rdallpci      wrpci       wrhc       wrhs                        
      wrha       wrca      rdpci       rdhc                        
      rdhs       rdha       rdca       rdmb                        
      exit        set      rring      rslim                        
     riocb       rrpi        rbp    rmemseg                        
      mbox      reset     rbinfo    nddstat                        
    fcstat      wslim     wffreg     rffreg                        
     sdiag        dbg      rnode      rdevp                        
  instance        lip   linkinfo     ioinfo                        
  nodeinfo     getcfg     setcfg     failio                        
  outfcpio    rqdepth         ct    hbaattr                        
  portattr   portstat  dportattr  wportattr                        
 iportattr     fcpmap    fcpbind    setmgmt                        
   getmgmt       rnid   getevent  resetstat                        
  sendscsi    refresh        els  getmpulse                        
 setmpulse      listn      trace       help                        
         p

Sajna a fejlesztők arra már nem szánták rá magukat, hogy a help parancsot kibővítsék az alparancsok leírásával is, így némi kis próbálkozás után sikerül eljutnom csak az alábbi kimenethez:

cmd> linkinfo                                                                               
Event 0x0  Up 0x1  Down 0x0  Multi 0x0                                                      
PortID 0x0  alpa 0x0  topology 0x4 state 0x1                                                
ALPAmap 0:                                                                                  
Portname 10:00:00:00:ab:cd:ef:01  Nodename 20:00:00:00:ab:cd:ef:01  

Na ez már végre az amit akartam.. Az egyedüli bajom csak az, hogy a parancs ismételt kiadásával ugyan ezt az eredményt kapom vissza, viszont ebben a gépben (ahogy fentebb is látható volt) 2 HBA kártya van.. Valahogy rá kéne venni a programot, hogy a másik kártya adatait is le lehessen kérdezni.

Ekkor ugrott be a fenti script, ami képes volt tetszőleges adapterre lefuttatni az rqdepth parancsot. Mindezt a set board $1 parancsal, úgy hogy nyomban mentem is vissza az újonnan megismert subshellem alá további tesztelésre:

root@server[lpfs] # ./dfc                                           
LightPulse Engineering Debug Utility                                       
Copyright (c) 1999, 2000 Emulex Network Systems, Inc.                      

Do not run this utility unless instructed by Emulex Technical Support

Found 0 PCI 2 SBUS adapters: onmask 3f58f offmask 1e7 Driver:4.21x1
Adapter 0: lpfs1 SBUS id df1095f0 Firmware:3.90A7 (R2F3.90A7)      
Adapter 1: lpfs0 SBUS id df1095f0 Firmware:3.90A7 (R2F3.90A7)      
cmd> set board 0                                                   
cmd> linkinfo                                                      
Event 0x1  Up 0x1  Down 0x0  Multi 0x0                             
PortID 0x633613  alpa 0x13  topology 0x3 state 0x6                 
ALPAmap 0:                                                         
Portname 10:00:00:00:ab:fd:08:04  Nodename 20:00:00:00:ab:fd:08:04
cmd> set board 1                                                   
cmd> linkinfo                                                      
Event 0x0  Up 0x1  Down 0x0  Multi 0x0                             
PortID 0x0  alpa 0x0  topology 0x4 state 0x1                       
ALPAmap 0:                                                         
Portname 10:00:00:00:ab:cd:ef:01  Nodename 20:00:00:00:ab:cd:ef:01 
cmd> exit

Buli.. Igy mar szepen megy is minden, mint a karika csapás. Akkor már csak az maradt, hogy le is scriptljük a dolgot:

root@server[] # cat /tmp/emulex_wwpn_query.sh
#!/usr/bin/ksh
PACKAGE_NAME=`pkginfo |grep SCSI |egrep "lpfc|lpfs" |cut -d ' ' -f2`
DFC_PATH=`pkgchk -l $PACKAGE_NAME |grep Pathname |grep dfc$ |cut -d ' ' -f2`
while true
do
$DFC_PATH 2>&1 << !
exit
!
break
done |grep Adapter |cut -d ' ' -f 2 |sed "s/://g" |while read ID
do
$DFC_PATH 2>&1 << !
set board $ID
linkinfo
exit
!
done |grep Portname |cut -d ' ' -f 2 |sed "s/://g" |tr 'a-z' 'A-Z'

root@server[] # sh /tmp/emulex_wwpn_query.sh
10000000ABCDEF01
10000000ABFD0804

Trolloknak előre megjegyzem: ezen az ősrégi vackon a pipe feldolgozási sorrendje nem tudom miért de valahogy eltér a megszokottól; a $() nem működik, helyette van backtick (`), az viszont valamiért nem szeret több parancsot 1 soron belül látni; Talán pont a pipe-olás miatt az awk se működik úgy ahogy azt elvárnám, így fallbackeltem az ódivatú parancsokra, mint cut, grep, sed, tr (amit amúgy egy awk simán ki tudna váltani, viszont ha nincs ló, jó lesz a szamár is.. ). Amúgy ha valakinek van ötlete, hogy while; do ... done módszeren kívül hogy lehet még greppelni egy here tag (jelen esetben !) után az ne fogja vissza magát :)

HMC upgrade - Generációs problémák

Előző blogbejegyzésemben megemlítettem, hogy "szerintem" a HMC upgrade-ről nem lehet tartalmasan írni, mire egyik ismerősöm rámutatott arra, hogy hiába nem olyan hajmeresztő a téma, attól még neten nem hogy magyarul, de angolul sincs normális dokumentáció ilyen jellegű HMC upgrade-ről távoli upgrade-et tekintve. Így hát vettem a bátorságot és azt gondoltam, hogy ha másért nem, hát azért is leírom, hogy mivel is jár egy ilyen szintű upgrade előkészítése, kivitelezése, illetve mily buktatók vannak amire nem árt figyelni. Hosszú post következik, mindenki készítsen elő 1 hétre való hideg élelmiszert, meg konzervet :)))

Na szóval.. A feladat a következő: Adott egy csomó, pár generációval régebbi HMC, amik mind-mind valami über-fontos rendszert támogatnak (hogy ez mennyire fedi a valóságot az más kérdés - a customernek mindig minden über fontos). További információ, hogy a HW típusok, illetve a telepített HMC verziók is meglehetősen eltérőek, illetve minimalizálni kéne az onsite support nyújtotta lehetőségeket (a lehetőség adott, csak épp fizetni kell érte, amit meg valahogy az ügyfelek sose akarnak, mondván hogy "Hát azért fizetünk téged, hogy megcsináld.." )

Ezzel a felemelő tudattal lássuk hát mis is lehet tenni és hogyan.
1x is, nézzük, hogy a neten milyen információk érhetőek el jelenleg, avagy miből élünk:
Upgrading the HMC from Version 4.3, 4.4, or 4.5 to Version 6.1.3
Upgrading the HMC from Version 6.1.2 (or Later) to Version 7.3.2

Ezek a leírások szépen le is írják, hogy hogyan kéne a HMC-ket upgrade-elni, de hogy-hogy nem csak a local DVD-RAM-ra támaszkodnak, ami meg nekünk most nem sokat segít (hacsak nem tudunk valakit rábírni, hogy fizesse az utazási költséget, meg biztosítsa a fizikai hozzáférést az érintett HMC-khez). Egy dologra viszont azért még is használhatóak: Kb kideríthető, hogy az upgrade útvonal valami ilyesmi kéne legyen:
4.x-> 6.1.3 (plusz a szükséges fixek) -> 7.3.2 -> 7.7.x (jelenlegi latest)

Na persze ez önmagában még nem elég: Van egy olyan sajnálatos része is a dolognak, hogy a HMC által managelt box(ok) alatt futó firmware-nek is kompatibilisnek kell lennie a HMC-vel, különben az képtelen lesz kommunikálni az FSP-vel, minek következtében a HMC nem fogja tudni managelni a boxot (ergo pont azt a funkcionalitást veszítjük el, amiért a HMC-t tartjuk). Így sajna figyelembe kell vegyük azt is, hogy HMC upgrade előtt a boxok FW-je is megfelelő szinten legyen.

Ebben segítenek az alábbi doksik:
- Supported combinations for HMC and Power 5 Server code: http://www14.software.ibm.com/webapp/set2/sas/f/power5cm3/sftablep5.html
- Minimum FW levels: http://www-912.ibm.com/s_dir/slkbase.NSF/1444e529a72ba96486256a6400681992/c69799b70a28578c8625712c004fe06b?OpenDocument
- HMC 7.3.x es afölött: http://www-933.ibm.com/support/fixcentral/firmware/supportedCombinations
- Power5,P590, p505: http://www14.software.ibm.com/webapp/set2/sas/f/power5cm3/supportedtable2.html
- Power5, exlcuding p590, p595: http://www14.software.ibm.com/webapp/set2/sas/f/power5cm3/supportedtable1.html

További hasznos infó az, hogy jelenleg mely HMC verziók támogatottak is:

https://www-304.ibm.com/webapp/set2/sas/f/power5cm/eoss.html

.. illetve hogy mely HMC-k pontosan meddig is húzhatók fel:

AIX, VIOS and HMC Facts and Features (17. oldal)

Na most mindez után egy pillanatra álljunk meg.. Ugye azt mondtam, hogy azért itt akad 1-2 elég régi generációs masina is, ami azért magával von 1-2 meglehetősen fontos dolgot:
- Ha a HMC nem 1 mai darab, akkor valószínű, hogy a managelt box se.
- Ha a managelt box nem 1 mai darab, és még mindig alacsony HMC mellett üzemel, akkor a firmware se lehet épp a legfrissebb
- Ha upgrade-elni kell egy régebbi HMC-t, hogy supported szinten legyen, akkor az az alábbi dolgokat jelentheti:

- Vagy egy Power4es vasunk van aminél a legmagasabb elérhető szint a 3.3.7 (még ez év végéig támogatott)

- Vagy Power5ös, ami azt jelenti, hogy a HMC-nk 4.5.x-től bármelyik azóta kiadott HMC szóba jöhet

# Kis megjegyzés - Power6-Power7 nagyon nem jöhet szóba, tekintve, hogy azok annyira nem régiek, meg azokhoz min HMC v7.3.x dukál ..

- Ahhoz hogy egy p5-ös gépet (jelenleg; 2012.08.21) támogatott szintre felhúzzunk az alábbi HMC-k valamelyikével kell rendelkezzünk:

    - 7310-C05,7310-CR3 -> 7.7.x

    - 7310-C04,7310-C03, 7310-C02 -> 7.3.x

- Power5 alatt jelenleg egyik supported HMC se támogatja a régi FW-ket (Release 240 elöttiek), ergó az FW upgrade-et tuti nem ússzuk meg (Distruptive upgrade ==> Teljes box leállást igényel, így minden LPAR-t le kell kapcsolni mielőtt ennek nekiállunk)

Ha Power4ünk van, akkor könnyű dolgunk lesz (feltéve, hogy min 3.3-as szinten van a HMC). Ha viszont Power5-ről beszélünk (és a fent említett 5 modell valamelyikével áldott meg minket a sors), akkor már macerásabb helyzetben találhatjuk magunkat, tekintve, hogy abban az esetben a 4.5.x HMC se elképzelhetetlen.

Na jó.. Akkor ez után nézzük mit is lehet távolról egy nyomorult internet hozzáféréssel csinálni.
Alap járaton ugye adott a fix/service pack telepítésének lehetősége, ami viszont nem jelent verzió ugrást (mondjuk egy 3.3.x-> 3.3.7 telepítéséhez ez még bőven elég). Ahhoz, hogy verziók között tudjunk ugorni (6.x->7.x) szükségünk van az úgy nevezett "alternate disk installation" nevű módszerre (vagy akik AIX-földről jöttek annak az alt_disk_boot lehet ismerősebb). A probléma ezzel csupán annyi, hogy ez a parancs csak az 5.2.1-es verzió óta érhető el, következés képen ha version 5.x, vagy afölött vagyunk akkor még van remény (verzión belül tudunk ugrálni mint mondtam, ergo 5.x-ről fel tudjuk húzni remote 5.2.1ig a HMC-t), ha viszont egy v4.x HMC-vel hozott össze a sors, akkor kötelezően szükségünk lesz valakire aki helyben felhúzza a HMC-t egy számunkra kellemes szintre (Ennyit a customer elvárásairól ez esetben :D Mázlira 4.x-ről direkt lehet ugrani 6.1.2-re local DVD-RAM-al, tovább viszont a firmware függőségek viszont nem.)

További "kellemes" problémaforrás, hogy amennyiben a 7310-C03 HMC-vel hozott össze a sors minket, úgy nem csak a box(ok) FW upgrade-je miatt kell fájjon a fejünk, hanem a HMC BIOS upgrade-je (!) miatt is, mielőtt fel akarnánk az vinni v6.1.x vagy afölé (amihez szintén helyi technikus kell :))
https://www-304.ibm.com/support/customercare/sas/f/hmcl/bios/home.html

# Kis segítség: az 'lshmc -b' paranccsal meg lehet nézni milyen verziójú BIOS fut a HMC-nk alatt

Na akkor összegezzük hogy mit is kéne csinálni:
- Ha a sors egy 7310-C03 HMC-vel hozott össze, akkor onsite technikus segítségével a BIOS-t fel kell upgrade-elni, mielőtt bármit is csinálnánk
- Ha egy v4.x HMC-vel hozott össze a sors, akkor szintén onsite technikus segítségét kell kérjük, hogy a HMC-t 6.1.2 felhúzza
- Ha a HMC-nk meg a 3.3.x idők elötti verzión fut, akkor local technikus fog ismételten csak kelleni:

http://www-304.ibm.com/webapp/set2/sas/f/hmc/p4lpp/related/tip001_upgrade2to3.html

http://www-304.ibm.com/webapp/set2/sas/f/hmc/p4lpp/related/hmc31tohmc337.html

- Ha a HMC-nk v3.3.x verzión fut, akkor nincs mitől félnünk, a standard update process-t alkalmazva

http://www.www-304.ibm.com/webapp/set2/sas/f/hmc/power4/download/v33.Update.html

http://www-01.ibm.com/support/docview.wss?uid=isg3T1012428

- Abban az esetben ha a HMC-nk minimum v5.x-en fut, akkor az upgrade path a következő lesz:

- 5.1.0 -> 5.2.0 /* update */

- 5.2.0 -> 5.2.1 /* update */

- 5.2.1 -> 6.1.2 /* altdiskboot */

- 6.1.2 -> 6.1.3 (+ javítások) /* update */

- Firmware upgrade Release 240-re az összes HMC által managelt boxon

/* ajánlott upgrade a 240_382. Innen konkurensen lehet ugrani a latest 240_418-as verzióra */

- 6.1.3 -> 7.3.4 /* altdiskboot */

- 7.3.4 -> 7.7.7 (amennyiben lehetséges) /* altdiskboot */

- 7.7.7 -> 7.7.7.2 (amennyiben lehetséges) /* update */

Szükséges file-ok:

3.3.5 -> 3.3.7 (update) / HMC_Update_V3R3.7.zip

3.3.7 Corrective Service Fixes / U808917.zip, U810401.zip, U814685.zip, U860526.zip

4.x -> 6.1.2 (onsite only) / HMC_Recovery_V6R1.2_1.iso, HMC_Recovery_V6R1.2_2.iso

5.1.0 -> 5.2.0 update / HMC_Update_V5R2.0_1.zip, HMC_Update_V5R2.0_2.zip

5.2.0 -> 5.2.1 update / HMC_Update_V5R2.1_1.zip, HMC_Update_V5R2.1_2.zip

5.2.1 -> 6.1.2 - netinstall / bzImage, disk1.img, disk2.img, disk3.img, initrd.gz

6.1.2 -> 6.1.3 update / HMC_Update_V6R1.3_1.zip, HMC_Update_V6R1.3_2.zip, HMC_Update_V6R1.3_3.zip, HMC_Update_V6R1.3_4.zip

6.1.3 Corrective Service Fixes / MH01082.zip, MH01110.zip, MH01127.zip, MH01128.zip, MH01168.zip

6.1.3 -> 7.3.4 - netinstall / bzImage, disk1.img, disk2.img, disk3.img, hmcnetworkfiles.sum, initrd.gz

7.3.4 -> 7.7.7 - netinstall / bzImage, disk1.img, disk2.img, disk3.img, hmcnetworkfiles.sum, initrd.gz

7.7.7.0 -> 7.7.7.2 update / HMC_Update_V7R770_SP2.iso

7.7.7.2 Corrective Service Fix / MH01367.iso

Ha eddig tudtál követni (és a tervezésnek minden kellemes percét kiélted már), akkor most jön arra a kérdésre a válasz, hogy akkor mit és hogyan.
Kezdjük talán a hivatalos dokumentációval:

Remote upgrade from HMC 5.2.1 using network images

Upgrading or installing HMC V7 over a network

Feltételezve, hogy eljutottunk arra a szintre, hogy a HMC-nk valóban távolról upgrade-elhető, nézzük hogy hogyan is kéne ennek elvileg lezajlania:
- Nulladik körben kell egy szervert találni, ami a HMC-vel viszonylag jó hálózati kapcsolattal bír, lehetőleg a tűzfal nem blokkolja az FTP/NFS kapcsolatokat, és fel tudjuk rá tölteni az összes szükséges Firmware és HMC update/upgrade file is.

# Jó tanács: Érdemes egy kb 50 MB-os file-t SCP-vel feltolni a HMC-re tesztelni, hogy a hálózat milyen sebességet képes nyújtani.

- Első körben csinálunk valami nyamvadék backupot ha tudunk:

- HMC v3.x sajna csak local DVD-RAM-ra tud bármilyen backupot küldeni, így ott ha lehet, akkor kérjünk meg valakit, hogy rakja be a szükséges optikai lemezt a helyére. Ha ez nem megoldható akkor egyik jó kollégám mondásával élve "Don't be afraid to be a cowboy", persze azért a "Kockázatokról, és lehetséges mellékhatásokról kérjük értesítse ügyfelét, vagy jogász ismerősét", csupán a kényelmetlen kérdések elkerülése végett.

- HMC v4.x óta van lehetőség a "Critical Console Data"-t egy NFS szerverre feltolni, amit meglehetősen tudok is ajánlani (hogy pontosan miért azt kicsit később)

- Második körben én komolyan azt tanácsolom, hogy ha lehet akkor az alábbiak közül minél többet tartsunk készenlétben:

- PESH jelszó (vagy épp kedvenc rbash escape modszer, ha ismersz ilyet) a HMC-nkhez (mind a 7.3 előtti, mind az utáni PESH jelszó)

- Onsite technikus (aka local support) ha valami tényleg balul ütne ki

- 3. körben szintén egy jó tanács: Mielőtt elkezdünk upgrade-elgetni, indítsuk újra a HMC-t. Hogy miért?

- Nem szeretem amikor X napja/hónapja beragadt processek szívatnak meg

- Jobb leellenőrizni, hogy a HMC egyáltalán képes e magától talpra állni (a restartot meg amúgy se ússzuk meg, szóval inkább még az elején derüljön ki ha valami gáz van, mintsem arra gyanakodjunk, hogy az update/upgrade szúrt el valamit)

- Induláskor 1-2 diagnosztikai rutin azért lefut, szóval ha van valami gáz, akkor ha mákunk van még elcsíphetjük a /var/log/messages-ben.

- Érdemes lehet még kicsit kipucolni a HMC-n 1-2 dolgot is mielőtt elkezdjük felforgatni a mindenséget :)

- Event-ek lezárása: chsvcevent –o closeall

- Logok ürítése: chhmcfs –o f –d 0

/* Ezzel a lépéssel amúgy nem teljesen értek egyet auditálhatósági szempontból, de ki ki ítélje ezt meg maga. */

- Mindezek után jön az, hogy akkor update/upgrade-eljünk. Attól függően, hogy verzión belül maradunk e, vagy épp ugrunk más-más módszert kell alkalmazni:

- alternate disk install:

saveupgdata -r disk
getupgfiles -h $SERVER -u $USER -d $SOURCE_DIRECTORY
chhmc -c altdiskboot -s enable --mode upgrade
hmcshutdown -r -t now

- Update: (ISO vagy zip file-okból)

Távoli szerverről: updhmc -f /$FILE_FULL_PATH -h $SERVER -r -t s -u $USER -i

Előzőleg feltöltött file-ból: updhmc -f /$FILE_FULL_PATH -h $SERVER -r -t l -c

# Megjegyzések:
- Megoszlanak a vélemények, hogy az update-et console-ról, vagy az elérhető GUI-s (WebSM, Web-es) felületről érdemesebb e csinálni. Számomra a console gyorsabb (próbált már valaki WebSM-et futtatni 2 proxy mögül? :)), cserébe a GUI-s felület informatívabb (bár sikerült belefutnom olyan hibába, ahol viszont nem az elvárt módon működött, míg a parancssori megfelelője meg igen - erről később)
- Lehetőség van előzőleg a HMC-re feltöltött file-ból update-elni, de amennyiben alternate disk install-t is kell csinálnunk, úgy sajna csak az FTP szerver jön szóba hivatalosan. /* Nem hivatalosan root hozzáféréssel ezt meg tudjuk kerülni - erről is majd kicsit később)
- Ha jól rémlik 7.3.5-ös verzió óta van lehetőség a getupgfile parancsnál SFTP használatára a "-s" kapcsolóval
- Alternate disk install esetén, ha a saveupgdata parancsot elfelejtettük lefuttatni, vagy a parancs nem tudott mindent lementeni, akkor számoljunk vele, hogy a HMC nem fogja visszaállítani se az előzőleg létrehozott usereket, se a hálózati beállításokat, se az FSP-k kapcsolódási adatait => Lesz egy csupasz upgrade-elt HMC-nk, ami nemhogy nem managel egy boxot se, de még hálózatról se lesz elérhető. Ilyen esetben helyi technikus kell a hálózat beállításához és/vagy az előzőleg kreált "Critical Console Data" visszaállításához.

És akkor ami ezen felül még szerintem jó ha van:
- Egy alternativ session-ünk ahol monitorozni tudjuk, hogy épp hol tart a HMC (mondjuk az adat feltöltésben)

# getupgfiles parancs esetén a már letöltött file-ok a /hmcdump alá kerülnek

# updhmc parancs esetén a letöltött adat a /usr/local/hsc_install.images/ alá kerül

- Még jobb ha az a session root hozzáféréssel bír (na miért írtam a PESH-t?), ugyan is nem 1 olyan eset jött szembe, ahol igen is root hozzáférés kellett ahhoz, hogy a problémával tudjak valamit kezdeni.

Íme 1-2 példa:
- 3.3.7 alatt előjött hiba: az updhmc parancs elszáll az alábbi hibaüzenettel: "An error occurred while trying to run corrective services. Please check your entry and retry command."

- Megoldás: Nézzük meg a dátum beállításokat :) (Na jó, ezt root hozzáférés nélkül is lehet javítani (chhmc -c date -s modify), viszont a debughoz itt is kelett a root hozzáférés)

- 6.1.3 HMC alatt a saveupgdata parancs elhasal "Exception in thread "main" java.lang.NoClassDefFoundError: com/ibm/jcb/JCApplicationListener" hibával

- Megoldás: pakoljuk fel újra az alábbi javításokat ebben a sorrendben: MH01082, MH01110, MH01128, MH01127,MH01168 (Ne felejtsük el újraindítani a HMC-t mind1ik után). Ez még megy root hozzáférés nélkül.

- Majd töröljük a /tmp/saveupgrade.list file-t, és indítsuk újra a rendszert (a file törléséhez sajna már root hozzáférés kell)

# Kis kiegészítő információ: Ez a hiba több HMC-n is előjött, viszont a hibát ténylegesen csak a parancssorból hívott saveupgdata jelentette, a GUI alatt elérhető hasonló funkció vígan közölte, hogy minden rendben. Ez a "hiba" sajna egy meglehetősen kellemetlen restore-al javult csak meg, miután a site-on lévő technikus konstatálta, hogy a HMC semmiféle információt nem töltött vissza az upgrade process során.

- 7.3.4 alatt a getupgfiles az alábbi hibával elszáll: "The file bzImage appeared to be missing, or the transfer did not complete successfully, resulting in an incorrect file size or checksum. Please retry the operation." A parancs ismételt kiadása nem segít semmit.

- Megoldás: Valószínű betelt a /hmcdump FS. Kénytelenek leszünk manuálisan törölni a file-okat, majd megismételni a getupgfiles parancsot.

- Szintén 7.3.4 alatt sikerült egy olyan furcsaságba belefussak, hogy a hmcshutdown -r -t now kiadása után az SSH már leállt, illetve a HMC parancsok se működtek már, de a HMC valahogy mégse bírt ujraindulni magától: root console alól shutdown -r -t now segített csak.
- Verzió független issue: Volt szerencsém olyan HMC-hez is, ami ugyan látta a repository szervert, viszont a kapcsolat a 2 szerver között csodás 30 kb/sec-el tántorgott. Mit csinál ilyenkor az ember? Megpróbálja megszakítani a parancsot egy CTRL+C-vel, majd egy másik (immár gyorsabb szervert használva) helyről áttölteni az adatot. Na most a CTRL+C lenyomásával nincs is gond, az ember szépen vissza is kapja a terminálját.. Na de viszont amikor egy immár remélhetőleg gyorsabb helyről ismét elindítjuk a programot (illetve monitorozzuk is a folyamatot), akkor észre vehetjük hogy egyszerre több file is változik egyszerre. A dolog mögött pedig az áll, hogy a CTRL+C lenyomásakor a parancs ugyan vissza adja a parancssort, viszont a parancsot nem állítja le.

# Amennyiben ilyen helyzetbe kerülünk lehet simán jobban járunk ha root jogokkal kill-eljük a programot, és manuálisan scp-vel feltoljuk a csomagot a szükséges helyére (getupgfiles esetén ne feledkezzünk el a /hmcdump felmountolásáról se, ha esetleg le lenne csatolva)

# Pro tipp: Az alábbi paranccsal követhetjük, hogy milyen (avagy mennyi) process fut a HMC-nken root hozzáférés nélkül is: (számolni a 'grep -c'-vel tudunk :))

# for i in $(ls -d /proc/[0-9]* |sed 's/\/proc\///g'|sort -n);do echo -e "$i\t $(cat /proc/$i/status |grep Name |sed 's/Name://g') $(cat /proc/$i/cmdline)";done

Utolsó jó tanács:
- Ha valaki nagyon ragaszkodik a GUI-hoz, és van SSH hozzáférése a HMC-hez, úgy lehet megéri ha SSH tunnelezi a GUI eléréséhez szükséges portokat, majd a localhost megfelelő portjára csatlakozva manageli a HMC-t (főleg ha a HMC proxy vagy tűzfal mögött van):

- WebSM esetén:

# export TARGET=${HMC_SERVER_ADDRESS}
# ssh -L 9090:${TARGET}:9090 -L 9940:${TARGET}:9940 -L 9443:${TARGET}:9443 -L 30000:${TARGET}:30000 -L 30001:${TARGET}:30001 -L 30002:${TARGET}:30002 -L 30003:${TARGET}:30003 -L 30004:${TARGET}:30004 -L 30005:${TARGET}:30005 -L 30006:${TARGET}:30006 -L 30007:${TARGET}:30007 -L 30008:${TARGET}:30008 -L 30009:${TARGET}:30009 hscroot@${TARGET}
# /opt/websm/bin/wsm /* Majd a kapcsolódási adatoknál a szervernév localhost */

- Web-based GUI esetén:

# ssh -L 8443:${HMC_SERVER_ADDRESS}:443 hscroot@${HMC_SERVER_ADDRESS}
# firefox https://localhost:8443

# Figyelem - ez a módszer (sajna) nem használható az ASMI felület eléréséhez

Ezek után még csodálkozik valaki, hogy ennyi macera mellett a hivatalos doksik az onsite upgrade-et részesítik előnyben? :)

"Még jőni kell, még jőni fog egy jobb core.." - Népköltés..

Majd 3 hónap.. Ennyi ideje nem írtam erre e blogra semmit..
Nem azért mert szabadságon voltam, vagy mert elfelejtettem.. Egyszerűen nem volt miről írni ami erre a blogra tartozott volna (az, hogy hogyan lehet Monitoringot migrálni, meg HMC-t 4.4-rol 7.7re felupgrade-elni nem olyan jó alapanyag higgyétek el), vagy pedig szimplán olyan természetű volt amit a jelenlegi szerződésem nem enged meg (pedig jó lenne írni egy cikket róla.. ki tudja, majd 1x talán).
Hiába, ez van ha az ember nem foglalkozhat a hétköznapi adminisztrációval, hanem csak "project tevékenységekkel"

Ami azt illeti, a mostani téma se olyan nagy eresztés, de gondoltam azért még valakinek így is jól jöhet még ez.

Na szóval a helyzet: Adott egy core file a rendszeren (VIO szerver), ráadásul meglehetősen nagy méretben:

server@root # ls -l /core
-rw------- 1 root system 829566976 Jul 27 19:45 core

Igen, ez egy majd 800 MB-os darab, ráadásul a / FS alatt, amit a rendszer adminok nem véletlenül utálnak, legfőképp VIO szervereken.
A feladat: kideríteni, hogy:
- Mi dobta a core-t
- Miért dobta az a valami azt :)

Az első kérdésre alap esetben azt mondanám, hogy az errpt-ben nézzünk körbe, viszont most pont sikerült egy olyan helyzetbe bele fussak, ahol az errpt (más hibák miatt) már rotálódott, szóval más utat kell találni ennek kiderítésére. Sebaj, van 2 módszer is amit lehet használni:

1) - strings parancs: kicsit ügye fogyott, de azért még jól használható arra, hogy 1-2 környezeti adatot megismerjünk :)

server@root # strings /core | grep ^_=
 _=/opt/IBM/ITM/aix523/va/bin/kvaagent
 _=nY
 _=/usr/bin/grep
 _=/u
 _=/u

Ebből persze még nem lehet sok mindent levonni, de az a /opt/IBM/ITM/aix523/va/bin/kvaagent igen kecsegtetően néz ki.

2) - lquerypv: Az ember nem is gondolná mennyire de hasznos tud lenni ez a kis parancs, pedig meglehetősen sokoldalú, ha tudjuk mit és hol is keressünk :) Jelen esetben a 6E0 cím az ami minket foglalkoztat, ugyan is AIX alatt a core file-on belül mindig ezen a címen kell legyen az aktuális bináris neve, ami a core-t dobta:

server@root # lquerypv -h /core 6E0 16
 000006E0 61697844 61746150 726F7669 6465722D |aixDataProvider-|
 000006F0 36310000 00000000 00000000 00000000 |61..............|

aixDataProvider-61.. Ez persze nem sokat mond egy átlagos embernek, aki viszont dolgozott már ITM6 alatt VA agent-el az tudhatja, hogy ez az a process ami a kvaagent alatt fut szinte mindig, ergó jó nyomon járunk.

Nézzük a 2. kérdésre a választ.. Hogy került oda az a core.. Nos, ennek megállapításához több dolog is kell:
- Az aktuális bináris ami a core-t dobta (nem baj, azt az első lépésben már megtaláltuk, max a pontos helyét nem tudjuk még, de azt egy find se perc alatt megmondja :)
- DBX parancs azonos kernel és futtatókörnyezetben (Ez se gáz, max használjuk azt a gépet ahol az issue előjött :))
- Némi kis tudás, hogy mit is kéne nézni ...
- .. Illetve hogy hogy is kéne értelmezni..
Na haladjunk sorban, aztán meglássuk meddig jutunk..
- Na szóval, első pont: Az aktuális binárisunk.. Rövid find keresés, majd meg is találjuk a /opt/IBM/ITM/aix523/va/bin/aixDataProvider-61 alatt.
- Második pont: A dbx parancs a bos.adt.debug csomag része, ha nincs fent a gépen, akkor vagy feltesszük, vagy keresünk egy másik gépet ami megfelel a fenti kritériumoknak. Jelen esetben nekem épp fent volt a csomag :)
- Harmadik pont. Na itt jön a vicces rész. 1x is be kell hívjuk a core-t a dbx debuggerbe, majd meg kell néznünk hol is akadt el, aztán abból kitotózni, hogy mi volt a gond.
Kezdésként hívjuk be a dbx-et ay adott core file-ra:

server@root #  dbx /opt/IBM/ITM/aix523/va/bin/aixDataProvider-61 /core
 Type 'help' for help.
 warning: The core file is truncated. You may need to increase the ulimit
 for file and coredump, or free some space on the filesystem.
 [using memory image in /core]
 reading symbolic information ...warning: no source compiled with -g 
 
 Segmentation fault in . at 0x100286cc ($t1)
 0x100286cc (???) 7cc5212e stwx r6,r5,r4

Majd nézzük meg hol is hasaltunk el (where parancs):

(dbx) where
 get_diskstats() at 0x100286cc
 adp_get_diskstats(0x2ff21804) at 0x10005a88
 dt_CollectDiskData(0x3052a680, 0x30321748) at 0x1002d6a8
 dt_CollectData(0x3052a680, 0x30321748) at 0x10031b74
 itmTranslator(0x0) at 0x10032834
 main(0x1, 0x2ff21e40) at 0x1000619c

Na ez a legtöbb embernek nem mond semmit a kód ismerete nélkül (nyugi, az adminoknak se), viszont tökéletes kiinduló alap, hogy megnézzük, hogy ismert stack-ről van e szó (IBM jó szokása, hogy sokszor mellékelnek stack példát az ismert bugokhoz, így csak a stack ismeretével is el lehet indulni valamerre (Ha meg nem találunk semmit, akkor is rossz esetben a stack-el nyitni lehet egy PMR-t és hivatalos segítséget kérni).

Esetünkben mondhatni mázlink van: A 'get_diskstats adp_get_diskstats dt_CollectDiskData dt_CollectData itmTranslator site:ibm.com' google keresőszavak meglehetősen sok találatot adnak. A legjobb találat azt hiszem ez az oldal ahol 4 helyen is szinte azonos stack van (minimális eltérésekkel), így már csak arra kell rájöjjünk, hogy az oldalon említett IF0004 (version 6.2.2.2 FP4) valóban megoldja e a problémát. Ehhez persze nem árt tudni, hogy most épp milyen szinten van a progink :)

Erre ITM6 alatt 2 verzió van:
- Ha az UX agent is telepítve van, akkor /opt/IBM/ITM/aix526/ux/bin/itmver.sh script segítségével ki lehet kérni bármelyik agent verzió számát (sajna ez az én VIO-mon nem volt fent)
- A /opt/IBM/ITM/registry/ mappa alatt lévő file-ből ki lehet nézni a verziót direktben (grep a VRMF stringre) :)

server@root #  # grep VRMF /opt/IBM/ITM/registry/vaaix*.ver
 VRMF = 06220102

Jelen esetben ez a következőt jelenti: version 06.2.2.01.02 -> 6.2.2.1 FP02.

Bingó. /* Nem véletlenül standard policy az, hogy frissíts ha teheted, mert a hibák nagyja már esélyes, hogy javítva van */