Migration nach AIX PCM kombiniert mit OS-Update

Bei den meisten AIX Systemen wird wahrscheinlich in regelmäßigen Abständen der SP- oder TL-Level aktualisiert. Es bietet sich an, bei einem solchen Update, die Migration von SDDPCM nach AIX PCM mit durchzuführen. Dies spart Zeit und einige Reboots, die ansonsten extra wegen der Multipathing Migration durchgeführt werden müssen.

In unserem Blog-Beitrag „Migration von SDDPCM nach AIX-PCM“ hatten wir die Migration für Standalone Systeme schon gezeigt.

Hier soll die Migration von SDDPCM nach AIX-PCM im Rahmen eines OS-Updates gezeigt werden, wobei das Alternate Disk Copy Verfahren zum Einsatz kommt. Der Ablauf ist im groben der folgende:

  1. Entspiegeln der rootvg um eine freie Platte für Alternate Disk Copy zu gewinnen.
  2. Ändern des Path Control Moduls (PCM) auf AIX PCM.
  3. Erzeugen der altinst_rootvg.
  4. Entfernen von Fixes in der altinst_rootvg.
  5. Durchführen des OS-Updates auf der altinst_rootvg.
  6. Installation von Fixes in der altinst_rootvg.
  7. Hinzufügen eines firstboot-Skripts um Platten-Attribute zu setzen.
  8. Ändern des Path Control Moduls (PCM) zurück auf SDDPCM.
  9. Booten von der altinst_rootvg.

Auf unserem Beispiel-System ist AIX 7.1 TL5 SP2 installiert, die Platten sind SVC-Platten, die über virtual FC Adapter angebunden sind. SDDPCM ist der aktuell aktive Multipathing-Treiber:

# oslevel -s
7100-05-02-1810
# lsdev -l hdisk0 -F uniquetype
disk/fcp/2145
aix01:/root> lsattr -El hdisk0 -a PCM -F value
PCM/friend/sddpcm
#

Wie schon im oben genannten Blog-Beitrag ausgeführt, ändern sich einige Platten-Attribute bei der Migration auf AIX PCM. Daher sollte man sich die aktuellen Attribute genau anschauen, um diese gegebenenfalls später zu übernehmen (zumindest teilweise). Exemplarisch schauen wir uns hier nur das Attribut queue_depth an, welches aktuell den Wert 120 hat:

# lsattr -El hdisk0 -a queue_depth -F value
120
#

Unser System besitzt eine gespiegelte rootvg:

# lsvg -p rootvg
rootvg:
PV_NAME           PV STATE          TOTAL PPs   FREE PPs    FREE DISTRIBUTION
hdisk3            active            399         232         00..01..71..80..80
hdisk0            active            399         240         00..01..79..80..80
#

Das System wurde von der hdisk0 gebootet:

# bootinfo -b
hdisk0
#

Daher lassen wir die hdisk0 in der rootvg und entfernen die hdisk3 aus der rootvg, um eine freie Platte für Alternate Disk Copy zu gewinnen.

# unmirrorvg rootvg hdisk3
0516-1246 rmlvcopy: If hd5 is the boot logical volume, please run 'chpv -c <diskname>'
        as root user to clear the boot record and avoid a potential boot
        off an old boot image that may reside on the disk from which this
        logical volume is moved/removed.
0516-1804 chvg: The quorum change takes effect immediately.
0516-1144 unmirrorvg: rootvg successfully unmirrored, user should perform
        bosboot of system to reinitialize boot records.  Then, user must modify
        bootlist to just include:  hdisk0.
# reducevg rootvg hdisk3
# chpv -c hdisk3
# bootlist -m normal hdisk0
#

Bevor wir nun mittels Alternate Disk Copy eine Kopie der rootvg erzeugen, stellen wir das System temporär auf AIX PCM um, ohne allerdings zu rebooten. Wird dann anschließend die altinst_rootvg erzeugt, dann ist in dieser die Umstellung auf AIX PCM schon vorgenommen!

# manage_disk_drivers -d IBMSVC -o AIX_AAPCM
********************** ATTENTION *************************
  For the change to take effect the system must be rebooted
#

