LPAR-Tool: welche LPARs haben keine RMC-Verbindung

Status und Konfiguration von LPARs sind regelmäßig benötigte Informationen bei der Administration von LPARs. Mit dem LPAR-Tool lassen sich Informationen wie Status, RMC-Status, Anzahl Cores, Größe RAM, OS-Version und andere Daten, sehr leicht und schnell ermitteln, auch bei hunderten oder tausenden von LPARs. Welche LPARs keine RMC-Verbindung haben, wird in einem der Beispiele gezeigt.

Alle folgenden Beispiele wurden auf einer Umgebung mit 10 HMCs, 50 Managed Systems und etwas über 500 LPARs durchgeführt. Zur Orientierung wie lange das LPAR-Tool benötigt, wurden jeweils die Laufzeiten der Kommandos mit time gemessen und angegeben.

Die Namen der LPARs wurden in den gezeigten Ausgaben manuell abgeändert und durch generische Namen lparXX und aixYY ersetzt.

Zunächst einmal der Status einer einzelnen LPAR:

$ time lpar status aix01
NAME   LPAR_ID  LPAR_ENV   STATE     PROFILE    SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
aix01  27       aixlinux   Running   standard   0     active    1      0.1         8192    AIX 7.1 7100-04-02-1614

real    0m0.210s
user    0m0.011s
sys     0m0.013s
$

Natürlich kann man auch mehrere LPARs angeben. Möchte man den Status aller LPARs (in unserem Falle etwas über 500 LPARs) wissen, läßt man einfach das Argument weg:

$ time lpar status
NAME    LPAR_ID  LPAR_ENV   STATE     PROFILE      SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
aix01   27       aixlinux   Running   standard     0     active    1      0.1         8192    AIX 7.1 7100-04-02-1614
aix02   1        aixlinux   Running   standard     -     -         1      -           8320    Unknown
...
lpar01  6        aixlinux   Running   standard     0     active    1      0.4         20480   AIX 7.1 7100-04-05-1720

real	0m18.933s
user	0m3.819s
sys	0m3.789s
$

Hierbei werden im Hintergrund vom LPAR-Tool mehr als 150 Kommandos (lshwres und lssyscfg) auf den HMCs abgesetzt!

Die Ausgabe soll jetzt eingeschränkt werden auf LPARs die gerade aktiv sind (state=Running). Hierzu gibt es die Option „-s„, mit der Kriterien für Attribute angegeben werden können, die erfüllt sein müssen. Nur LPARs die diese Kriterien erfüllen, werden ausgegeben:

$ time lpar status -s state=Running
NAME     LPAR_ID  LPAR_ENV   STATE    PROFILE    SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
aix01    27       aixlinux   Running  standard   0     active    1      0.1         8192    AIX 7.1 7100-04-02-1614
aix02    1        aixlinux   Running  standard   -     -         1      -           8320    Unknown
...
lpar01   6        aixlinux   Running  standard   0     active    1      0.4         20480   AIX 7.1 7100-04-05-1720

real	0m17.998s
user	0m3.692s
sys	0m3.647s
$

Wir wollen jetzt wissen, auf welchen dieser LPARs RMC nicht funktioniert/nicht aktiv ist. Die Option „-s“ erlaubt es beliebig viele Kriterien zu kombinieren. Es müssen dann alle angegebenen Kriterien erfüllt sein (logischen UND). Der RMC-Zustand findet sich im Attribut rmc_state:

$ time lpar status -s state=Running,rmc_state!=active
NAME     LPAR_ID  LPAR_ENV   STATE    PROFILE    SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
aix02    1        aixlinux   Running  standard   -     -         1      -           8320    Unknown
aix03    2        aixlinux   Running  standard   -     -         1      -           8320    Unknown
...
lpar07   4        aixlinux   Running  standard   0     none      1      1.0         4352    Unknown

real	0m19.057s
user	0m3.550s
sys	0m3.512s
$

Als weiteres Beispiel wollen wir wissen auf welchen LPARs AIX 7.1 TL5 installiert ist. Im Attribut os_version findet sich die OS-Version. Mit dem ‚~‚ Operator kann gegen einen regulären Ausdruck verglichen werden (ähnlich wie beim Kommando grep). Wir verwenden den regulären Ausdruck 7100-05:

$ time lpar status -s os_version~7100-05
NAME     LPAR_ID  LPAR_ENV  STATE    PROFILE    SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
aix14    14       aixlinux  Running  standard   0     active    2      0.2         16384   AIX 7.1 7100-05-02-1810
aix16    24       aixlinux  Running  standard   0     active    2      0.2         16384   AIX 7.1 7100-05-03-1846
...
lpar10   10       aixlinux  Running  standard   0     active    3      0.3         32768   AIX 7.1 7100-05-02-1810

real	0m18.212s
user	0m3.726s
sys	0m3.676s
$

Bisher haben wir immer das Default Ausgabeformat verwendet. Jetzt würden wir gerne alle Systeme auflisten, die noch unter AIX 6.1 laufen. Aber dieses Mal soll nur der LPAR-Name und die OS-Version ausgegeben werden. Hierfür gibt es die Option „-F„, mit der die gewünschten Ausgabe-Felder angegeben werden können:

$ time lpar status -s os_version~6100 -F name:os_version
aix39:AIX 6.1 6100-07-04-1216
aix46:AIX 6.1 6100-07-04-1216
...
lpar35:AIX 6.1 6100-09-05-1524

real	0m18.041s
user	0m3.619s
sys	0m3.699s
$

