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.

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!

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/

Welche FC-Ports gehören zu welcher SAN-Fabric?

In größeren Umgebungen mit vielen Managed Systems und mehreren SAN-Fabrics ist es trotz guter Dokumentation nicht immer klar, zu welcher SAN-Fabric ein FC-Port gehört. In vielen Fällen steht die Hardware weit entfernt vom Bildschirm, eventuell sogar in einem ganz anderen Gebäude oder auch geographisch weiter entfernt, so dass man auch nicht einfach vor Ort die Verkabelung überprüfen kann.

In diesem Blog-Beitrag soll gezeigt werden, wie man mit Hilfe von Live-Partition-Mobility (LPM) alle FC-Ports herausfinden kann, die zu einer gegebenen SAN-Fabric gehören.

Wir verwenden der Einfachheit halber das LPAR-Tool, man kann aber auch ohne LPAR-Tool mit Kommandos der HMC CLI arbeiten, also bitte weiterlesen auch wenn das LPAR-Tool nicht verfügbar sein sollte!

Im Folgenden haben wir unsere SAN-Fabrics mit „Fabric1“ und „Fabric2“ bezeichnet. Das unten beschriebene Verfahren kann aber bei beliebig vielen SAN-Fabrics verwendet werden.

Da LPM verwendet werden soll, benötigen wir erst einmal eine LPAR. Wir legen die LPAR auf einem unserer Managed Systems (ms09) mit dem LPAR-Tool an:

$ lpar –m ms09 create fabric1
Creating LPAR fabric1:
done
Register LPAR
done
$

Man kann natürlich auch die HMC GUI oder die HMC CLI verwenden, um die LPAR anzulegen. Wir haben die neue LPAR nach unserer SAN-Fabric „fabric1“ benannt. Jeder andere Name ist aber genauso gut!

Als nächstes benötigt unsere LPAR einen virtuellen FC-Adapter der auf einen FC-Port der Fabric „Fabric1“ gemappt ist:

$ lpar –p standard addfc fabric1 10 ms09-vio1
fabric1 10 ms09-vio1 20
$

Das LPAR-Tool hat auf dem VIOS ms09-vio1 den Slot 20 für den VFC Server Adapter ausgewählt und neben dem Client- auch den Server-Adapter angelegt. Über das HMC GUI oder die HMC CLI können Client und Server Adapter natürlich genauso angelegt werden. Da die LPAR nicht aktiv ist, wurde mittels der Option ‚-p standard‘ angegeben das nur das Profil angepasst werden soll.

Um den VFC Server Adapter auf einen physikalischen FC-Port zu mappen, benötigen wir die Nummer des vfchost Adapters auf dem VIOS ms09-vio1:

$ vios npiv ms09-vio1
VIOS       ADAPT NAME  SLOT  CLIENT OS      ADAPT   STATUS        PORTS
…
ms09-vio1  vfchost2    C20   (3)    unknown  -     NOT_LOGGED_IN  0
…
$

Im Slot 20 haben wir den vfchost2, dieser muss also nun auf einen FC-Port von Fabric „Fabric1“ gemappt werden. Wir mappen auf den FC-Port fcs8, von dem wir wissen das dieser an die Fabric „Fabric1“ geht. Sollten wir uns irren, werden wir dies in Kürze sehen.

Schauen wir uns kurz die WWPNs für den virtuellen FC Client Adapter an:

$ lpar -p standard vslots fabric1
SLOT  REQ  TYPE           DATA
0     yes  serial/server  remote: (any)/any hmc=1
1     yes  serial/server  remote: (any)/any hmc=1
10    no   fc/client      remote: ms09-vio1(1)/20 c050760XXXXX0016,c050760XXXXX0017
$

Ausgestattet mit den WWPNs lassen wir uns nun von unseren Storage-Kollegen eine kleine LUN für diese WWPNs erstellen, die nur in der Fabric „Fabric1“ sichtbar sein soll. Nachdem die Storage-Kollegen die LUN angelegt und das Zoning entsprechend angepasst haben, aktivieren wir unsere neue LPAR im OpenFirmware Modus und öffnen eine Console:

$ lpar activate –p standard –b of fabric1

$ lpar console fabric1

Open in progress 

Open Completed.

IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM
...

          1 = SMS Menu                          5 = Default Boot List
          8 = Open Firmware Prompt              6 = Stored Boot List

     Memory      Keyboard     Network     SCSI     Speaker  ok
0 >

Das geht natürlich auch wieder ohne Probleme mit GUI oder HMC CLI.

Im OpenFirmware Modus starten wir ioinfo und überprüfen ob die kleine LUN sichtbar ist. Wenn diese nicht sichtbar ist, dann lag der FC-Port fcs8 doch nicht in der richtigen Fabric!

0 > ioinfo

!!! IOINFO: FOR IBM INTERNAL USE ONLY !!!
This tool gives you information about SCSI,IDE,SATA,SAS,and USB devices attached to the system