Am Ende des OS-Updates machen wir diese Umstellung dann auf der rootvg wieder rückgängig, um den Original-Zustand mit SDDPCM zu haben.

Nach diesen Vorbereitungen starten wir nun das alt_disk_copy Kommando:

# alt_disk_copy -d hdisk3 -B
Calling mkszfile to create new /image.data file.
Checking disk sizes.
Creating cloned rootvg volume group and associated logical volumes.
Creating logical volume alt_hd5.
Creating logical volume alt_hd6.
Creating logical volume alt_hd8.
…
#

Auf dem System sind einige EFixes installiert, die wir vor dem Update noch aus der altinst_rootvg entfernen:

# emgr -l
ID  STATE LABEL      INSTALL TIME      UPDATED BY ABSTRACT
=== ===== ========== ================= ========== ======================================
1    S    102m_ifix  10/14/18 10:48:18            IFIX for Openssl CVE on 1.0.2m       
2    S    IJ03121s0a 10/14/18 10:49:04            IJ03121 for AIX 7.1 TL5 SP00         
3    S    IJ05822s2a 10/14/18 10:49:18            a potential security issue exists    
…
#

Aktivieren der altinst_rootvg:

# alt_rootvg_op -W -d hdisk3
Waking up altinst_rootvg volume group ...
#

Und entfernen der EFixes:

# INUCLIENTS=1 /usr/sbin/chroot /alt_inst /usr/sbin/emgr –r -n 3
+-----------------------------------------------------------------------------+
Efix Manager Initialization
+-----------------------------------------------------------------------------+
Initializing log /var/adm/ras/emgr.log ...
Accessing efix metadata ...
Processing efix label "IJ05822s2a" ...
…
Operation Summary
+-----------------------------------------------------------------------------+
Log file is /var/adm/ras/emgr.log

EFIX NUMBER       LABEL               OPERATION              RESULT           
===========       ==============      =================      ==============   
1                 IJ05822s2a          REMOVE                 SUCCESS          

Return Status = SUCCESS
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -n 2
…
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -n 1
…

(Hinweis: Bitte nicht die Variable INUCLIENTS vergessen, diese signalisiert das die Operation in einem Alternate Boot Environment stattfindet!)

Wir mounten nun die LPP-Source für den OS-Update per NFS von unserem NIM-Server:

# mount aixnim:/export/nim/lpps/aix710503lpp /mnt
#

Nun kann der OS-Update in der altinst_rootvg durchgeführt werden:

# alt_rootvg_op -C -b update_all -l /mnt
Installing optional filesets or updates into altinst_rootvg...
install_all_updates: Initializing system parameters.
install_all_updates: Log file is /var/adm/ras/install_all_updates.log
install_all_updates: Checking for updated install utilities on media.
…
installp:  * * * A T T E N T I O N ! ! !
        Software changes processed during this session require
        any diskless/dataless clients to which this SPOT is
        currently allocated to be rebooted.
install_all_updates: Log file is /var/adm/ras/install_all_updates.log
install_all_updates: Result = SUCCESS
#

Abschließend installieren wir noch einige EFixes, dazu mounten wir zunächst das Verzeichnis /mnt mit den Fixes in die altinst_rootvg:

# mount -v namefs /mnt /alt_inst/mnt
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -e /mnt/emgr/ppc/102p_fix.181127.epkg.Z
+-----------------------------------------------------------------------------+
Efix Manager Initialization
+-----------------------------------------------------------------------------+
Initializing log /var/adm/ras/emgr.log ...
Efix package file is: /mnt/emgr/ppc/102p_fix.181127.epkg.Z
…
EPKG NUMBER       LABEL               OPERATION              RESULT           
===========       ==============      =================      ==============   
1                 102p_fix            INSTALL                SUCCESS          

Return Status = SUCCESS
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -e /mnt/emgr/ppc/IJ09621s3a.181001.epkg.Z
…
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -e /mnt/emgr/ppc/IJ11545s0a.181127.epkg.Z
…
# umount /alt_inst/mnt
#

Um die gewünschten Platten-Attribute zu setzen und um SDDPCM zu deinstallieren verwenden wir ein firstboot-Skript:

# cat /alt_inst/etc/firstboot
#! /bin/ksh