Wer lieber JSON-Output hat, kann dies ganz einfach mit der Option „-j“ erreichen, hier das gleiche Beispiel mit JSON-Ausgabe:

$ time lpar status -s os_version~6100 -F name:os_version -j
{
	"name": "aix39",
	"os_version": "AIX 6.1 6100-07-04-1216"
}
{
	"name": "aix46",
	"os_version": "AIX 6.1 6100-07-04-1216"
}
...
{
	"name": "lpar35",
	"os_version": "AIX 6.1 6100-09-05-1524"
}

real	0m21.247s
user	0m3.670s
sys	0m3.720s
$

Natürlich kann man nicht alle Attribut-Namen auswendig wissen! Das ist aber auch gar nicht notwendig, da man sich alle Attribut-Namen einfach anzeigen lassen kann. Man verwendet die Option „-f“ (Stanza-Format) und gibt eine beliebige LPAR an:

$ lpar status -f lpar19
lpar19:
	curr_lpar_proc_compat_mode = POWER7
	curr_mem = 8192
	curr_proc_mode = shared
	curr_proc_units = 0.3
	curr_procs = 2
	name = lpar19
	os_version = AIX 6.1 6100-09-05-1524
...
$

Über die Optionen „-h“ und „-m“ können die LPARs noch in Abhängigkeit von zugehöriger HMC und/oder Managed System ausgewählt werden.

Status aller LPARs mit zugehöriger HMC hmc01:

$ lpar -h hmc01 status

Status aller LPARs deren zugehörige HMC den Typ 7042-CR6 hat:

$ lpar -h 7042-CR6 status

Status aller LPARs deren zugehörige HMC den Typ 7042-CR6 hat und deren Name mit lpar beginnt:

$ lpar -h 7042-CR6 status lpar*

Status aller LPARs auf dem Managed System ms13:

$ lpar -m ms13 status

Status aller LPARs deren Managed System eine S922 ist:

$ lpar -m 9009-22A status

Die vorgestellten Auswahl- und Ausgabemöglichkeiten gelten für alle Ausgabe-Kommandos des LPAR-Tools (außer dem Kommando vios).

Das LPAR-Tool kann in unserem Download-Bereich heruntergeladen werden: https://powercampus.de/download

Das LPAR-Tool beinhaltet eine Test-Lizenz mit einer Gültigkeit bis zum 31. Oktober.

LPAR-Tool in Aktion: Examples

Das LPAR-Tool kann HMCs, Managed Systems, LPARs und Virtual-I/O-Server über die Kommandozeile administrieren. Die aktuelle Version des LPAR-Tools (aktuell: 1.4.0.2), kann von unserer Download-Seite https://powercampus.de/download heruntergeladen werden. Eine Test-Lizenz, gültig bis 31. Oktober, ist enthalten. In diesem Beitrag sollen einige einfache, aber nützliche Anwendungen des LPAR-Tools gezeigt werden.

Eine häufig auftretende Frage in größeren Umgebungen (mehrere HMCs, viele Managed Systems) ist: wo befindet sich eine bestimmte LPAR. Mit dem LPAR-Tool kann diese Frage leicht beantwortet werden, hierfür gibt es das Kommando „lpar show„:

$ lpar show lpar02
NAME    ID  SERIAL     LPAR_ENV  MS    HMCS
lpar02  39  123456789  aixlinux  ms21  hmc01,hmc02
$

Neben dem Namen, der LPAR-ID und der Seriennummer wird auch das Managed System, hier ms21, und die zugehörigen HMCs, hier hmc01 und hmc02, gezeigt. Es können auch mehrere LPARs und/oder Wildcards angegeben werden:

$ lpar show lpar02 lpar01
...
$ lpar show lpar*
...
$

Wird kein Argument angegeben, werden alle LPARs aufgelistet.

 

Eine weitere Frage, die sich häufig stellt, ist der Status der LPAR oder LPARs. Auch dies läßt sich leicht beantworten, dieses Mal mit dem Kommando „lpar status„:

$ lpar status lpar02
NAME    LPAR_ID  LPAR_ENV  STATE    PROFILE   SYNC  RMC     PROCS  PROC_UNITS  MEM   OS_VERSION
lpar02  39       aixlinux  Running  standard  0     active  1      0.7         7168  AIX 7.2 7200-03-02-1846
$

Die LPAR lpar02 ist im Zustand Running, das verwendete Profil heißt standard, die RMC-Verbindung ist active und die LPAR läuft unter AIX 7.2 (TL3 SP2). Die LPAR besitzt 1 Prozessor Core, mit 0.7 Processor Units und 7 GB RAM. Die Spalte SYNC gibt an ob die aktuelle Konfiguration mit dem Profil synchronisiert wird (Attribut sync_curr_profile).

Natürlich lassen sich auch hier mehrere LPARs oder auch alle LPARs angeben.

Möchte man sehen, was das LPAR-Tool im Hintergrund macht, kann man bei den meisten Kommandos die Option „-v“ für verbose-only angeben. Es werden dann die HMC-Kommandos aufgelistet, es werden aber keine Änderungen auf der HMC durchgeführt. Hier die HMC-Kommandos die für die Status-Ausgabe abgesetzt werden:

$ lpar status -v lpar02
hmc01: lssyscfg -r lpar -m ms21
hmc01: lshwres -r mem -m ms21 --level lpar
hmc01: lshwres -r proc -m ms21 --level lpar
$

 

Als nächstes soll das Hinzufügen von zusätzlichem RAM gezeigt werden. Wir starten mit dem Status der LPAR:

$ lpar status lpar02
NAME    LPAR_ID  LPAR_ENV  STATE    PROFILE   SYNC  RMC     PROCS  PROC_UNITS  MEM   OS_VERSION
lpar02  39       aixlinux  Running  standard  0     active  1      0.7         7168  AIX 7.2 7200-03-02-1846
$

Die LPAR läuft und RMC ist aktiv, eine DLPAR-Operation sollte also möglich sein. Wir schauen zunächst nach, ob die maximal mögliche Speichergröße schon verwendet wird:

$ lpar lsmem lpar02
            MEMORY         MEMORY         HUGE_PAGES 
LPAR_NAME  MODE  AME  MIN   CURR  MAX   MIN  CURR  MAX
lpar02     ded   0.0  2048  7168  8192  0    0     0
$

Aktuell verwendet die LPAR 7 GB, maximal möglich sind 8 GB. Eine Erweiterung um 1 GB (1024 MB) sollte also möglich sein. Wir führen die Erweiterung durch, das notwendig Kommando ist „lpar addmem„:

$ lpar addmem lpar02 1024
$

Wir überprüfen den Erfolg, indem wir das Kommando „lpar lsmem“ noch einmal starten:

$ lpar lsmem lpar02
           MEMORY         MEMORY         HUGE_PAGES 
LPAR_NAME  MODE  AME  MIN   CURR  MAX   MIN  CURR  MAX
lpar02     ded   0.0  2048  8192  8192  0    0     0
$

(Übrigens: falls die aktuelle Konfiguration nicht mit dem aktuellen Profil synchronisiert wird, Attribut sync_curr_profile, dann aktualisiert das LPAR-Tool auch das Profil!)

 

Virtuelle Adapter lassen sich mittels „lpar lsvslot“ auflisten:

$ lpar lsvslot lpar02
SLOT  REQ  ADAPTER_TYPE   STATE  DATA
0     Yes  serial/server  1      remote: (any)/any connect_status=unavailable hmc=1
1     Yes  serial/server  1      remote: (any)/any connect_status=unavailable hmc=1
2     No   eth            1      PVID=123 VLANS= ETHERNET0 XXXXXXXXXXXX
6     No   vnic           -      PVID=1234 VLANS=none XXXXXXXXXXXX failover sriov/ms21-vio1/1/3/0/2700c003/2.0/2.0/20/100.0/100.0,sriov/ms21-vio2/2/1/0/27004004/2.0/2.0/10/100.0/100.0
10    No   fc/client      1      remote: ms21-vio1(1)/47 c050760XXXXX0016,c050760XXXXX0017
20    No   fc/client      1      remote: ms21-vio2(2)/25 c050760XXXXX0018,c050760XXXXX0019
21    No   scsi/client    1      remote: ms21-vio2(2)/20
$

Das Beispiel zeigt neben virtuellen FC- und SCSI-Adaptern auch einen vNIC Adapter in Slot 6.

 

Als letztes zeigen wir noch das Starten einer Konsole für eine LPAR:

$ lpar console lpar02

Open in progress 

 Open Completed.

…

AIX Version 7

Copyright IBM Corporation, 1982, 2018.

Console login:

…

Die Konsole kann mit „~.“ beendet werden.

 

Natürlich kann das LPAR-Tool noch viel mehr.

Fortsetzung folgt.

 

LPAR-Tool 1.4.0.1 verfügbar (inklusive Testlizenz)!

Im Download-Bereich steht ab sofort die Version 1.4.0.1 unseres LPAR-Tools mit einer gültigen Test-Lizenz bis 31.10.2019 zum Download bereit. Die Lizenz ist in den Binaries direkt enthalten, es muss also kein Lizenz-Key eingetragen werden. Die enthaltene Test-Lizenz erlaubt die Benutzung des LPAR-Tools für bis zu 10 HMCs, 100 Managed Systems und 1000 LPARs.

LPAR-Tool mit Test-Lizenz bis 15.09.2019

Im Download-Bereich steht ab sofort die Version 1.3.0.2 unseres LPAR-Tools mit einer gültigen Test-Lizenz bis 15.09.2019 zum Download bereit. Die Lizenz ist in den Binaries direkt enthalten, es muss also kein Lizenz-Key eingetragen werden. Die enthaltene Test-Lizenz erlaubt die Benutzung des LPAR-Tools für bis zu 10 HMCs, 100 Managed Systems und 1000 LPARs.

Resourcen von nicht aktivierten LPARs und Memory Affinity

Wird eine LPAR heruntergefahren, werden nicht automatisch die Resourcen, wie Prozessoren, Speicher und I/O-Slots, der LPAR freigegeben. Die Resourcen bleiben weiterhin der LPAR zugeordnet und werden dann beim nächsten Aktivieren (mit der aktuellen Konfiguration) wiederverwendet. Im ersten Teil des Beitrags Resourcen von nicht aktivierten LPARs hatten wir uns dies schon angeschaut.

(Hinweis: In den Beispiel-Ausgaben benutzen wir die Version 1.4 des LPAR-Tools, zeigen aber in allen Fällen die unterliegenden Kommandos auf der HMC Kommandozeile. Man kann also alles auch ohne die Verwendung des LPAR-Tools ausprobieren.)

Die Beispiel LPAR lpar1 wurde heruntergefahren, belegt aber aktuell immer noch 100 GB Speicher:

