In unserem Download-Bereich ist ab sofort ein PDF zu PowerVM verfügbar (ca 260 Seiten, mit ca 75 Abbildungen):
Virtualisierung mit PowerVM: Praktische Einführung
Home of the LPAR-Tool
In unserem Download-Bereich ist ab sofort ein PDF zu PowerVM verfügbar (ca 260 Seiten, mit ca 75 Abbildungen):
Virtualisierung mit PowerVM: Praktische Einführung
Das Kommando „oslevel –s“ zeigt den höchsten vollständig installierten Service-Pack auf einem AIX-System an, z.B.:
$ oslevel -s 7100-05-05-1939 $
Es kann aber ohne weiteres ein höherer Service-Pack installiert sein (allerdings nicht vollständig). Am einfachsten lässt sich das mit „oslevel –qs“ überprüfen:
$ oslevel -qs Known Service Packs ------------------- 7100-05-06-2028 7100-05-06-2016 7100-05-06-2015 7100-05-05-1939 7100-05-05-1938 7100-05-05-1937 7100-05-04-1914 7100-05-04-1913 7100-05-03-1846 7100-05-03-1838 … $
Die Ausgabe zeigt das 7100-05-06-2028 installiert ist. Allerdings gibt es Filesets die nicht auf den Stand von 7100-05-06-2028 aktualisiert wurden, weshalb eine niedrigere Version bei „oslevel –s“ angezeigt wird.
Möchte man wissen welche Filesets einen niedrigeren Stand als 7100-05-06-2028 haben, kann „oslevel –s –l“ verwendet werden:
$ oslevel -s -l 7100-05-06-2028 Fileset Actual Level Service Pack Level ----------------------------------------------------------------------------- openssl.base 1.0.2.1801 1.0.2.2002 openssl.license 1.0.2.1801 1.0.2.2002 openssl.man.en_US 1.0.2.1801 1.0.2.2002 $
Die OpenSSL Filesets sind also noch in einer älteren Version (1.0.2.1801) installiert und müssten auf 1.0.2.2002 aktualisiert werden, damit der Service-Pack 7100-05-06-2028 vollständig installiert ist.
Mit dem LPAR-Tool lassen sich jederzeit Statistiken für alle virtuellen FC Clients mit dem Kommando „vios fcstat“ anzeigen. Damit lässt sich jederzeit feststellen welche Client LPARs gerade welchen I/O-Durchsatz haben (bei Verwendung von NPIV).
Welche NPIV fähigen FC-Adapter es auf einem Virtual-I/O-Server gibt, lässt sich leicht mit „vios lsnports“ herausfinden:
$ vios lsnports ms15-vio1 NAME PHYSLOC FABRIC TPORTS APORTS SWWPNS AWWPNS fcs0 U78CB.001.XXXXXXX-P1-C5-T1 1 64 62 2032 2012 fcs1 U78CB.001.XXXXXXX-P1-C5-T2 1 64 62 2032 2012 fcs2 U78CB.001.XXXXXXX-P1-C5-T3 1 64 61 2032 1979 fcs3 U78CB.001.XXXXXXX-P1-C5-T4 1 64 61 2032 1979 fcs4 U78CB.001.XXXXXXX-P1-C3-T1 1 64 50 3088 3000 fcs5 U78CB.001.XXXXXXX-P1-C3-T2 1 64 63 3088 3077 $
Wir lassen uns die FC Client Statistiken mit dem Kommando „vios fcstat“ anzeigen, dabei werden per Default alle 10 Sekunden die Daten für alle virtuellen FC Clients des angegebenen Virtual-I/O-Servers, ausgegeben:
$ vios fcstat ms15-vio1 HOSTNAME PHYSDEV WWPN DEV INREQS INBYTES OUTREQS OUTBYTES CTRLREQS ms15-vio1 fcs1 0x210000XXXXX56EC5 fcs1 774.75/s 129.51 MB/s 1332.71/s 92.96 MB/s 20 aixtsmp1 fcs2 0xC050760XXXXX0058 fcs6 318.10/s 83.39 MB/s 481.34/s 126.18 MB/s 0 ms15-vio1 fcs2 0x210000XXXXX56EC6 fcs2 318.10/s 83.39 MB/s 480.78/s 126.03 MB/s 0 aixtsmp1 fcs5 0xC050760XXXXX003E fcs0 583.98/s 60.35 MB/s 1835.17/s 124.86 MB/s 0 ms15-vio1 fcs5 0x10000090XXXXX12D fcs5 583.70/s 60.27 MB/s 1836.21/s 124.92 MB/s 0 ms15-vio1 fcs0 0x21000024XXXXXEC4 fcs0 923.19/s 165.08 MB/s 1032.81/s 17.25 MB/s 46 aixtsmp3 fcs1 0xC050760XXXXX00E4 fcs0 775.12/s 129.48 MB/s 1047.32/s 17.15 MB/s 20 aixtsmp3 fcs0 0xC050760XXXXX00DE fcs1 775.78/s 128.99 MB/s 1037.99/s 17.39 MB/s 20 aixtsmp1 fcs1 0xC050760XXXXX0056 fcs5 0.00/s 0.00 B/s 290.39/s 76.12 MB/s 0 aixtsmp1 fcs0 0xC050760XXXXX0052 fcs4 142.89/s 36.12 MB/s 0.00/s 0.00 B/s 26 ms15-vio1 fcs4 0x10000090XXXXX12C fcs4 234.97/s 4.58 MB/s 621.78/s 11.12 MB/s 40 cus1dbp01 fcs4 0xC050760XXXXX0047 fcs0 243.55/s 5.05 MB/s 432.33/s 9.95 MB/s 0 cus1dbi01 fcs4 0xC050760XXXXX0044 fcs1 0.94/s 10.42 KB/s 87.28/s 459.26 KB/s 0 ... HOSTNAME PHYSDEV WWPN DEV INREQS INBYTES OUTREQS OUTBYTES CTRLREQS aixtsmp1 fcs5 0xC050760XXXXX003E fcs0 1772.84/s 162.24 MB/s 1309.30/s 70.60 MB/s 68 ms15-vio1 fcs5 0x10000090XXXXX12D fcs5 1769.13/s 161.95 MB/s 1305.60/s 70.54 MB/s 68 ms15-vio1 fcs1 0x21000024XXXXXEC5 fcs1 883.55/s 118.97 MB/s 1551.97/s 108.78 MB/s 43 ms15-vio1 fcs2 0x21000024XXXXXEC6 fcs2 201.09/s 52.72 MB/s 497.26/s 130.35 MB/s 0 aixtsmp1 fcs2 0xC050760XXXXX0058 fcs6 201.09/s 52.72 MB/s 495.40/s 129.87 MB/s 0 ms15-vio1 fcs0 0x21000024XXXXXEC4 fcs0 923.54/s 128.89 MB/s 1234.98/s 23.31 MB/s 65 aixtsmp3 fcs0 0xC050760XXXXX00DE fcs1 876.93/s 118.93 MB/s 1234.98/s 23.32 MB/s 44 aixtsmp3 fcs1 0xC050760XXXXX00E4 fcs0 884.17/s 119.07 MB/s 1223.50/s 23.00 MB/s 43 aixtsmp1 fcs1 0xC050760XXXXX0056 fcs5 0.00/s 0.00 B/s 325.83/s 85.41 MB/s 0 ... ^C $
Ausgegeben werden der LPAR-Name, der physikalische FC-Port (PHYSDEV) auf dem Virtual-I/O-Server, die WWPN des Client Adapters, der virtuelle FC-Port (DEV), sowie die Anzahl Requests (INREQS und OUTREQS) und dabei transferierte Bytes (INBYTES und OUTBYTES). Die Transfer-Raten werden dabei jeweils in KB/s, MB/s oder GB/s ausgegeben. Auf größeren Systemen kann die Ausgabe sehr lang werden! Die Ausgabe wird ist nach Durchsatz sortiert, d.h. die aktivsten virtuellen Clients Adapter werden als erstes ausgegeben. Über die Option ‚-t‚ (Top) kann die Ausgabe auf eine gewünschte Zahl von Datensätzen eingeschränkt werden: z.B. werden mit ‚-t 10‚ nur die 10 Adapter mit dem höchsten Durchsatz ausgegeben. Zusätzlich kann über ein weiteres Argument auch die Intervall Länge (in Sekunden) angegeben werden, hier ein kurzes Beispiel:
$ vios fcstat -t 10 ms15-vio1 2 HOSTNAME PHYSDEV WWPN DEV INREQS INBYTES OUTREQS OUTBYTES CTRLREQS ms15-vio1 fcs1 0x21000024XXXXXEC5 fcs1 1034.58/s 86.56 MB/s 2052.23/s 160.11 MB/s 20 ms15-vio1 fcs5 0x10000090XXXXX12D fcs5 1532.63/s 115.60 MB/s 1235.72/s 118.32 MB/s 40 aixtsmp1 fcs5 0xC050760XXXXX003E fcs0 1510.33/s 114.88 MB/s 1236.49/s 118.27 MB/s 40 aixtsmp3 fcs1 0xC050760XXXXX00E4 fcs0 1036.11/s 86.67 MB/s 1612.25/s 44.86 MB/s 20 aixtsmp3 fcs0 0xC050760XXXXX00DE fcs1 1031.50/s 86.29 MB/s 1588.02/s 44.27 MB/s 20 ms15-vio1 fcs0 0x21000024XXXXXEC4 fcs0 1029.58/s 86.31 MB/s 1567.63/s 43.65 MB/s 20 aixtsmp1 fcs1 0xC050760XXXXX0056 fcs5 0.00/s 0.00 B/s 436.52/s 114.43 MB/s 0 ms15-vio1 fcs2 0x21000024XXXXXEC6 fcs2 0.00/s 0.00 B/s 435.75/s 114.23 MB/s 0 aixtsmp1 fcs2 0xC050760XXXXX0058 fcs6 0.00/s 0.00 B/s 432.68/s 113.42 MB/s 0 ms15-vio1 fcs4 0x10000090XXXXX12C fcs4 144.99/s 0.78 MB/s 478.83/s 2.22 MB/s 46 HOSTNAME PHYSDEV WWPN DEV INREQS INBYTES OUTREQS OUTBYTES CTRLREQS aixtsmp1 fcs5 0xC050760XXXXX003E fcs0 758.14/s 35.55 MB/s 1822.99/s 112.60 MB/s 0 ms15-vio1 fcs5 0x10000090XXXXX12D fcs5 757.38/s 35.52 MB/s 1821.46/s 112.59 MB/s 0 ms15-vio1 fcs0 0x21000024XXXXXEC4 fcs0 944.23/s 85.09 MB/s 1657.58/s 41.40 MB/s 2 aixtsmp3 fcs0 0xC050760XXXXX00DE fcs1 943.47/s 85.15 MB/s 1636.90/s 40.68 MB/s 2 ms15-vio1 fcs1 0x21000024XXXXXEC5 fcs1 949.21/s 84.88 MB/s 1586.74/s 39.41 MB/s 2 aixtsmp3 fcs1 0xC050760XXXXX00E4 fcs0 946.53/s 84.64 MB/s 1584.83/s 39.40 MB/s 2 ms15-vio1 fcs4 0x10000090XXXXX12C fcs4 39.44/s 449.92 KB/s 676.97/s 3.63 MB/s 10 cus1dbp01 fcs4 0xC050760XXXXX0047 fcs0 29.10/s 471.69 KB/s 310.92/s 1.28 MB/s 4 cus1mqp01 fcs4 0xC050760XXXXX002C fcs0 1.91/s 4.71 KB/s 230.12/s 1.66 MB/s 0 cus2orap01 fcs4 0xC050760XXXXX000F fcs0 0.77/s 4.31 KB/s 48.25/s 263.49 KB/s 0 ^C $
Über die Option ‚-s‚ (Select) können auch nur Datensätze eines bestimmten Clients (‚-s hostname=aixtsmp1‚) oder nur Datensätze eines bestimmten physikalischen Ports (‚-s physdev=fcs1‚) ausgewählt und ausgegeben werden:
$ vios fcstat -s hostname=aixtsmp1 ms15-vio1 2 HOSTNAME PHYSDEV WWPN DEV INREQS INBYTES OUTREQS OUTBYTES CTRLREQS aixtsmp1 fcs5 0xC050760XXXXX003E fcs0 1858.72/s 51.14 MB/s 1231.82/s 104.20 MB/s 0 aixtsmp1 fcs2 0xC050760XXXXX0058 fcs6 6.94/s 1.82 MB/s 6.94/s 1.82 MB/s 0 aixtsmp1 fcs4 0xC050760XXXXX0042 fcs2 0.39/s 1.19 KB/s 0.39/s 395.05 B/s 0 aixtsmp1 fcs1 0xC050760XXXXX0056 fcs5 0.39/s 7.72 B/s 0.00/s 0.00 B/s 1 aixtsmp1 fcs0 0xC050760XXXXX0052 fcs4 0.00/s 0.00 B/s 0.00/s 0.00 B/s 0 aixtsmp1 fcs3 0xC050760XXXXX005A fcs7 0.00/s 0.00 B/s 0.00/s 0.00 B/s 0 HOSTNAME PHYSDEV WWPN DEV INREQS INBYTES OUTREQS OUTBYTES CTRLREQS aixtsmp1 fcs5 0xC050760XXXXX003E fcs0 1760.48/s 111.48 MB/s 1125.70/s 95.20 MB/s 0 aixtsmp1 fcs2 0xC050760XXXXX0058 fcs6 8.53/s 2.24 MB/s 484.61/s 127.04 MB/s 0 aixtsmp1 fcs1 0xC050760XXXXX0056 fcs5 0.00/s 0.00 B/s 469.04/s 122.96 MB/s 0 aixtsmp1 fcs4 0xC050760XXXXX0042 fcs2 0.37/s 1.14 KB/s 0.00/s 0.00 B/s 0 aixtsmp1 fcs0 0xC050760XXXXX0052 fcs4 0.00/s 0.00 B/s 0.00/s 0.00 B/s 0 aixtsmp1 fcs3 0xC050760XXXXX005A fcs7 0.00/s 0.00 B/s 0.00/s 0.00 B/s 0 ^C $
Mit dem „vios fcstat“ Kommando lassen sich auf extrem einfache Weise jederzeit FC-Durchsatz von beliebigen LPARs, sozusagen auf Knopfdruck, ausgeben.
Bei kleineren Intervallen leidet die Genauigkeit der angezeigten Werte. Bei 2 Sekunden Intervallen beträgt die Ungenauigkeit ca 10%. Die Relationen zwischen den angezeigten Werten ist allerdings korrekt.
Wir hatten kürzlich einen kleineren Ausfall auf einem unserer Systeme. Benutzer konnten sich nicht mehr einloggen und Benutzer konnten eine Web-GUI nicht mehr benutzen. Das Problem trat sporadisch immer mal wieder auf und verschwand dann wieder. Während dieser Zeiten fanden sich im Syslog jede Menge Meldungen der folgenden Art:
Mar 4 07:56:05 aix01 daemon:err|error secldapclntd: LDAP failed to bind to server aixldapp11. Mar 4 07:56:05 aix01 daemon:err|error secldapclntd: LDAP failed to bind to server aixldapp12. Mar 4 07:56:10 aix01 daemon:err|error secldapclntd: LDAP failed to bind to server aixldapp11. Mar 4 07:56:10 aix01 daemon:err|error secldapclntd: LDAP failed to bind to server aixldapp12. ...
Diese Meldungen deuteten daraufhin, das beide LDAP-Server zeitweise nicht erreichbar waren. Untersuchungen der Logs auf den beiden LDAP-Servern ergaben aber keine Verbindungsversuche, die zurückgewiesen worden sind. Und auch eine Untersuchung der Firewall-Logs ergab das die Firewall hier keine Pakete zu den LDAP-Servern geblockt hat.
Wir haben daraufhin einen Case bei IBM eröffnet und bekamen auch prompt Anweisungen für das Aufsetzen eines speziellen LDAP-Tracings zurück. Allerdings ist das Problem dann nicht mehr aufgetreten, und somit konnte durch das Tracing auch die Ursache nicht ermittelt werden.
Das betreffende System ist über das Internet erreichbar und daher wurde die Anzahl der ephemeral Ports aus Sicherheitsgründen eingeschränkt. Nur etwa 1500 ephemeral Ports sind über die Firewall erlaubt und auf AIX konfiguriert (tcp_ephemeral_high und tcp_ephemeral_low). Wir haben auf einem Test-System dann nachgestellt was passiert wenn die verfügbaren ephemeral Ports ausgeschöpft sind. Es kam dann sofort zu den obigen Meldungen, sobald der LDAP-Client eine neue Verbindung aufmachen möchte.
Eine Ursache für die LDAP Client Fehlermeldung „LDAP failed to bind to server“ kann also auch die Nichtverfügbarkeit von ephemeral Ports sein!
Ab AIX 7.2 TL4 bzw. VIOS 3.1.1.10 gibt es für physikalische FC-Adapter das neue Attribut „label“. Dieses Attribut kann vom Administrator auf eine beliebige Zeichenkette (maximal 255 Zeichen) gesetzt werden. Auch wenn das Attribut nur informativen Character hat, kann es in PowerVM Virtualisierungsumgebungen äußerst nützlich sein. Hat man eine größere Anzahl von Managed Systems, ist nicht immer klar erkennbar an welche FC-Fabric ein bestimmter FC-Port angebunden ist. Das lässt sich natürlich in der Dokumentation der eigenen Systeme nachschauen, ist aber doch mit einem gewissen Aufwand verbunden. Einfacher ist es, wenn man diese Information direkt mit den FC-Adaptern verknüpft, was das neue Attribut „label“ auf einfache Weise erlaubt. Unter AIX:
# chdev -l fcs0 -U -a label="Fabric_1" fcs0 changed # lsattr -El fcs0 -a label -F value Fabric_1 #
Auf Virtual-I/O-Servern kann das Attribut auch über den padmin-Account gesetzt werden:
/home/padmin> chdev -dev fcs1 -attr label="Fabric_2" -perm fcs1 changed /home/padmin> lsdev -dev fcs1 -attr label value Fabric_2 /home/padmin>
Das Attribut ist auch für ältere FC-Adapter definiert.
Bei konsequenter Verwendung des Attributes „label“ kann man jederzeit für jeden FC-Adapter online feststellen, an welche Fabric der Adapter angebunden ist. Dazu muß lediglich einmal für jeden FC-Adapter diese Information hinterlegt werden.
(Hinweis: Für AIX 7.1 wurde das Attribut „label“ nicht implementiert, zumindest nicht bis 7.1 TL5 SP6.)
In Teil III unserer Artikel-Reihe „AIX LVM: Mechanik von migratepv“ zeigen wir wie inkorrekte Spiegelung von Logical Volumes online korrigiert werden kann. Dazu sind lediglich die Kommandos migratelp und migratepv, sowie ein gutes Verständnis der Arbeitsweise dieser Kommandos notwendig.
Hier die Links zu den Artikeln der Reihe:
AIX LVM: Mechanik von migratepv (Part I)
Beim Versuch die System Firmware eines Managed Systems über die HMC Command Line zu aktualisieren, sind wir auf die folgende Fehlermeldung gestoßen:
hmc01:~> updlic -o a -t all -l latest -m ms26 -r sftp -h X.X.X.X -u XXXXXXXX --passwd XXXXXXXX -d /firmware/system/01VL940_071_027 HSCF0180E Operation failed for ms26 (9009-22A*XXXXXXX). Could not unpack the firmware update package. Check the health and available disk space of the file system. hmc01:~>
Die angezeigte Fehlermeldung legte nahe den verfügbaren Platz in den HMC Dateisystemen zu überprüfen:
hmc01:~> lshmcfs filesystem=/var,filesystem_size=7935,filesystem_avail=4955,temp_files_start_time=11/22/2018 12:59:00,temp_files_size=2011 filesystem=/dump,filesystem_size=60347,filesystem_avail=55935,temp_files_start_time=02/15/2021 10:21:00,temp_files_size=0 filesystem=/extra,filesystem_size=20030,filesystem_avail=15939,temp_files_start_time=none,temp_files_size=0 filesystem=/,filesystem_size=15615,filesystem_avail=4369,temp_files_start_time=02/15/2021 06:05:00,temp_files_size=4 hmc01:~>
Eigentlich sollte der verfügbare Platz ausreichend sein, aber um ganz sicher zu gehen, haben wir bei den temporären Dateien etwas aufgeräumt:
hmc01:~> chhmcfs -o f -d 5 hmc01:~>
Das Kommando updlic zeigte sich aber dadurch unbeeindruckt und lieferte die gleiche Fehlermeldung.
Auch das Entfernen einiger alter Firmware Versionen aus der lokalen Disk Repository der HMC brachte keinen Erfolg:
hmc01:~> updlic -o p --ecnumber 01AL740 hmc01:~> updlic -o p --ecnumber 01AL770 hmc01:~> updlic -o p --ecnumber 01AM740 hmc01:~>
Die Fehlermeldung war nach wie vor die gleiche. Offensichtlich hatte das Problem, entgegen dem Hinweis aus der Fehlermeldung, nichts mit dem verfügbaren Platz auf der HMC zu tun!
Daraufhin haben wir uns die heruntergeladene Firmware noch einmal genauer angeschaut. Die Firmware hatten wir als ISO-Datei H75557812_01VL940_071_027.iso von der IBM Website heruntergeladen und dann mit dem Kommando loopmount auf unserem NIM-Server gemountet:
aixnim:/root> loopmount -i /tmp/H75557812_01VL940_071_027.iso -o "-o ro -V cdrfs" -m /mnt aixnim:/root> ls -l /mnt total 528296 -rw-r--r-- 1 102010979 213 1860 Feb 04 09:08 01VL940071_special_instructs.xml.special.note.xml -rw-r----- 1 102010979 210 7290 Feb 04 09:08 01VL940_071_027.dd.xml -rw-r--r-- 1 102010979 213 95687 Feb 04 09:07 01VL940_071_027.html -rw-r----- 1 102010979 210 2971 Feb 04 09:08 01VL940_071_027.pd.sdd -rw-r----- 1 102010979 210 67338 Feb 04 09:08 01VL940_071_027.readme.txt -rw-r----- 1 102010979 210 134969022 Feb 04 09:08 01VL940_071_027.rpm -rw-r----- 1 102010979 210 135328848 Feb 04 09:08 01VL940_071_027.tar.gz -rw-r----- 1 102010979 210 9442 Feb 04 09:08 01VL940_071_027.xml aixnim:/root>
Was uns beim Kopieren der Dateien nicht aufgefallen war, waren die fehlenden Lese-Berechtigungen bei other für die meisten Dateien.
Nachdem wir für alle Dateien Leseberechtigungen vergeben hatten, war der nächste Update-Versuch erfolgreich:
hmc01:~> updlic -o a -t all -l latest -m ms26 -r sftp -h X.X.X.X -u XXXXXX --passwd XXXXXXXX -d /firmware/system/01VL940_071_027 HSCF0179W Operation was partially successful for ms26 (9009-22A*XXXXXXX). The following deferred fixes are present in the fix pack. Deferred fixes will be activated after the next IPL of the system. An immediate IPL is not required, unless you want to activate one of the fixes below now. .. hmc01:~>
Ab sofort ist unser LPAR-Tool in der Version 1.6.0.0 in unserem Download-Bereich verfügbar!
Neue Feature sind:
Im Artikel Überwachung des SEA Netzwerk-Verkehrs werden die Möglichkeiten SEA Client Statistiken abzurufen gezeigt.