print "INFO: adjust hdisk attributes"
chdev -Pl hdisk0 -a queue_depth=120

print "INFO: uninstalling SDDPCM"
installp -u devices.sddpcm.$(uname -v)$(uname -r).rte devices.fcp.disk.ibm.mpio.rte

print "INFO: perform reboot"
reboot

# chmod a+x /alt_inst/etc/firstboot
#

Das Skript sollte, falls man es verwendet, auf die eigenen Bedürfnisse angepaßt werden und man sollte dort alle gewünschten Platten-Attribute anpassen (queue_depth, reserve_policy,…). Das Beispiel-Skript hier soll nur andeuten was man alles machen könnte!

Die altinst_rootvg ist nun aktualisiert und auf AIX PCM umgestellt. Wir deaktivieren die altinst_rootvg, damit von dieser gebootet werden kann.

# alt_rootvg_op –S -t
Putting volume group altinst_rootvg to sleep ...
forced unmount of /alt_inst/var/adm/ras/livedump
…
forced unmount of /alt_inst
Fixing LV control blocks...
Fixing file system superblocks...
#

(Hinweis: Bitte nicht die Option “-t” vergessen, diese erzeugt ein neues Boot-Image!)

Bevor wir jedoch nun von der altinst_rootvg booten, stellen wir auf der rootvg den Multipathing Treiber wieder zurück auf SDDPCM!

# manage_disk_drivers -d IBMSVC -o NO_OVERRIDE
********************** ATTENTION *************************
  For the change to take effect the system must be rebooted
#

Abschließend stellen wir noch die Bootliste auf die altinst_rootvg (hdisk3) um:

# bootlist -m normal hdisk3
#

Und als Letztes rebooten wir nun:

# shutdown –r now

SHUTDOWN PROGRAM
Tue Apr 16 19:49:08 CEST 2019

Broadcast message from root@aix01 (tty) at 19:49:08 ...

PLEASE LOG OFF NOW ! ! !
System maintenance in progress.
All processes will be killed now.
…

-------------------------------------------------------------------------------
                                Welcome to AIX.
                   boot image timestamp: 19:45:08 04/16/2019
                 The current time and date: 19:51:11 04/16/2019
        processor count: 2;  memory size: 4096MB;  kernel size: 36847630
       boot device: /vdevice/vfc-client@3000000a/disk@5005076XXXXXXXXX:2
-------------------------------------------------------------------------------
…
Multi-user initialization completed
INFO: adjust hdisk attributes
hdisk0 changed
INFO: uninstalling SDDPCM
…
Installation Summary
--------------------
Name                        Level           Part        Event       Result
-------------------------------------------------------------------------------
devices.sddpcm.71.rte       2.7.1.1         ROOT        DEINSTALL   SUCCESS   
devices.sddpcm.71.rte       2.7.1.1         USR         DEINSTALL   SUCCESS   
devices.fcp.disk.ibm.mpio.r 1.0.0.25        USR         DEINSTALL   SUCCESS   
INFO: perform reboot
Rebooting . . .
…

AIX Version 7
Copyright IBM Corporation, 1982, 2018.
Console login:

(In der Ausgabe kann man die Aktionen des firstboot-Skriptes sehen: Änderung Plattenattribute, Deinstallation SDDPCM und Reboot.)

Nach dem Einloggen überprüfen wir die OS-Version, den verwendeten Multipathing Treiber und ein paar Platten-Attributes:

# oslevel -s
7100-05-03-1846
# lsdev -l hdisk0 -F uniquetype
disk/fcp/mpioosdisk
# lsattr -El hdisk0 -a PCM -F value
PCM/friend/fcpother
# lsattr -El hdisk0 -a queue_depth -F value
120
# genkex|grep pcm
         5ae0000    60000 /usr/lib/drivers/aixdiskpcmke
# lslpp -l|grep sddpcm
#

Damit haben wir die Migration von SDDPCM nach AIX PCM zusammen mit einem OS-Update erfolgreich durchgeführt. Durch Verskripten lässt sich dies noch automatisieren.

Wir haben dies für AIX 7.1 und AIX 7.2 getestet. Ein Test für PowerHA konnten wir bisher aus zeitlichen Gründen noch nicht durchführen.