linux $ lpar status lpar1
NAME   LPAR_ID  LPAR_ENV  STATE          PROFILE   SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
lpar1  39       aixlinux  Not Activated  standard  0     inactive  1      0.2         102400  Unknown
linux $

Auf der zugehörigen HMC hmc01 wurden die folgenden Kommandos für die Ausgabe oben ausgeführt:

hmc01: lssyscfg -r lpar -m ms09 --filter lpar_names=lpar1
hmc01: lshwres -r mem -m ms09 --level lpar --filter lpar_names=lpar1
hmc01: lshwres -r proc -m ms09 --level lpar --filter lpar_names=lpar1

Wie die Ausgabe zeigt, hat die LPAR lpar1 noch ihre Resourcen (Prozessoren, Memory, I/O-Adapter) alloziert.

Um zu verstehen warum beim Deaktivieren einer LPAR die Resourcen nicht frei gegeben werden, muss man sich den „Memory Affinity Score“ anschauen:

linux $ lpar lsmemopt lpar1
             LPAR_SCORE  
LPAR_NAME  CURR  PREDICTED
lpar1      100   0
linux $

HMC Kommandozeile:

hmc01: lsmemopt -m ms09 -r lpar -o currscore –filter lpar_names=lpar1

Der Memory Affinity Score beschreibt wie nahe sich Prozessoren und Memory sind, je näher, desto besser ist der Durchsatz auf den Speicher.  Das Kommando oben gibt mit einem Wert zwischen 1 und 100 an, wie groß die Affinität zwischen Prozessoren und LPARs ist. Unsere LPAR lpar1 hat aktuell einen Wert von 100, das heißt die bestmögliche Affinität von Speicher und Prozessoren. Würden beim Deaktivieren einer LPAR die Resourcen freigegeben, dann würde die LPAR erst einmal diesen Memory Affinity Score verlieren. Beim nächsten Aktivieren der LPAR hängt es dann von dem dann verfügbaren Speicher und Prozessoren ab wie gut die Memory Affinität dann ist. Wir geben einmal die Resourcen frei:

linux $ lpar -d rmprocs lpar1 1
linux $

HMC Kommandozeile:

hmc01: chhwres -m ms09 -r proc  -o r -p lpar1 --procs 1

Es wird nun kein Score mehr angegeben, da der LPAR keine Resourcen mehr zugeordnet sind:

linux $ lpar lsmemopt lpar1
             LPAR_SCORE  
LPAR_NAME  CURR  PREDICTED
lpar1      none  none
linux $

HMC Kommandozeile:

hmc01: lsmemopt -m ms09 -r lpar -o currscore –filter lpar_names=lpar1

Nun lassen wir die Resourcen neu zuweisen und Schauen welchen Einfluß dies auf die Memory Affinität hat:

linux $ lpar applyprof lpar1 standard
linux $

HMC Kommandozeile:

hmc01: chsyscfg -r lpar -m ms09 -o apply -p lpar1 -n standard

Wir ermitteln erneut den Memory Affinity Score:

linux $ lpar lsmemopt lpar1
             LPAR_SCORE  
LPAR_NAME  CURR  PREDICTED
lpar1      53    0
linux $

HMC Kommandozeile:

hmc01: lsmemopt -m ms09 -r lpar -o currscore –filter lpar_names=lpar1

Der Score ist jetzt nur noch bei 53, die Performance der LPAR ist damit schlechter geworden. Ob und wie stark sich dies dann auch bemerkbar macht, hängt dann letztlich von den Applikationen auf der LPAR ab.

Das die Resourcen beim Deaktivieren einer LPAR nicht freigegeben werden, garantiert also beim nächsten Aktivieren (mit der aktuellen Konfiguration) das die Memory Affinität gleich bleibt und damit die Performance die Gleiche sein sollte.

Gibt man die Resourcen einer LPAR frei (manuell oder automatisch), dann muß man sich im Klaren sein das dies Auswirkungen auf die LPAR hat, wenn sie später wieder aktiviert wird, da dann die Resourcen neu zugewiesen werden und sich ein schlechterer (möglicherweise aber auch ein besserer) Memory Affinity Score ergeben kann.

Umgekehrt kann man vor dem Aktivieren einer neuen LPAR aber auch durch Freigeben von Resourcen dafür sorgen das es eine gute Chance für einen hohen Memory Affinity Score für die neue LPAR gibt.

(Hinweis: die Resource Verteilung kann zur Laufzeit mit Hilfe des Dynamic Plattform Optimizers DPO geändert und verbessert werden. DPO wird ab POWER8 unterstützt.)

 

Resourcen von nicht aktivierten LPARs

Wird eine LPAR heruntergefahren, werden Resourcen, wie Prozessoren, Speicher und I/O-Slots, der LPAR nicht automatisch freigegeben. Die Resourcen bleiben weiterhin der LPAR zugeordnet und werden dann beim nächsten Aktivieren (mit der aktuellen Konfiguration) wiederverwendet.

Im Artikel soll gezeigt werden wie das automatische Freigeben der Resourcen erfolgt und falls gewünscht, wie man manuell Resourcen einer nicht aktivierten LPAR freigeben kann.

(Hinweis: In den Beispiel-Ausgaben benutzen wir die Version 1.4 des LPAR-Tools, zeigen aber in allen Fällen die unterliegenden Kommandos auf der HMC Kommandozeile. Man kann also alles auch ohne die Verwendung des LPAR-Tools ausprobieren.)

Die Beispiel LPAR lpar1 wurde heruntergefahren, belegt aber aktuell immer noch 100 GB Speicher:

linux $ lpar status lpar1
NAME   LPAR_ID  LPAR_ENV  STATE          PROFILE   SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
lpar1  39       aixlinux  Not Activated  standard  0     inactive  1      0.2         102400  Unknown
linux $

Auf der zugehörigen HMC hmc01 wurden die folgenden Kommandos für die Ausgabe oben ausgeführt:

hmc01: lssyscfg -r lpar -m ms09 --filter lpar_names=lpar1
hmc01: lshwres -r mem -m ms09 --level lpar --filter lpar_names=lpar1
hmc01: lshwres -r proc -m ms09 --level lpar --filter lpar_names=lpar1

Das Attribut resource_config einer LPAR gibt an, ob die LPAR aktuell Resourcen alloziert hat (resource_config=1) oder nicht (resource_config=0):

linux $ lpar status -F resource_config lpar1
1
linux $

Entsprechend auf der HMC Kommandozeile:

hmc01: lssyscfg -r lpar -m ms09 --filter lpar_names=lpar1 –F resource_config

Die von einer nicht aktivierten LPAR allozierten Resourcen können auf 2 verschiedenen Wegen freigegeben werden:

  1. Automatisch: Die belegten Resourcen werden von einer anderen LPAR benötigt, z.B. weil Speicher dynamisch erweitert wird oder eine LPAR aktiviert wird, die nicht ausreichend Resourcen besitzt. In diesem Fall werden einer deaktivierten LPAR automatisch Resourcen weggenommen. Wir zeigen dies weiter unten anhand eines Beispiels.
  2. Manuell: Die allozierten Resourcen werden vom Administrator explizit frei gegeben. Auch dies zeigen wir nachfolgend in einem Beispiel.

Zunächst zeigen wir ein Beispiel bei dem einer nicht aktivierten LPAR automatisch Resourcen weggenommen werden.

Das Managed System ms09 besitzt aktuell noch ca 36 GB freien Speicher:

linux $ ms lsmem ms09
NAME  INSTALLED  FIRMWARE  CONFIGURABLE  AVAIL  MEM_REGION_SIZE
ms09  786432     33792     786432        36352  256
linux $

HMC-Kommandozeile:

hmc01: lshwres -r mem -m ms09 --level sys

Wir starten eine LPAR (lpar2) die mit 100 GB RAM konfiguriert wurde. Das Managed System besitzt nur 36 GB RAM und ist daher gezwungen inaktiven LPARs Resourcen wegzunehmen um die benötigten 100 GB zur Verfügung stellen zu können. Wir starten lpar2 mit dem Profil standard und schauen uns die Speicherverhältnisse an:

linux $ lpar activate -b sms -p standard lpar2
linux $

HMC-Kommandozeile:

hmc01: chsysstate -m ms09 -r lpar -o on -n lpar2 -b sms -f standard

Übersicht über die Speicherverhältnisse von lpar1 und lpar2:

linux $ lpar status lpar\*
NAME   LPAR_ID  LPAR_ENV  STATE          PROFILE   SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
lpar1  4        aixlinux  Not Activated  standard  0     inactive  1      0.2         60160   Unknown
lpar2  8        aixlinux  Open Firmware  standard  0     inactive  1      0.2         102400  Unknown
linux $ ms lsmem ms09
NAME  INSTALLED  FIRMWARE  CONFIGURABLE  AVAIL  MEM_REGION_SIZE
ms09  786432     35584     786432        0      256
linux $

HMC-Kommandozeile:

hmc01: lssyscfg -r lpar -m ms09
hmc01: lshwres -r mem -m ms09 --level lpar
hmc01: lshwres -r proc -m ms09 --level lpar
hmc01: lshwres -r mem -m ms09 --level sys

Die LPAR lpar2 hat 100 GB RAM, das Managed System hat keinen freien Speicher mehr und der LPAR lpar1 zugewiesene Speicher wurde auf ca 60 GB reduziert. Allozierte Resourcen von nicht aktivierten LPARs werden bei Bedarf also automatisch weggenommen und anderen LPARs zugewiesen.

Man kann aber auch die Resourcen manuell freigeben. Dies soll hier auch noch kurz gezeigt werden. Wir reduzieren den Speicher von LPAR lpar1 um 20 GB:

linux $ lpar -d rmmem lpar1 20480
linux $

HMC Kommandozeile:

hmc01: chhwres -m ms09 -r mem  -o r -p lpar1 -q 20480

Wie angegeben wurde der zugewiesene Speicher um 20 GB reduziert:

linux $ lpar status lpar\*
NAME   LPAR_ID  LPAR_ENV  STATE          PROFILE   SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
lpar1  4        aixlinux  Not Activated  standard  0     inactive  1      0.2         39680   Unknown
lpar2  8        aixlinux  Open Firmware  standard  0     inactive  1      0.2         102400  Unknown
linux $ ms lsmem ms09
NAME  INSTALLED  FIRMWARE  CONFIGURABLE  AVAIL  MEM_REGION_SIZE
ms09  786432     35584     786432        20480  256
linux $

HMC-Kommandozeile:

hmc01: lssyscfg -r lpar -m ms09
hmc01: lshwres -r mem -m ms09 --level lpar
hmc01: lshwres -r proc -m ms09 --level lpar
hmc01: lshwres -r mem -m ms09 --level sys

Die 20 GB stehen dem Managed System sofort wieder als freier Speicher zur Verfügung. Nimmt man den kompletten Speicher oder alle Prozessoren (oder Prozessor-Units) weg, dann werden alle Resourcen einer inaktiven LPAR wieder freigegeben:

