AIX - Rootvg költöztetés - csak óvatosan!!

Történt az a vicces eset, hogy a rootvg-t át kellett költöztetni egy AIX gépen.. Ez alapvetően nem is nagy nehézség:
- extendvg rootvg [new_disk]
- mirrorvg rootvg [new_disk]
- syncvg rootvg # Menjünk biztosra
- unmirrorvg rootvg [old_disk]
- reducevg rootvg [old_disk]
- bosboot -ad /dev/new_disk
- bootlist -m normal [new_disk]

Ez szépen is megy.. De sajna van egy bökkenő, ha mksysb-t is szeretnénk futtatni a gépen ezek után - az elég durván elhasal, ilyesmi hibaüzenettel: 

0301-168 bosboot: The current boot logical volume, /dev/hd5,
        does not exist on /dev/hdisk0.

Mint kiderül: A szituáció az, hogy az mksysb-nk meghívja az mkszfile parancsot, ami pedig hív egy 'bosboot -qv'-t.
A szerencsétlen bosboot-unk pedig nagyon nem is törődik a rendszer állapotával, őt csak az érdekli, hogy mi van az NVRAM-ban, ergo ez így csak restart után menne neki..
Kivétel persze, ha kicsit megszeghetjük a szabályokat =>
Az IBM már egy ideje tisztában van az adott problémával, sőt hibajegyet is adtak ki rá: IZ90977. Ez alapján már nem nehéz kicsit áttúrni az mkszfile-t, hogy azt csinálja ami nekünk kell: A /usr/bin/mkszfile file-an a 399. sor környékén írjuk át a számunkra szükséges sort az alábbiak alapján: 

 +399 BOOT_BLKS=`LC_MESSAGES=C ${bosboot} -qv | ${tail} -1l | ${awk} '{print $2 * 2}'`
=>
 +399 BOOT_BLKS=`LC_MESSAGES=C ${bosboot} -qvd /dev/ipldevice | ${tail} -1l | ${awk} '{print $2 * 2}'`

Ezek után még figyeljünk arra, hogy a /dev/ipldevice-unk a megfelelő rhdisk-re mutasson: 

# Test_server:root > ls -l /dev/rhdisk5
crw-------    2 root     system       17,  5 Feb 18 15:01 /dev/rhdisk1
# Test_server:root > ls -l /dev/ipldevice
crw-------    2 root     system       17,  5 Feb 18 15:01 /dev/ipldevice

Innen pedig már az mkszfile-unk is jól lefut, illetve az mksysb se fog kardjába dőlni..

( LGee | 2011. 03. 31., cs – 17:02 )

Mi lenne, ha a mirrorvg _elott_ csinalnal mksysb-t? ;-)

szerk. es kimaradt egy unmirrorvg a regi diszkrol

Totál mind1.. Heti backup esetén ez így is úgy is gondot okoz..
Amúgy az unmirrorvg jogos.. fejből írtam, aztán ez kimaradt a nagy kapkodásban :) Javítva..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( Zahy v | 2011. 03. 31., cs – 19:44 )

Csak a szokásos szőrszálhasogatás. Ha ezt valaki automatikusan (vagy nem, de rendszeresen) akarja futtani, akkor: 


- reducevg rootvg [old_disk]
- bosboot -ad /dev/new_disk
- bootlist -m normal [new_disk]

helyett 


- bosboot -ad /dev/new_disk
- bootlist -m normal [new_disk]
- reducevg rootvg [old_disk]

szerintem a javasolható sorrend - ha ez így egyáltalán mehet. Nem szeretnél ott lenni, amikor a reducevg után elpánikol a rendszer és van egy rossz helyre mutató boot disk. (Már ha jól értem, hogy mi történik.) De nyugodtan felhomályosíthattok, ha valamit rosszul gondolok.

Mázli, hogy a reducevg csak a VGDA-t, meg az ODM-et piszkálja ( miután megnézte, hogy egyáltalán ki lehet e kapni a VG alól a diszket).. Hacsak nincs valami oltári nagy programozási hiba, akkor ott a rendszer nem omlik össze sztem :)
Viszont, hogy a hozzászólásom ne legyen vita indítő - annyiban igazad van, hogy a te módszered a minél hamarabbi stabilitásra törekszik, amivel viszont én is egyet értek.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Félreértettél: én arra gondoltam, hogy a szkripttől független okokból pánikol, csak éppen abban a félkész helyzetben. (És igazából nem a pánikon van a hangsúly, bőven lehet egy másik rendszergazda, aki közel ezzel egyidőben indít egy shutdown -t, ami a reducevg és a bosboot között jut el odáig, hogy "killall". Nyilván valószínűsége igen csekély :-) )