Select a tool from the following

1. SCSIINFO
2. IDEINFO
3. SATAINFO
4. SASINFO
5. USBINFO
6. FCINFO
7. VSCSIINFO

q - quit/exit

==> 6

FCINFO Main Menu
Select a FC Node from the following list:
 # Location Code           Pathname
-------------------------------------------------
 1. U9117.MMC.XXXXXXX7-V10-C10-T1  /vdevice/vfc-client@3000000a

q - Quit/Exit

==> 1

FC Node Menu
FC Node String: /vdevice/vfc-client@3000000a
FC Node WorldWidePortName: c050760XXXXXX0016
------------------------------------------
1. List Attached FC Devices
2. Select a FC Device
3. Enable/Disable FC Adapter Debug flags

q - Quit/Exit

==> 1

1. 500507680YYYYYYY,0 - 10240 MB Disk drive

Hit a key to continue...

FC Node Menu
FC Node String: /vdevice/vfc-client@3000000a
FC Node WorldWidePortName: c050760XXXXXX0016
------------------------------------------
1. List Attached FC Devices
2. Select a FC Device
3. Enable/Disable FC Adapter Debug flags

q - Quit/Exit

==> q

Die LUN taucht auf, die WWPN 500507680YYYYYYY ist die WWPN des zugehörigen Storage-Ports, diese ist weltweit eindeutig und kann damit nur in der Fabric „Fabric1“ gesehen werden!

Das Aktivieren der LPAR im OpenFirmware Modus hat zwei Zwecken gedient, zum Einen um zu Überprüfen das die LUN sichtbar ist und unser Mapping auf fcs8 richtig war, zum Anderen hat das System nun die Information welche WWPNs bei einer LPM-Operation gefunden werden müssen, damit die LPAR verschoben werden kann!

Wir deaktivieren die LPAR nun wieder.

$ lpar shutdown –f fabric1
$

Führen wir nun eine LPM Validierung für die inaktive LPAR durch, so kann eine Valdierung nur auf einem Managed System erfolgreich sein, welches einen Virtual-I/O-Server mit einer Anbindung an die Fabric „Fabric1“ besitzt. Mit einer kleinen for-Schleife probieren wir das für einige Managed Systems aus:

$ for ms in ms10 ms11 ms12 ms13 ms14 ms15 ms16 ms17 ms18 ms19
do
echo $ms
lpar validate fabric1 $ms >/dev/null 2>&1
if [ $? -eq 0 ]
then
   echo connected
else
   echo not connected
fi
done

Das Kommando auf der HMC CLI zum Validieren ist ‚migrlpar‚.

Da wir nicht an den Meldungen der Validierung interessiert sind, leiten wir alle Meldungen der Validierung nach /dev/null um.

Hier die Ausgabe der for-Schleife:

ms10
connected
ms11
connected
ms12
connected
ms13
connected
ms14
connected
ms15
connected
ms16
connected
ms17
connected
ms18
connected
ms19
connected

Offensichtlich sind alle Managed Systems an die Fabric „Fabric1“ angebunden. Das ist aber nicht sehr überraschend, da diese genau so aufgebaut wurden.

Interessanter wäre es nun zu wissen welcher FC-Port auf den Managed Systems (Virtual-I/O-Servern) an die Fabric „Fabric1“ angebunden sind. Dazu benötigen wir für jedes Managed System eine Liste der Virtual-I/O-Server und für jeden Virtual-I/O-Server die Liste der NPIV-fähigen FC-ports.

Die Liste der Virtual-I/O-Server kann relativ einfach mit dem folgenden Kommando gewonnen werden:

$ vios -m ms11 list
ms11-vio1
ms11-vio2
$

Auf der HMC CLI kann man das Kommando: lssyscfg -r lpar -m ms11 -F „name lpar_env“ verwenden.

Die NPIV-fähigen Ports kann man mit dem folgenden Kommando herausfinden :

$ vios lsnports ms11-vio1
ms11-vio1       name             physloc                        fabric tports aports swwpns  awwpns
ms11-vio1       fcs0             U78AA.001.XXXXXXX-P1-C5-T1          1     64     60   2048    1926
ms11-vio1       fcs1             U78AA.001.XXXXXXX-P1-C5-T2          1     64     60   2048    2023
...
$

Zum Einsatz kommt das Kommando lsnports auf dem Virtual-I/O-Server. Dieses kann man natürlich auch ohne LPAR-Tool ausführen.

Bei der LPM-Validierung (und natürlich auch bei der Migration) kann man angeben welcher FC-Port auf dem Ziel-System verwendet werden soll, wir zeigen dies hier einmal an zwei Beispielen:

$ lpar validate fabric1 ms10 virtual_fc_mappings=10/ms10-vio1///fcs0 >/dev/null 2>&1
$ echo $?
0
$ lpar validate fabric1 ms10 virtual_fc_mappings=10/ms10-vio1///fcs1 >/dev/null 2>&1
$ echo $?
1
$