linux $ lpar -d rmmem lpar1 39680
linux $

HMC Kommandozeile:

hmc01: chhwres -m ms09 -r mem  -o r -p lpar1 -q 39680

Hier die resultierenden Speicherverhältnisse:

linux $ lpar status lpar\*
NAME   LPAR_ID  LPAR_ENV  STATE          PROFILE   SYNC  RMC       PROCS  PROC_UNITS  MEM     OS_VERSION
lpar1  4        aixlinux  Not Activated  standard  0     inactive  0      0.0         0       Unknown
lpar2  8        aixlinux  Open Firmware  standard  0     inactive  1      0.2         102400  Unknown
linux $ ms lsmem ms09
NAME        INSTALLED  FIRMWARE  CONFIGURABLE  AVAIL  MEM_REGION_SIZE
ms09  786432     31232     786432        64512  256
linux $

HMC Kommandozeile:

hmc01: lssyscfg -r lpar -m ms09
hmc01: lshwres -r mem -m ms09 --level lpar
hmc01: lshwres -r proc -m ms09 --level lpar
hmc01: lshwres -r mem -m ms09 --level sys

Die LPAR lpar1 hat nun 0 Prozessoren, 0.0 Prozessor-Units und 0 MB Speicher! Außerdem hat nun das Attribut resource_config den Wert 0 und gibt damit an das die LPAR keine konfigurierten Resourcen mehr besitzt!

linux $ lpar status -F resource_config lpar1
0
linux $

HMC Kommandozeile:

hmc01: lssyscfg -r lpar -m ms09 --filter lpar_names=lpar1 –F resource_config

Es stellt sich abschließend die Frage warum man unter Umständen Resourcen manuell freigeben sollte, wenn diese vom Managed System bei Bedarf doch automatisch freigegeben werden?

Dieser Frage gehen wir in einem zweiten Artikel nach.

Zugriff auf das Ablaufdatum des Update Access Keys von AIX aus

