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.

TCP-Verbindungsabbrüche wegen „max assembly queue depth“

Kürzlich hatten wir häufige Programm-Abbrüche von einigen Java-Client Programmen. Im Java Stack-Trace war folgendes zu finden:

[STACK] Caused by: java.io.IOException: Premature EOF
[STACK]           at sun.net.www.http.ChunkedInputStream.readAheadBlocking(Unknown Source)
[STACK]           at sun.net.www.http.ChunkedInputStream.readAhead(Unknown Source)
[STACK]           at sun.net.www.http.ChunkedInputStream.read(Unknown Source)
[STACK]           at java.io.FilterInputStream.read(Unknown Source)

Das Problem tritt in der Klasse ChunkedInputStream in der Methode readAheadBlocking auf. Im Source Code der Methode findet man:

558 /**
559 * If we hit EOF it means there's a problem as we should never
560 * attempt to read once the last chunk and trailers have been
561 * received.
562 */
563 if (nread < 0) {
564 error = true;
565 throw new IOException("Premature EOF");
566 }

Der Wert nread wird kleiner 0, wenn das Ende des Datenstroms erreicht ist. Dies kann auch passieren wenn die Gegenseite die Verbindung unerwartet schließt.

Die Serverseite war in diesem Fall ein AIX-System (AIX 7.1 TL5 SP3). Eine Überprüfung der TCP-Verbindungen auf Abbrüche (Drops) mittels netstat ergab:

$ netstat -p tcp | grep drop
        361936 connections closed (including 41720 drops)
        74718 embryonic connections dropped
                0 connections dropped by rexmit timeout
                0 connections dropped due to persist timeout
                0 connections dropped by keepalive
        0 packets dropped due to memory allocation failure
        0 Connections dropped due to bad ACKs
        0 Connections dropped due to duplicate SYN packets
        1438 connections dropped due to max assembly queue depth
$

Demnach gab es 1438 Verbindungsabbrüche wegen Erreichen der maximalen TCP Assembly Queue Tiefe (max assembly queue depth). Die Queue Tiefe wird über den neuen Kernel Parameter tcp_maxqueuelen konfiguriert, der als Fix für den CVE-2018-6922 eingeführt wurde (siehe: The CVE-2018-6922 fix (FreeBSD vulnerability) and scp) . Der Defaultwert ist 1000. Bei größeren Paket-Laufzeiten kann es zum Überlauf der Queue kommen.

Nach einer Erhöhung des Kernel-Parameters tcp_maxqueuelen sind keine Verbindungsabbrüche mehr aufgetreten.

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.

ProbeVue in Action: Überwachen der „Queue Depth“ von Platten

Platten und Storage Systeme unterstützen Tagged Command Queueing, d.h. angeschlossene Server können mehrere I/O Aufträge an die Platte oder das Storage-System senden ohne zu Warten das ältere I/O-Aufträge fertig sind. Wieviele I/O-Aufträge man an eine Platte senden darf, bevor man warten muss das ältere I/O-Aufträge abgeschlossen wurden, kann über das hdisk Attribut queue_depth unter AIX konfiguriert werden. Für viele hdisk Typen ist der Wert 20 für die queue_depth der Default-Wert. In der Regel erlauben die meisten Storage-Systeme aber noch größere Werte für die Queue-Depth.

Mit Hilfe von ProbeVue lässt sich die Auslastung der Platten-Queue sehr leicht beobachten.

Ab AIX 7.1 TL4 bzw. AIX 7.2 TL0 unterstützt AIX den I/O Probe Manager. Damit lassen sich auf einfache Weise Ereignisse im I/O Stack von AIX tracen. Wird ein I/O vom Platten-Treiber gestartet, so geschieht dies über die Funktion iostart im Kernel, der Request wird an den Adapter-Treiber weitergegeben und geht dann über den Host-Bus-Adapter an das Storage-System. Das Bearbeiten der Antwort wird von der Funktion iodone im Kernel übernommen. Der I/O Probe-Manager unterstützt (unter anderem) Proben an diesen Stellen:

@@io:disk:iostart:read:<filter>
@@io::disk:iostart:write:<filter>
@@io:disk:iodone:read:<filter>
@@io::disk:iodone:write:<filter>