Wussten Sie, das die HMC Status und Konfigurationsänderungen für etwa 2 Monate speichert?

Status und Konfigurationsänderungen von LPARs und Managed Systems werden auf den HMCs für ca 2 Monate gespeichert. Damit lässt sich nachträglich ohne Probleme herausfinden, wann z.B. ein Managed System heruntergefahren wurde, wann ein Service Prozessor Failover stattfand, oder wann der Speicher einer LPAR erweitert wurde, zumindest wenn das Ereignis nicht länger als 2 Monate zurück liegt.

Die Statusänderungen eines Managed Systems lassen sich mit dem Kommando „lslparutil -r sys -m <managed-system> -s h –startyear 1970 –filter event_types=state_change“ auflisten, oder alternativ mit dem LPAR-Tool Kommando „ms history <managed-system>„.

linux $ ms history ms04
TIME                  PRIMARY_STATE         DETAILED_STATE
03/14/2019 08:45:13   Started               None
03/14/2019 08:36:52   Not Available         Unknown
02/17/2019 01:51:55   Started               None
02/17/2019 01:44:00   Not Available         Unknown
02/12/2019 09:32:57   Started               None
02/12/2019 09:28:02   Started               Service Processor Failover
02/12/2019 09:27:07   Started               None
02/12/2019 09:24:42   Standby               None
02/12/2019 09:21:25   Starting              None
02/12/2019 09:22:59   Stopped               None
02/12/2019 09:21:58   Not Available         Unknown
02/12/2019 09:09:45   Stopped               None
02/12/2019 09:07:53   Stopping              None
linux $

Konfigurationsänderungen (Prozessor, Memory) eines Managed Systems lassen sich mit „lslparutil -r sys -m <managed-system> -s h –startyear 1970 –filter event_types=config_change“ anzeigen, oder alternativ wieder mit dem LPAR-Tool:

linux $ ms history -c ms02
                                PROCUNIS              MEMORY
TIME                  CONFIGURABLE  AVAILABLE  CONFIGURABLE  AVAILABLE  FIRMWARE
04/16/2019 12:15:51      20.0          5.05       1048576       249344     25856
04/11/2019 11:17:39      20.0          5.25       1048576       253696     25600
04/02/2019 13:24:35      20.0          4.85       1048576       249344     25856
03/29/2019 14:29:14      20.0          5.25       1048576       253696     25600
03/15/2019 15:37:08      20.0          4.85       1048576       249344     25856
03/15/2019 11:36:57      20.0          4.95       1048576       249344     25856
...
linux $

Die gleichen Informationen kann man sich auch für LPARs anzeigen lassen.

Die letzten Statusänderungen einer LPAR können mit „lpar history <lpar>“ aufgelistet werden:

linux $ lpar history lpar02
TIME                  PRIMARY_STATE         DETAILED_STATE
04/17/2019 05:42:43   Started               None
04/17/2019 05:41:24   Waiting For Input     Open Firmware
04/16/2019 12:01:54   Started               None
04/16/2019 12:01:29   Stopped               None
02/15/2019 11:30:48   Stopped               None
02/01/2019 12:23:34   Not Available         Unknown
02/01/2019 12:22:50   Relocating            None
...

Dies entspricht dem Kommando „lslparutil -r lpar -m ms03 -s h –startyear 1970 –filter event_types=state_change,lpar_names=lpar02“ auf der HMC Kommandozeile.

Aus der Ausgabe ist ersichtlich, dass die LPAR mit LPM verschoben wurde, gestoppt wurde und neu gestartet wurde und sich im Open Firmware-Modus befunden hat.

Und zuletzt kann man sich natürlich auch die letzten Konfigurationsänderungen einer LPAR anschauen, das Kommando auf der HMC CLI ist „lslparutil -r lpar -m ms03 -s h –startyear 1970 –filter event_types=config_change,lpar_names=lpar02„. Die Ausgabe des LPAR-Tools ist etwas übersichtlicher:

linux $ lpar history -c lpar02
TIME                  PROC_MODE  PROCS  PROCUNITS  SHARING  UNCAP_WEIGHT  PROCPOOL         MEM_MODE  MEM
04/23/2019 18:49:43   shared    1      0.7        uncap    10          DefaultPool      ded       4096
04/23/2019 18:49:17   shared    1      0.7        uncap    5           DefaultPool      ded       4096
04/23/2019 18:48:44   shared    1      0.3        uncap    5           DefaultPool      ded       4096
04/09/2019 08:04:25   shared    1      0.3        uncap    5           DefaultPool      ded       3072
03/14/2019 12:37:32   shared    1      0.1        uncap    5           DefaultPool      ded       3072
02/26/2019 09:34:28   shared    1      0.1        uncap    5           DefaultPool      ded       3072
02/20/2019 06:51:57   shared    1      0.3        uncap    5           DefaultPool      ded       3072
01/31/2019 08:12:58   shared    1      0.3        uncap    5           DefaultPool      ded       3072
..

Anhand der Ausgabe kann man sehen, dass die Anzahl der Processing Units mehrmals geändert wurde, das uncapped_weight geändert wurde und der Speicher erweitert wurde.

Änderungen der letzten beiden Monate stehen also jederzeit abrufbereit zur Verfügung!

Interim Fixes und Alternate Disk Copy

Bei Verwendung des Alternate Disk Copy Verfahrens für AIX Updates kommt es gelegentlich vor das installierte Fixes einen erfolgreichen Update verhindern. Hier bietet es sich an, die installierten Fixes direkt in der altinst_rootvg zu deinstalieren. Dazu kann das emgr Kommando mittels chroot direkt in der altinst_rootvg aufgerufen werden.

Nach dem Erstellen der altinst_rootvg, z.B. mit dem Kommando alt_disk_copy, muß die altinst_rootvg zunächst ersteinmal aktiviert werden:

# alt_rootvg_op -W -d hdisk3
Waking up altinst_rootvg volume group ...
#

Die installierten Fixes kann man sich dann wie folgt auflisten lassen:

# /usr/sbin/chroot /alt_inst /usr/sbin/emgr –l

ID  STATE LABEL      INSTALL TIME      UPDATED BY ABSTRACT
=== ===== ========== ================= ========== ======================================
1    S    102m_ifix  10/14/18 10:48:18            IFIX for Openssl CVE on 1.0.2m       
2    S    IJ03121s0a 10/14/18 10:49:04            IJ03121 for AIX 7.1 TL5 SP00         
3    S    IJ05822s2a 10/14/18 10:49:18            a potential security issue exists    
…

Beim Entfernen von Fixes in der altinst_rootvg ist die Umgebungsvariable INUCLIENTS wichtig. Diese signalisiert dem emgr Kommando keine Dienste zu restarten und keine Geräte dynamisch zu ändern. Ohne das Setzen dieser Variablen schlägt die Deinstallation einiger Fixes in der altinst_rootvg fehl!

# INUCLIENTS=1 /usr/sbin/chroot /alt_inst /usr/sbin/emgr –r -n 3
+-----------------------------------------------------------------------------+
Efix Manager Initialization
+-----------------------------------------------------------------------------+
Initializing log /var/adm/ras/emgr.log ...
Accessing efix metadata ...
Processing efix label "IJ05822s2a" ...
...
Operation Summary
+-----------------------------------------------------------------------------+
Log file is /var/adm/ras/emgr.log

EFIX NUMBER       LABEL               OPERATION              RESULT           
===========       ==============      =================      ==============   
1                 IJ05822s2a          REMOVE                 SUCCESS          

Return Status = SUCCESS
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -n 2
…
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -r -n 1
…

Nun stehen einem OS-Update keine Fixes mehr im Weg!

Nach dem OS-Update können auf ähnliche Weise neue Fixes noch vor dem Reboot in der altinst_rootvg installiert werden. Wir mounten zunächst das Verzeichnis mit den Fixes unter /alt_inst/mnt:

# mount aixnim:/export/nim/lpps/aix710503lpp /alt_inst/mnt
#

Und installieren anschließend die Fixes wieder mit Hilfe von chroot und INUCLIENTS direkt in der altinst_rootvg:

# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -e /mnt/emgr/ppc/102p_fix.181127.epkg.Z
+-----------------------------------------------------------------------------+
Efix Manager Initialization
+-----------------------------------------------------------------------------+
Initializing log /var/adm/ras/emgr.log ...
Efix package file is: /mnt/emgr/ppc/102p_fix.181127.epkg.Z
…
EPKG NUMBER       LABEL               OPERATION              RESULT           
===========       ==============      =================      ==============   
1                 102p_fix            INSTALL                SUCCESS          

Return Status = SUCCESS
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -e /mnt/emgr/ppc/IJ09621s3a.181001.epkg.Z
…
# INUCLIENTS=1 chroot /alt_inst /usr/sbin/emgr -e /mnt/emgr/ppc/IJ11545s0a.181127.epkg.Z
…

Als letztes muß die altinst_rootvg dann noch deaktiviert werden, hierbei sollte man auf jeden Fall noch einmal ein neues Boot-Image in der altinst_rootvg erzeugen, ansonsten bleibt das System beim Booten der altinst_rootvg hängen!

# alt_rootvg_op –S -t
Putting volume group altinst_rootvg to sleep ...
forced unmount of /alt_inst/var/adm/ras/livedump
…
forced unmount of /alt_inst
Fixing LV control blocks...
Fixing file system superblocks...
#

(Hinweis: Die Option ‚-t‚ erzwingt das Erzeugen eines neuen Boot-Images!)

Nun kann wie gewohnt die Boot-Liste umgestellt werden und das System nach dem Update rebootet werden.

 

PowerVM: Kennen Sie das Profil „last*valid*configuration“?

Vielleicht hat sich der Ein oder Andere schon mal gefragt, wie und wo die aktuelle Konfiguration einer LPAR abgespeichert ist. Sind aktuelle Konfiguration und Profil nicht miteinander synchronisiert, ergeben sich schnell Unterschiede. Wird eine LPAR heruntergefahren und deaktiviert, bleibt die letzte aktuelle Konfiguration erhalten. Beim Aktivieren der LPAR ist diese Konfiguration neben den Profilen der LPAR als „current configuration“ im GUI verfügbar. Wählt man diese aus, so besitzt die LPAR nach dem Aktivieren die gleiche Konfiguration wie vor dem Deaktivieren. Bei einer neu angelegten LPAR ist diese Auswahl hingegen beim Aktivieren nicht verfügbar. Der Unterschied äußert sich auch auf der HMC-Kommandozeile: die schon mal aktivierte LPAR kann ohne Angabe eines Profils aktiviert werden, die neu angelegte LPAR kann nur durch Angabe eines Profils aktiviert werden. Das schauen wir uns nun einmal genauer an.

(Kurzer Hinweis: Die Kommandos auf der HMC-Kommandozeile wurden direkt auf der HMC hmc01 ausgeführt.Bei den Beispiel-Ausgaben mit dem LPAR-Tool wurden die Kommandos von einem Linux-Sprungserver aus gestartet. Alle Kommandos sind immer mit beiden Varianten gezeigt!)

Wir haben hierzu die LPAR aix01 mit dem Profil „standard“ aktiviert und gebootet. Dynamische Änderungen haben wir noch keine vorgenommen. Wir schauen kurz den Status der LPAR an und überprüfen ob eine RMC-Verbindung zur HMC besteht:

hscroot@hmc01:~> lssyscfg -m p710 -r lpar --filter lpar_names=aix01 --header -F name lpar_env state curr_profile rmc_state os_version
name lpar_env state curr_profile rmc_state os_version
aix01 aixlinux Running standard active "AIX 7.1 7100-04-00-0000"
hscroot@hmc01:~>
linux $ lpar status aix01
NAME  ID      TYPE   STATUS  PROFILE    RMC   PROCS  PROCUNITS MEMORY  OS
aix01  5  aixlinux  Running  standard  active   1       -      3072    AIX 7.1 7100-04-00-0000
linux $

Um die Auswirkung einer dynamischen Änderung zu sehen, schauen wir uns den Ist-Zustand und das Profil „standard“ noch an:

hscroot@hmc01:~> lshwres -m p710 -r mem --level lpar --filter lpar_names=aix01 -F curr_mem
3072
hscroot@hmc01:~> lssyscfg -m p710 -r prof --filter profile_names=standard,lpar_names=aix01 -F desired_mem
3072
hscroot@hmc01:~>
linux $ lpar mem aix01
      MEMORY            MEMORY           HUGEPAGES