Im Zuge der Einführung von POWER8 Systemen hat IBM auch den „Update Access Key“ eingeführt, der für das Durchführen von Firmware Updates des Managed Systems notwendig ist. Neu ausgelieferte System haben standardmäßig einen Update Access Key der in der Regel nach 3 Jahren abläuft. Danach kann der Update Access Key bei bestehen eines Wartungsvertrages jeweils um ein halbes Jahr verlängert werden (https://www.ibm.com/servers/eserver/ess/index.wss).

Wann der aktuelle Update Access Key abläuft lässt sich natürlich leicht über die HMC herausfinden, GUI oder CLI. Man kann das Ablaufdatum aber auch über das Kommando lscfg von AIX aus anzeigen:

Im Falle von AIX 7.1 sieht dies so aus:

$ lscfg -vpl sysplanar0 | grep -p "System Firmware"
      System Firmware:
...
        Microcode Image.............SV860_138 SV860_103 SV860_138
        Microcode Level.............FW860.42 FW860.30 FW860.42
        Microcode Build Date........20180101 20170628 20180101
        Microcode Entitlement Date..20190825
        Hardware Location Code......U8284.22A.XXXXXXX-Y1
      Physical Location: U8284.22A.XXXXXXX-Y1

Im Falle von AIX 7.2 ist die Ausgabe geringfügig anders:

$ lscfg -vpl sysplanar0 |grep -p "System Firmware"
      System Firmware:
...
        Microcode Image.............SV860_138 SV860_103 SV860_138
        Microcode Level.............FW860.42 FW860.30 FW860.42
        Microcode Build Date........20180101 20170628 20180101
        Update Access Key Exp Date..20190825
        Hardware Location Code......U8284.22A.XXXXXXX-Y1
      Physical Location: U8284.22A.XXXXXXX-Y1

Relevant sind die Zeilen „Microcode Entitlement Date“ bzw. „Update Access Key Exp Date„.

FC NPIV Client Durchsatz-Statistiken

Bei Verwendung von NPIV teilen sich mehrere Client-LPARs einen physikalischen FC-Port eines Virtual-I/O-Servers. Für Performance-Untersuchungen wäre es natürlich schön, wenn man den Durchsatz der einzelnen Client-LPARs leicht feststellen könnte um diese vergleichend anzuschauen. Damit könnten Fragen wie

  • wieviel Durchsatz erzielt eine bestimmte LPAR gerade
  • welche LPARs haben den höchsten Durchsatz und produzieren den meisten FC-Verkehr
  • treten Resource-Engpässe auf

beantwortet werden.

Es gibt natürlich verschiedene Möglichkeiten diese Daten zu gewinnen. Eine besonders einfache Möglichkeit stellt der Virtual-I/O-Server über das padmin Kommando ‚fcstat‚ bereit. Das Kommando erlaubt die Ausgabe von NPIV-Client-Statistiken bei Verwendung der Option ‚-client‚:

(0)padmin@aixvio1:/home/padmin> fcstat -client
              hostname   dev                wwpn     inreqs    outreqs ctrlreqs          inbytes         outbytes  DMA_errs Elem_errs Comm_errs

               aixvio1  fcs0  0x100000XXXXXXXXXX 49467894179 50422150679 947794529 1861712755360927 1451335312750576         0         0         0
     C050760YYYYYYYYY
                                    0          0        0                0                0         0         0         0
     C050760ZZZZZZZZZ
                                    0          0        0                0                0         0         0         0
                 aix01  fcs0  0xC050760XXXXXXXXX   22685402  101956075 10065757     699512617896    1572578056704         0         0         0
                 aix02  fcs0  0xC050760XXXXXXXXX   28200473   82295158 12051365     387847746448     626772151808         0         0         0
                 aix03  fcs0  0xC050760XXXXXXXXX  376500672  255163053 21583628   22619424512608    3786990844928         0         0         0
                 aix04  fcs0  0xC050760XXXXXXXXX  116450405  504688524 14020031    4037786527400    9929289617408         0         0         0
          blbprodora22  fcs0  0xC050760XXXXXXXXX 1341092479  580673554 37458927   44288566807072   12166718497792         0         0         0
...
               aixvio1  fcs1  0x100000XXXXXXXXXX  391131484 1090556094 156294130   71031615240217   87642294572864         0         0         0
              aixtsm01  fcs2  0xC050760XXXXXXXXX  334020900  785597352 74659821   62072552942128   83284555980288         0         0         0
              aixtsm02  fcs0  0xC050760XXXXXXXXX    2943054   40921231 11617552     107317697968     289142333440         0         0         0

               aixvio1  fcs2  0x210000XXXXXXXXXX  403180246 5877180796   236998  105482699300998 1540608710446612         0         0         0
              aixtsm01  fcs6  0xC050760XXXXXXXXX  146492419  392365162    74250   38378099796342  102844775468007         0         0         0
              aixtsm02  fcs2  0xC050760XXXXXXXXX         19     192848       20             1090      50551063184         0         0         0

               aixvio1  fcs3  0x210000XXXXXXXXXX  405673338 7371951499   260575  105969796271246 1932388891128304         0         0         0
              aixtsm02  fcs3  0xC050760XXXXXXXXX          0          0        4                0                0         0         0         0
                 aix02  fcs7  0xC050760XXXXXXXXX      42624 2677470211    34211          2382280  701864613402184         0         0         0
...
Invalid initiator world wide name
Invalid initiator world wide name
(0)padmin@aixvio1:/home/padmin>

Die Zeile mit der WWPN C050760YYYYYYYYY und C050760ZZZZZZZZZ gehören zu NPIV-Adaptern von nicht aktivierten LPARs. Daher werden als Zähler auch nur Nullen angezeigt. Für jeden physikalischen (NPIV-fähigen) FC-Port des Virtual-I/O-Servers wird der physikalische FC-Port, sowie die NPIV Client-LPARs angezeigt. Anhand des fett-markierten Blocks soll hier kurz die Ausgabe beschrieben werden. Als erstes wird immer der physikalische Port des Virtual-I/O-Servers ausgegeben, hier aixvio1 und FC-Port fcs1. In den darauffolgenden Zeilen kommen dann die NPIV-Clients, jeweils mit dem LPAR-Namen und dem zugehörigen virtuellen FC-Port der LPAR, hier aixtsm01 und aixtsm02. Die virtuellen FC-Ports der LPARs fcs2 (aixtsm01) und fcs0 (aixtsm02) sind auf den physikalischen FC-Port fcs1 von aixvio1 gemappt. Nach einer Leerzeile kommt der nächste physikalische FC-Port des Virtual-I/O-Servers.

In den Spalten werden die WWPN der physikalischen bzw. virtuellen FC-Ports augelistet. Außerdem werden die Anzahl der Ein- und Ausgehenden Requests, sowie die übertragenen Bytes, ebenfalls ein- und ausgehend, aufgelistet. In den 3 verbleibenden Spalten werden Fehler aufgeführt. Gibt es für einen Request keinen DMA Puffer mehr, wird DMA_errs hochgezählt, ist die Queue des FC-Adapters voll, wird Elem_errs hochgezählt, bei Übertragungs-Fehlern wird Comm_errs hochgezählt. Tauchen regelmäßig Zähler bei DMA_errs oder Elem_errs auf, kann das ein Hinweis auf zu kleine Werte bei einigen Tuning-Attributen sein.

Aufgrund der Länge der Ausgabe und den absoluten Zählern die ausgegeben werden, ist die Ausgabe etwas unübersichtlich. Mit einem kleinen Skript kann man aber leicht Delta-Werte errechnen und die Ausgabe auf MB pro Sekunde skalieren. Mit dem nachfolgenden Beispiel-Skript haben wir dies getan:

$ cat npivstat
#! /bin/ksh93
#
# Copyright (c) 2019 by PowerCampus 01 GmbH
# Author: Dr. Armin Schmidt
#

delta=5 # seconds

typeset -A dataInreqs
typeset -A dataOutreqs
typeset -A dataInbytes
typeset -A dataOutbytes
typeset -A dataDMA_errs
typeset -A dataElem_errs
typeset -A dataComm_errs

bc |& # start bc as coroutine
print -p "scale=2"

# get first sample

/usr/ios/cli/ioscli fcstat -client 2>/dev/null | \
while read hostname dev wwpn inreqs outreqs ctrlreqs inbytes outbytes DMA_errs Elem_errs Comm_errs rest
do
case "$wwpn" in
0x*)
dataInreqs[${hostname}_${dev}]=$inreqs
dataOutreqs[${hostname}_${dev}]=$outreqs
dataInbytes[${hostname}_${dev}]=$inbytes
dataOutbytes[${hostname}_${dev}]=$outbytes
dataDMA_errs[${hostname}_${dev}]=$DMA_errs
dataElem_errs[${hostname}_${dev}]=$Elem_errs
dataComm_errs[${hostname}_${dev}]=$Comm_errs
;;
esac
done
sleep $delta