Als Filter kann z.B. ein Hdisk Name wie hdisk2 angegeben werden. Die Proben-Punkte lösen dann nur Ereignisse für die Platte hdisk2 aus. Damit lässt sich schon einmal eine Aktion durchführen wann immer ein I/O für eine Hdisk beginnt oder endet. Damit könnte man z.B. messen wie lange eine I/O Operation dauert oder auch einfach nur mitzählen wieviele I/Os ausgeführt werden. In unserem Beispiel waren wir aber an der Auslastung der Platten-Queue interessiert, d.h. der Anzahl I/Os die an die Platte gesendet aber noch nicht abgeschlossen wurden. Der I/O Probe-Manager besitzt für die I/O Ereignisse  iostart und iodone die Builtin-Variable __diskinfo mit den folgenden Feldern (https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.genprogc/probevue_man_io.htm):

name          char*     Name der Platte
…
queue_depth   int       Die Queue-Depth der Platte (Wert aus der ODM)
cmds_out      int       Anzahl der ausstehenden I/Os
…

Das Feld cmds_out gibt an wieviele I/Os an die Platte gesendet wurden, für die das I/O noch nicht abgeschlossen ist (Antwort ist noch nicht beim Server angekommen).

Mit dem folgenden Code-Abschnitt ermitteln wir die minimale, maximale und durchschnittliche Anzahl an Einträgen in der Platten-Queue:

@@io:disk:iostart:*:hdisk0     // Nur I/Os für hdisk0 berücksichtigen
{
   queue = __iopath->cmds_out; // Anzahl ausstehende I/Os in Variable queue festhalten
   ++numIO;                    // Anzahl I/Os in der Variablen numIO mitzählen (wegen Durchschnittsbildung)
   avg += queue;               // Variable avg um Anzahl ausstehende I/Os erhöhen
   if ( queue < min )
      min = queue;             // Überprüfen auf Minimum und gegebenenfalls setzen
   if ( queue > max )
      max = queue;             // Überprüfen auf Maximum und gegebenenfalls setzen
}

Die ermittelten Werte geben wir dann einmal pro Sekunde mit Hilfe des Intervall Probe-Managers aus:

@@interval:*:clock:1000
{
   if ( numIO == 0 )
      numIO = 1;    // Verhindert Division durch 0 bei der Durchschnittsbildung
   if ( min > max )
      min = max;
   printf( "%5d  %5d  %5d\n" , min , avg/numIO , max );
   min = 100000;   // Zurücksetzen der Variablen für das nächste Intervall
   avg = 0;
   max = 0;
   numIO = 0;
}

Das vollständige Skript ist auf unserer Webseite zum Download verfügbar: ioqueue.e.

Hier ein Beispiel-Lauf des Skriptes für die Platte hdisk13:

# ./ioqueue.e hdisk13
  min    avg    max
    1      1      2
    1      1      9
    1      1      2
    1      1      8
    1      1      2
    1      1      2
    1      1      8
    1      1     10
    1      1      2
    1      1      1
    1      1     10
    1      1      2
    1      1     11
...

Das Skript erwartet die Angabe einer hdisk als Argument und gibt dann einmal pro Sekunde die ermittelten Werte für die angegebene hdisk aus.

In der Beispiel-Ausgabe sieht man das die maximale Anzahl der Einträge in der Platten-Queue 11 ist. Eine Erhöhung des Attributes queue_depth macht daher aus Performance-Sicht keinen Sinn.

Hier ein anderes Beispiel:

# ./ioqueue.e hdisk21
  min    avg    max
    9     15     20
   11     17     20
   15     19     20
   13     19     20
   14     19     20
   17     18     20
   18     18     19
   16     19     20
   13     18     20
   18     19     19
   17     19     20
   18     19     20
   17     19     19
...

In diesem Fall wird der maximale Wert 20 (die hdisk21 hat eine queue_depth von 20) regelmäßig erreicht. Eine Erhöhung der queue_depth kann in diesem Fall zu einer Verbesserung des Durchsatzes führen.