NAME   MODE  AME   MIN   CURR   MAX   MIN  CURR  MAX
aix01  ded    -   2048   3072  8192    0     0    0
linux $ lpar -p standard mem aix01
      MEMORY            MEMORY           HUGEPAGES
NAME   MODE  AME   MIN   CURR   MAX   MIN  CURR  MAX
aix01  ded    -   2048   3072  8192    0     0    0
linux $

Die LPAR hat aktuell 3072 MB Hauptspeicher, die auch im Profil „standard“ hinterlegt sind.

Nun fügen wir 1024 MB Hauptspeicher dynamisch (DLPAR) hinzu:

hscroot@hmc01:~> chhwres -m p710 -r mem -o a -p aix01 -q 1024
hscroot@hmc01:~>
linux $ lpar -d addmem aix01 1024
linux $

Jetzt schauen wir uns die resultierenden Speicher Resourcen der LPAR an:

hscroot@hmc01:~> lshwres -m p710 -r mem --level lpar --filter lpar_names=aix01 -F curr_mem
4096
hscroot@hmc01:~>
linux $ lpar mem aix01
     MEMORY            MEMORY          HUGEPAGES
NAME  MODE  AME   MIN   CURR   MAX   MIN  CURR  MAX
aix01  ded   -   2048   4096  8192    0     0    0
linux $

Die LPAR hat wie erwartet nun 4096 MB RAM. Doch wie sieht das Profile „standard“ aus?

hscroot@hmc01:~> lssyscfg -m p710 -r prof --filter profile_names=standard,lpar_names=aix01 -F desired_mem
3072
hscroot@hmc01:~>
linux $ lpar -p standard mem aix01
     MEMORY            MEMORY          HUGEPAGES
NAME  MODE  AME   MIN   CURR   MAX   MIN  CURR  MAX
aix01  ded   -   2048   3072  8192    0     0    0
linux $

Das Profile hat sich nicht geändert, beim Aktivieren mit diesem Profil würde das System mit 3072 MB gestartet werden.

Die aktuelle Konfiguration wird immer im speziellen Profil „last*valid*configuration“ gespeichert:

hscroot@hmc01:~> lssyscfg -m p710 -r prof --filter profile_names=last*valid*configuration,lpar_names=aix01 -F desired_mem
4096
hscroot@hmc01:~>
linux $ lpar -p last*valid*configuration mem aix01
     MEMORY            MEMORY          HUGEPAGES
NAME  MODE  AME   MIN   CURR   MAX   MIN  CURR  MAX
aix01  ded   -   2048   4096  8192    0     0    0
linux $

Hier ist der Wert von 4096 MB zu finden, übereinstimmend mit dem aktuell verfügbaren Speicher in der LPAR.

Jede dynamische Aenderung an einer LPAR wird zum Einen per DLPAR-Operation auf der LPAR umgesetzt und zum Anderen in diesem speziellen Profil hinterlegt! Wird ein Profil manuell oder automatisch synchronisiert, dann wird letztlich dieses spezielle Profil mit dem gewünschten Profil synchronisiert.

Die Existenz und Handhabung des speziellen Profils „last*valid*configuration“ macht auch einige Möglichkeiten bei LPM leichter verständlich. Damit werden wir uns in einem späteren Blog-Beitrag noch einmal beschäftigen.

Wir wollen Feedback!

Wir wollen Feedback! Das neue PowerCampus „LPAR tool“ steht zum Download bereit! In weiten Teilen überarbeitet und in C++ geschrieben. Es unterstützt Output in verschiedenen Formaten: JSON + YAML!

Die ersten 100 Feedbacks erhalten beim Kauf zwei Lizenzen (2 LPARS) gratis! Für immer!

Also, downloaden installieren und Feedback geben, einfach per Mail an info@powercampus.de!

Die integrierte Test-Lizenz unterstützt ohne weitere Registrierung eine HMC und zwei komplette Managed Systems! Für eine erweiterte Trialversion für 4 HMC’s und unbegrenzte MS einfach eine Mail an info@powercampus.de senden.

Download „LPAR tool“: https://powercampus.de/en/download-2/