while true
do
/usr/ios/cli/ioscli fcstat -client 2>/dev/null | \
while read hostname dev wwpn inreqs outreqs ctrlreqs inbytes outbytes DMA_errs Elem_errs Comm_errs rest
do
case "$wwpn" in
0x*)
prevInreqs=${dataInreqs[${hostname}_${dev}]}
prevOutreqs=${dataOutreqs[${hostname}_${dev}]}
prevInbytes=${dataInbytes[${hostname}_${dev}]}
prevOutbytes=${dataOutbytes[${hostname}_${dev}]}
prevDMA_errs=${dataDMA_errs[${hostname}_${dev}]}
prevElem_errs=${dataElem_errs[${hostname}_${dev}]}
prevComm_errs=${dataComm_errs[${hostname}_${dev}]}
dataInreqs[${hostname}_${dev}]=$inreqs
dataOutreqs[${hostname}_${dev}]=$outreqs
dataInbytes[${hostname}_${dev}]=$inbytes
dataOutbytes[${hostname}_${dev}]=$outbytes
dataDMA_errs[${hostname}_${dev}]=$DMA_errs
dataElem_errs[${hostname}_${dev}]=$Elem_errs
dataComm_errs[${hostname}_${dev}]=$Comm_errs

print -p "(${inreqs}-${prevInreqs})/$delta"
read -p inreqs
print -p "(${outreqs}-${prevOutreqs})/$delta"
read -p outreqs
print -p "(${inbytes}-${prevInbytes})/${delta}/1024/1024"
read -p inbytes
print -p "(${outbytes}-${prevOutbytes})/${delta}/1024/1024"
read -p outbytes
print -p "(${DMA_errs}-${prevDMA_errs})/$delta"
read -p DMA_errs
print -p "(${Elem_errs}-${prevElem_errs})/$delta"
read -p Elem_errs
print -p "(${Comm_errs}-${prevComm_errs})/$delta"
read -p Comm_errs

printf "%15s %5s %16s %6.2f %7.2f %7.2f %8.2f %8.2f %9.2f %9.2f\n" "$hostname" "$dev" "$wwpn" "$inreqs" "$outreqs" \
"$inbytes" "$outbytes" "$DMA_errs" "$Elem_errs" "$Comm_errs"
;;
"wwpn")
printf "%15s %5s %16s %6s %7s %7s %8s %8s %9s %9s\n" "$hostname" "$dev" "$wwpn" "$inreqs" "$outreqs" \
"$inbytes" "$outbytes" "$DMA_errs" "$Elem_errs" "$Comm_errs"
;;
"")
[ -n "$hostname" ] && continue
printf "%15s %5s %16s %6s %7s %7s %8s %8s %9s %9s\n" "$hostname" "$dev" "$wwpn" "$inreqs" "$outreqs" \
"$inbytes" "$outbytes" "$DMA_errs" "$Elem_errs" "$Comm_errs"
;;
esac
done
print

sleep $delta
done

$

Das Skript steht zum Download in unserem Download-Bereich zur Verfügung.

Hier noch ein Auszug von einem Lauf des Skriptes (stark gekürzt, nur einer der physikalischen Ports ist dargestellt):

aixvio1 # ./npivstat
       hostname    dev              wwpn  inreqs  outreqs  inbytes  outbytes  DMA_errs  Elem_errs  Comm_errs
...                                                                                                          
        aixvio1   fcs2  0x210000XXXXXXXXXX    0.00  1019.00     0.00    254.75      0.00       0.00       0.00
       aixtsm01   fcs6  0xC0507605E5890074    0.00     0.00     0.00      0.00      0.00       0.00       0.00
       aixtsm02   fcs2  0xC0507609A6C70004    0.00     0.00     0.00      0.00      0.00       0.00       0.00
          aix05   fcs6  0xC0507609A6C7001C    0.00  1018.20     0.00    254.55      0.00       0.00       0.00
...                                                                                                          
        aixvio1   fcs2  0x210000XXXXXXXXXX    0.00  1020.20     0.00    255.05      0.00       0.00       0.00
       aixtsm01   fcs6  0xC050760XXXXXXXXX    0.00     0.00     0.00      0.00      0.00       0.00       0.00
       aixtsm02   fcs2  0xC050760XXXXXXXXX    0.00     0.00     0.00      0.00      0.00       0.00       0.00
          aix05   fcs6  0xC050760XXXXXXXXX    0.00  1019.80     0.00    254.95      0.00       0.00       0.00
...                                                                                                           
        aixvio1   fcs2  0x210000XXXXXXXXXX    0.00   984.80     0.00    246.20      0.00       0.00       0.00
       aixtsm01   fcs6  0xC050760XXXXXXXXX    0.00     0.00     0.00      0.00      0.00       0.00       0.00
       aixtsm02   fcs2  0xC050760XXXXXXXXX    0.00     0.00     0.00      0.00      0.00       0.00       0.00
          aix05   fcs6  0xC050760XXXXXXXXX    0.00   985.00     0.00    246.25      0.00       0.00       0.00
...
^Caixvio1 # 

Im obigen Beispiel generiert der NPIV-Client aix05 ca 250 MB/s an Daten, wärend die anderen beiden NPIV-Clients aixtsm01 und aixtsm02 während dieser Zeit keinen FC-Verkehr produzieren.

Das Skript muss als root auf einem Virtual-I/O-Server gestartet werden. Natürlich kann man das Skript auf die eigenen Bedürfnisse anpassen.

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!

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.