Das Beispiel-Skript lässt sich natürlich noch beliebig erweitern, man könnte z.B. noch den Durchsatz erfassen, oder die Wartezeit von I/Os in der Wait-Queue oder auch die Position und Größe jedes I/Os auf der Platte. Das dargestellte Beispiel zeigt wie einfach man Informationen zu I/Os mit Hilfe von ProbeVue ermitteln kann.

 

Zahlen: FC World Wide Names (WWNs)

Die meisten kennen WWNs als 64-bit WWNs, geschrieben als 16 hexadezimale Ziffern. Die Kenntnis das es verschiedene Formate bei den WWNs gibt und es auch 128-bit WWNs gibt ist nicht ganz so bekannt. In diesem Artikel sollen daher die verschiedenen Formate von WWNs kurz vorgestellt werden.

Der grundlegende Aufbau von 64-bit WWNs sieht wie folgt aus:

+---+----------------+
|NAA| NAME           |
+---+----------------+
4-bit 60-bit

Das 4-bit NAA (Network Address Authority) Feld gibt dabei den Typ der Adresse und das Format der Adresse vor.

Für das 60-bit NAME Feld gibt es eine Reihe von verschiedenen Möglichkeiten.

1. Format 1 Adresse (NAA = 0001)

+---+--------+------------------------+
|NAA|Reserved| 48-bit IEEE MAC Address|
+---+--------+------------------------+
4-bit 12-bit   48-bit

Im Feld Reserved (12-bit) müssen alle Bits auf 0 gesetzt sein!

Beispiel:

1 000 00507605326d (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

2. Format 2 Adresse (NAA = 0010)

+---+---------------+-----------------------+
|NAA|Vendor Assigned|48-bit IEEE MAC Address|
+---+---------------+-----------------------+
4-bit  12-bit         48-bit

Das 12-bit “Vendor Assigned” Feld kann vom Hersteller beliebig verwendet werden.

Beispiel:

2 001 00507605326d (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

3. Format 3 Adresse (NAA = 0011)

+---+-----------------+
|NAA|Vendor Assigned  |
+---+-----------------+
4-bit 60-bit

Das Feld „Vendor Assigned“ (60-bit) wird vom Hersteller beliebig vergeben. Damit ist diese Art von Adresse nicht weltweit eindeutig und ist daher in der Praxis eher nicht anzutreffen.

Beispiel:

3 0123456789abcde (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

4. Format 4 Adresse (NAA = 0100)

+---+---------+--------------+
|NAA|Reserved | IPv4 Address |
+---+---------+--------------+
4-bit 28-bit     32-bit

Das Feld “IPv4 Address” (32-bit) enthält eine 32-bit IPv4 Adresse.

Beispiel für IP 10.0.0.1:

4 0000000 0a000001 (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

5. Format 5 Adresse (NAA = 0101)

+---+-------+-----------------+
|NAA| OUI   | Vendor Assigned |
+---+-------+-----------------+
4.bit 24-bit 36-bit

Das Feld OUI (24-bit) enthält die 24-bit vom IEEE zugewiesene ID (Organizational Unique ID).

Das Feld „Vendor Assigned“ (36-bit) kann wieder vom Hersteller beliebig vergeben werden.

Beispiel:

5 005076 012345678 (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

6. Format 6 Adresse (NAA = 0110)

Format 6 Adressen sind 128-bit Adressen und werden häufig für LUNs im SAN verwendet.

+---+-------+---------------+-------------------------+
|NAA|  OUI  |Vendor Assigned|Vendor Assigned Extension|
+---+-------+---------------+-------------------------+
4.bit 24-bit  36-bit          64-bit

Das Feld OUI (24-bit) enthält die 24-bit vom IEEE zugewiesene ID.

Das Feld „Vendor Assigned“ (36-bit) kann vom Hersteller beliebig vergeben werden.

Das Feld „Vendor Assigned Extension“ (64-bit) kann ebenso vom Hersteller beliebig vergeben werden.

Beispiel:

6 005076 012345678 0123456789abcdef (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

7. IEEE EUI-64 Adresse (NAA=11)

Bei diesem Adress-Format ist das Feld NAA auf lediglich 2-bit verkürzt, wobei NAA den Wert 11 hat.

+---+-------------+---------------+
|NAA|OUI shortened|Vendor Assigned|
+---+-------------+---------------+
2-bit 22-bit       40-bit

Das Feld “OUI shortened” (22-bit) ist dabei eine auf 22-bit gekürzte Version der vom IEEE zugewiesenen 24-bit ID.

(Die beiden niederwertigsten Bit des 1 Byte werden hierbei weggelassen und die verbleibenden 6-Bit werden um 2 Bit-Positionen nach rechts verschoben um Platz für die beiden NAA Bits zu machen.)

Das Feld „Vendor Assigned“ (40-bit) kann vom Hersteller beliebig vergeben werden.

Diese Art von Adressen werden häufig im Bereich Virtualisierung verwendet, z.B. wenn es um NPIV (N_Port ID Virtualization) geht.

Beispiel:

C05076 0123456789 (Zur Verdeutlichung des Formats sind die Felder durch Leerzeichen getrennt)

 

 

Volles Filesystem: df und du zeigen unterschiedliche Belegung

Volle Filesysteme kommen in der Praxis immer wieder vor, jeder kennt dies. Üblicherweise sucht man dann nach großen Dateien oder Verzeichnissen und überprüft ob ältere Daten gelöschte werden können um wieder Platz zu schaffen (manchmal wird aber auch einfach das Filesystem vergrößert ohne genauere Untersuchung). In manchen Fällen lassen sich aber keine größeren Dateien finden die man löschen könnte oder man entdeckt das scheinbar Filesystem-Platz weg ist, kann aber nicht identifizieren wo dieser Platz verwendet wird. Das Kommando du zeigt dann einen kleineren Wert für den verwendeten Filesystem-Platz an als df. Im folgenden ist ein solches Beispiel gezeigt, und auch der Hinweis wie sich identifizieren lässt wo der Filesystem-Platz abgeblieben ist und wie er sich dann letztlich auch wiedergewinnen lässt. AIX hat hier eine schöne Möglichkeit zu bieten, die man nicht in jedem UNIX-Derivat findet.

Das Filesystem /var/adm/log ist zu 91% gefüllt, aktuell sind 3.6 GB des Filesystems in Benutzung:

# df -g  /var/adm/log
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
/dev/varadmloglv      4.00      0.39   91%      456     1% /var/adm/log
#

Eine Überprüfung mit dem Kommando du zeigt das scheinbar wesentlich weniger Platz belegt ist:

# du –sm /var/adm/log
950.21   /var/adm/log
#

Das Kommando “disk usage” kommt lediglich auf 950 MB belegten Platz! Das sind 2.7 GB weniger als der Wert aus dem Kommando df. Doch wo ist der fehlende Platz?

Der Unterschied kommt von Dateien die gelöscht wurden, aber noch von mindestens einem Prozeß geöffnet sind. Der Eintrag für solche Dateien wird aus dem zugehörigen Directory entfernt, womit auf die Datei nicht mehr zugegriffen werden kann. Daher zählt das Kommando du diese Dateien bei der Aufsummierung auch nicht mit und kommt auf den kleineren Wert. Solange ein Prozeß die gelöschte Datei noch in Benutzung hat, werden die zugehörigen Blöcke im Filesystem aber nicht freigegeben, daher zeigt df diese auch als belegt an.

Es gibt also mindestens eine Datei in dem Filesystem /var/adm/log welche gelöscht wurde, aber noch von einem Prozeß geöffnet ist. Es stellt sich die Frage wie man den betreffenden Prozeß und die Datei identifizieren kann.

AIX bietet eine einfache Möglichkeit Prozesse zu identifizieren die gelöschte Dateien geöffnet haben, das Kommando fuser besitzt hierfür die Option -d um Prozesse aufzulisten, die gelöschte Dateien geöffnet haben:

# fuser -d /var/adm/log
/var/adm/log:  9110638
#

Verwendet man zusätzlich die Option –V, dann werden auch noch Informationen zu den gelöschten Dateien angezeigt, wie Inode-Nummer und Dateigröße:

# fuser -dV /var/adm/log
/var/adm/log:
inode=119    size=2882647606   fd=12     9110638
#

Die Ausgabe zeigt das hier die Datei mit der Inode-Nummer 119 mit der Größe ca 2.8 GB gelöscht wurde, aber vom Prozeß mit der PID 9110638 über den File Descriptor 12 immer noch geöffnet ist.

Mittels ps lässt sich schnell herausfinden um welchen Prozeß es sich handelt:

# ps -ef|grep 9110638
    root  9110638  1770180   0   Nov 20      - 28:28 /usr/sbin/syslogd
    root  8193550  8849130   0 09:13:35  pts/2  0:00 grep 9110638
#

Es handelt sich hier um den syslogd. Vermutlich wurde hier eine Log-Datei mittels mv rotiert, ohne den syslogd zu informieren (refresh –s syslogd). Wir holen dies kurz nach und überprüfen dann noch einmal das Filesystem:

# refresh -s syslogd
0513-095 The request for subsystem refresh was completed successfully.
#
# df -g /var/adm/log
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
/dev/varadmloglv      4.00      3.07   24%      455     1% /var/adm/log
#

Die Ausgabe zeigt das die Filesystem-Blöcke jetzt freigegeben wurden.

 

ProbeVue in Action: Identifizieren eines Abstürzenden Prozesses

Kürzlich meldete unser Monitoring ein volles /var-Filesystem auf einem unserer Systeme. Schnell war herausgefunden das Core-Files im Verzeichnis /var/adm/core das Filesystem gefüllt hatten. Es stellte sich schnell heraus das alle Core-Files von Perl stammten. Allerdings konnte anhand der Core-Files nicht festgestellt werden welches Perl-Skript den Absturz von Perl verursacht hatte. Ein Blick auf die Zeitstempel der Core-Files ließ leider kein Muster erkennen:

-bash-4.4$ ls -ltr /var/adm/core
total 2130240
drwxr-xr-x    2 root     system          256 Jan 29 10:20 lost+found/
-rw-------    1 root     system    100137039 Jun 26 04:51 core.22610328.26025105.Z
-rw-------    1 root     system     99054991 Jun 26 06:21 core.21102892.26042104.Z
-rw-------    1 root     system     99068916 Jun 26 08:06 core.18153840.26060607.Z
-rw-------    1 root     system    100132866 Jun 26 08:21 core.19005848.26062105.Z
-rw-------    1 root     system     97986020 Jun 26 16:36 core.15270246.26143608.Z
-rw-------    1 root     system     99208958 Jun 26 22:21 core.22675838.26202106.Z
-rw-------    1 root     system     97557063 Jun 27 01:06 core.5505292.26230604.Z
-rw-------    1 root     system     98962499 Jun 27 10:06 core.8257960.27080603.Z
-rw-------    1 root     system     99804173 Jun 27 14:51 core.18940202.27125107.Z
-rw-------    1 root     system     99633676 Jun 28 03:21 core.17563960.28012107.Z
-rw-------    1 root     system     99116032 Jun 28 19:06 core.8651210.28170608.Z
-bash-4.4$

Auch die Einträge im Error Report lieferten keine Informationen um welches Perl-Skript es sich hier handelt und auf welchem Wege dieses gestartet wurde.

 

-bash-4.4$ sudo errpt -j A924A5FC –a
...
---------------------------------------------------------------------------
LABEL:          CORE_DUMP
IDENTIFIER:     A924A5FC

Date/Time:       Wed May 29 15:21:25 CEST 2019
Sequence Number: 17548
Machine Id:      XXXXXXXXXXXX
Node Id:         XXXXXXXX
Class:           S
Type:            PERM
WPAR:            Global
Resource Name:   SYSPROC        

Description
SOFTWARE PROGRAM ABNORMALLY TERMINATED

Probable Causes
SOFTWARE PROGRAM

User Causes
USER GENERATED SIGNAL

        Recommended Actions
        CORRECT THEN RETRY

Failure Causes
SOFTWARE PROGRAM

        Recommended Actions
        RERUN THE APPLICATION PROGRAM
        IF PROBLEM PERSISTS THEN DO THE FOLLOWING
        CONTACT APPROPRIATE SERVICE REPRESENTATIVE

Detail Data
SIGNAL NUMBER
         11
USER'S PROCESS ID:
              13369662
FILE SYSTEM SERIAL NUMBER
           1
INODE NUMBER
                 69639
CORE FILE NAME
/var/adm/core/core.13369662.29132106
PROGRAM NAME
perl
STACK EXECUTION DISABLED
           0
COME FROM ADDRESS REGISTER

PROCESSOR ID
  hw_fru_id: 1
  hw_cpu_id: 19

ADDITIONAL INFORMATION

Unable to generate symptom string.
Too many stack elements.
-bash-4.4$

Die einzige Information, die sich entnehmen ließ, war das die Prozesse mit dem Signal 11 (SIGSEGV) beendet wurden, also aufgrund eines Zugriffs auf eine ungültige Speicher-Adresse.

Es stellte sich die Frage: wie kann ermittelt werden um welches Perl-Skript es sich handelt und auf welchem Wege es gestartet wird.

Dies sollte sich eigentlich mit Hilfe von ProbeVue herausfinden lassen.

Es bot sich der sysproc-Provider an, der im Falle eines Exits eines Prozesses ein Event generiert. Über die spezielle built-in Variable __exitinfo werden genauere Informationen zum Exit, wie Exit-Status oder die Signal-Nummer die den Prozess beendet hat bereitgestellt. Damit lässt sich schon einmal die folgende Probe schreiben:

1: @@sysproc:exit:*
2: when ( __exitinfo->signo == 11 )
3: {
4:         printf( "%llu:  %s\n" , __pid , __pname );
5:         ptree(10);
6: }

Die 6 Zeilen seien hier kurz erklärt:

  1. Der Probe-Point: Provider ist sysproc, Event is exit, * bedeutet beliebiger Prozeß
  2. Durch Verwendung des obigen Prädikats wird der nachfolgende Action Block nur ausgeführt, wenn der Prozeß mit dem Signal 11 (SIGSEGV) beendet wurde.
  3. Start des Action Blocks.
  4. Ausgeben der PID und des Programm-Namens des Prozesses.
  5. Die Funktion ptree gibt den Vater, Großvater usw. (bis 10 Ebenen) des Prozesses aus.
  6. Hier endet der Action Block.

Leider lassen sich hier keine Argumente auflisten, mit denen das Programm gestartet wurde, was in unserem Falle mit Perl den Namen des Skriptes geliefert hätte. Aber immerhin bekommt man über die Funktion ptree heraus auf welchem Wege das Programm aufgerufen wurde, was in manchen Fällen schon ausreicht um das Programm dann letztlich zu identifizieren.

Wir hätten zur Identifikation gerne noch die Information über die Argumente mit denen Perl aufgerufen wurde. Diese Information liefert der syscall-Provider für den System-Call execve mit dem das Programm letztlich gestartet wird. Der Probe-Point ist damit syscall:*:execve:entry, da beim Eintritt in die Funktion die Argumente bekannt sind. Die Signatur von execve für ProbeVue sieht dann so aus:

int execve( char* , struct arg_t* args , char* );

Hierbei ist das erste Argument (wird von ProbeVue als __arg1 bereitgestellt) der Programm-Name. Das zweite Argument ist eine Struktur mit den gesuchten Argumenten (bereitgestellt über __arg2). Über das dritte Argumente hat man Zugriff auf Environment-Variablen, was aber in unserem Falle nicht von Bedeutung ist. Die Struktur struct arg_t sieht für 5 Argumente so aus:

struct arg_t
{
        union
        {
                char* arg[5];
                int num[5];
        } u;
};

Diese Struktur und die Signatur von execve müssen im ProbeVue-Skript deklariert werden, bevor man diese benutzen kann.

Beim Zugriff auf die Argumente ergibt sich dann noch ein kleines weiteres Problem: wenn der Action Block für unsere Probe angesprochen wird, sind wir im Kernel-Modus, die Argumente selber sind aber Adressen im User-Mode des Prozesses. Die Daten (in diesem Falle Zeichenketten) müssen aus dem User-Adreß-Raum herauskopiert werden. Dies erledigt die Funktion get_userstring.

Wir lassen uns bei jedem execve die PID, den Programm-Namen, das Kommando und bis zu 5 Argumente ausgeben. Dies ist im folgenden Programm implementiert:

#! /usr/bin/probevue

struct arg_t
{
        union
        {
                char* arg[5];
                int num[5];
        } u;
};

int execve( char* , struct arg_t* args , char* );

@@syscall:*:execve:entry
{
        __auto String command[128];
        __auto String argument[128];
        __auto struct arg_t argv;
        copy_userdata( __arg2 , argv );
        command = get_userstring( __arg1 , -1 );
        argument = get_userstring( argv.u.arg[0] , -1 );
        printf( "%llu: %s called execve(%s) with arguments: %s " , __pid , __pname , command , argument )
;
        if ( argv.u.num[1] != 0 )
        {
                argument = get_userstring( argv.u.arg[1] , -1 );
                printf( "%s " , argument );
                if ( argv.u.num[2] != 0 )
                {
                        argument = get_userstring( argv.u.arg[2] , -1 );
                        printf( "%s " , argument );
                        if ( argv.u.num[3] != 0 )
                        {
                                argument = get_userstring( argv.u.arg[3] , -1 );
                                printf( "%s " , argument );
                                if ( argv.u.num[4] != 0 )
                                {
                                        argument = get_userstring( argv.u.arg[4] , -1 );
                                        printf( "%s " , argument );
                                }
                        }
                }
        }
        printf( "\n" );
}

@@sysproc:exit:*
when ( __exitinfo->signo == 11 )
{
        printf( "%llu:  %s\n" , __pid , __pname );
        ptree(10);
}

Das Skript haben wir capture_segv.e genannt und ausführbar gemacht.

In der Theorie sollte das Programm nach dem Start alle startenden Programme mit PID, Namen und bis zu 5 Argumenten ausgeben. Außerdem erfolgt eine Ausgabe wenn ein Prozess mit dem Signal 11 (SIGSEGV) abgebrochen wird. Die entsprechende PID kann man dann weiter oben in der Ausgabe suchen und damit das Programm mit Argumenten identifizieren.

Leider ergibt sich in der Praxis das folgende kleine Problem: wenn ein Programm nach dem execve sehr schnell beendet wird, bevor ProbeVue mit get_userstring die Argumente kopieren kann, kommt es bei get_userstring zu einem Zugriff auf eine nicht mehr existierende Adresse und das ProbeVue Skript wird abgebrochen. Wir haben dies umgangen, indem wir das ProbeVue Skript einfach über eine Endlos-Schleife immer wieder starten:

# while true; do ./capture_segv.e >>/tmp/wait_for_segv ; done

Wir haben das ProbeVue Skript dann einige Stunden laufen lassen, bis es dann wieder zu einem Core-File von Perl kam. Die Datei /tmp/wait_for_segv enthielt ca 23.000 Zeilen! Wir haben hier nur die relevanten Zeilen aufgelistet:

# cat /tmp/wait_for_segv
…
8651210: ksh called execve(xxxx_hacheck.pl) with arguments: xxxx_hacheck.pl -c
8651210: ksh called execve(/var/opt/OV/bin/instrumentation/xxxx_hacheck.pl) with arguments: xxxx_hacheck
.pl -c
20054518: ksh called execve(/bin/proc2mon.pl) with arguments: proc2mon.pl
…
8651210:  perl

     PID              CMD
       1              init
                        |
                        V
9634196              ovcd
                        |
                        V
9765232              opcacta
                        |
                        V
8651210              perl    <=======
…

Man sieht das Perl über das Programm opcacta gestartet wurde, welches selbst von ovcd gestartet wurde. Diese Prozesse gehören zu HP OpenView das hier im Einsatz ist. Weiter oben in der Ausgabe kann man sehen das das Perl-Skript /var/opt/OV/bin/instrumentation/xxxx_hacheck.pl gestartet wurde. Damit haben wir das Skript gefunden das die vielen Core-Files erzeugt.

Das Skript wurde erst kürzlich geschrieben und muß offensichtlich noch einmal untersucht und überarbeitet werden.

Mit Hilfe von ProbeVue hat ein kurzes Skript und einige Stunden Warten ausgereicht um die Ursache des Problems zu finden! ProbeVue ist aber nicht nur bei der Untersuchung von Problemen nützlich; auch beim Performance Monitoring erweist sich ProbeVue als extrem hilfreich.

 

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.