Die Validierung mit Ziel ms10-vio1 und fcs0 war erfolgreich, d.h. das dieser FC-Port an die Fabric „Fabric1“ angeschlossen ist. Die Validierung mit Ziel ms10-vio1 und fcs1 war nicht erfolgreich, d.h. das dieser Port nicht an die Fabric „Fabric1“ angebunden ist.

Hier kurz das Kommando das auf der HMC aufgerufen werden muss, falls das LPAR-Tool nicht verwendet werden soll:

$ lpar -v validate fabric1 ms10 virtual_fc_mappings=10/ms10-vio1///fcs0
hmc02: migrlpar -m ms09 -o v -p fabric1 -t ms10 -v -d 5 -i 'virtual_fc_mappings=10/ms10-vio1///fcs0'
$

Um alle FC-Ports die an die Fabric „Fabric1“ angeschlossen sind herauszufinden, brauchen wir eine Schleife über die zu überprüfenden Managed Systems, für jedes Managed Systeme benötigen wir dann eine Schleife über alle VIOS des Managed Systems und letztlich für jeden VIOS eine Schleife über alle FC-Ports mit einer LPM-Validierung.

Wir haben dies im folgenden Skript zusammengefasst. Damit es nicht zu lang wird, haben wir einige Checks weggelassen:

$ cat bin/fabric_ports
#! /bin/ksh
# Copyright © 2018, 2019 by PowerCampus 01 GmbH

LPAR=fabric1

STATE=$( lpar prop -F state $LPAR | tail -1 )

print "LPAR: $LPAR"
print "STATE: $STATE"

if [ "$STATE" != "Not Activated" ]
then
            print "ERROR: $LPAR must be in state 'Not Activated'"
            exit 1
fi

fcsCount=0
fcsSameFabricCount=0

for ms in $@
do
            print "MS: $ms"
            viosList=$( vios -m $ms list )

            for vios in $viosList
            do
                        rmc_state=$( lpar -m $ms prop -F rmc_state $vios | tail -1 )
                        if [ "$rmc_state" = "active" ]
                        then
                                    fcList=
                                    vios -m $ms lsnports $vios 2>/dev/null | \
                                    while read vio fcport rest
                                    do
                                               if [ "$fcport" != "name" ]
                                               then
                                                           fcList="${fcList} $fcport"
                                               fi
                                    done

                                    for fcport in $fcList
                                    do
                                               print -n "${vios}: ${fcport}: "
                                               lpar validate $LPAR $ms virtual_fc_mappings=10/${vios}///${fcport} </dev/null >/dev/null 2>&1
                                               case "$?" in
                                               0)
                                                           print "yes"
                                                           fcsSameFabricCount=$( expr $fcsSameFabricCount + 1 )
                                                           ;;
                                               *) print "no" ;;
                                               esac
                                               fcsCount=$( expr $fcsCount + 1 )
                                    done
                        else
                                    print "${vios}: RMC not active"
                        fi
            done
done

print "${fcsCount} FC-ports investigated"
print "${fcsSameFabricCount} FC-ports in same fabric"

$

Zur Illustration zeigen wir hier kurz einen Lauf des Skripts über einige Managed Systems. Wir starten das Skript mittels time, um zu sehen wie lange das ganze dauert:

$ time bin/fabric_ports ms10 ms11 ms12 ms13 ms14 ms15 ms16 ms17 ms18 ms19
LPAR: fabric1
STATE: Not Activated
MS: ms10
ms10-vio3: RMC not active
ms10-vio1: fcs0: yes
ms10-vio1: fcs2: yes
ms10-vio1: fcs4: no
ms10-vio1: fcs6: no
ms10-vio2: fcs0: yes
ms10-vio2: fcs2: yes
ms10-vio2: fcs4: no
ms10-vio2: fcs6: no
MS: ms11
ms11-vio3: RMC not active
ms11-vio1: fcs0: no
ms11-vio1: fcs1: no
ms11-vio1: fcs2: no
ms11-vio1: fcs3: yes
ms11-vio1: fcs4: no
…
ms19-vio2: fcs2: no
ms19-vio2: fcs3: no
ms19-vio2: fcs0: no
ms19-vio2: fcs1: no
ms19-vio2: fcs4: no
ms19-vio2: fcs5: no
132 FC-ports investigated
17 FC-ports in same fabric

real       2m33.978s
user      0m4.597s
sys       0m8.137s
$

In ca 150 Sekunden wurden 132 FC-Ports untersucht (LPM-Validierungen durchgeführt). Das bedeutet das eine Validierung im Durchschnitt in etwa 1 Sekunde benötigt hat.

Wir haben damit alle FC-Ports gefunden, welche an die Fabric „Fabric1“ angeschlossen sind.

Das lässt sich natürlich für weitere Fabrics analog durchführen.

Noch ein Hinweis, nicht alle Ports oben sind verkabelt!