Die Auswirkungen von FC-Ports ohne Link

FC-Ports die nicht verwendet werden und keinen Link haben, sollten deaktiviert werden, da diese die Laufzeit einer Reihe von Kommandos und Operationen (z.B. LPM) deutlich verlängern.

(Hinweis: in einigen Beispielen wird unser LPAR-Tool verwendet, es werden aber auch immer die Kommandos auf der HMC, oder dem Virtual-I/O-Server gezeigt!)

Auf einem unserer Virtual-I/O-Server (ms26-vio1) sind 2 4-Port FC Adapter in Verwendung:

$ lpar lsslot ms26-vio1
DRC_NAME                  DRC_INDEX  IOPOOL  DESCRIPTION
U78D3.001.XXXXXXX-P1-C49  21040015   none    PCIe3 x8 SAS RAID Internal Adapter 6Gb
U78D3.001.XXXXXXX-P1-C7   2103001C   none    PCIe3 4-Port 16Gb FC Adapter
U78D3.001.XXXXXXX-P1-C2   21010021   none    PCIe3 4-Port 16Gb FC Adapter
$
(HMC: lshwres -r io --rsubtype slot -m ms26 --filter lpar_names=ms26-vio1)

Es sind allerdings nur 2 Ports verkabelt:

$ vios lsnports ms26-vio1
NAME  PHYSLOC                     FABRIC  TPORTS  APORTS  SWWPNS  AWWPNS
fcs0  U78D3.001.XXXXXXX-P1-C2-T1  1       64      64      3072    3072
fcs4  U78D3.001.XXXXXXX-P1-C7-T1  1       64      64      3072    3072
$
(VIOS: lsnports)

Beim Arbeiten mit dem Virtual-I/O-Server fällt auf, das einige der Kommandos eine unerwartet lange Laufzeit haben und teilweise für längere Zeit hängen. Im Folgenden sind einige Kommandos angegeben, zusammen mit der benötigten Laufzeit:

(0)padmin@ms26-vio1:/home/padmin> time netstat –cdlistats
…
Error opening device: /dev/fscsi1
errno: 00000045

Error opening device: /dev/fscsi2
errno: 00000045

Error opening device: /dev/fscsi3
errno: 00000045

Error opening device: /dev/fscsi5
errno: 00000045

Error opening device: /dev/fscsi6
errno: 00000045

Error opening device: /dev/fscsi7
errno: 00000045

real    1m13.56s
user    0m0.03s
sys     0m0.10s
(0)padmin@ms26-vio1:/home/padmin>
(0)padmin@ms26-vio1:/home/padmin> time lsnports
name             physloc                        fabric tports aports swwpns  awwpns
fcs0             U78D3.001.XXXXXXX-P1-C2-T1          1     64     64   3072    3072
fcs4             U78D3.001.XXXXXXX-P1-C7-T1          1     64     64   3072    3072

real    0m11.61s
user    0m0.01s
sys     0m0.00s
(0)padmin@ms26-vio1:/home/padmin>
(0)padmin@ms26-vio1:/home/padmin> time fcstat fcs1

Error opening device: /dev/fscsi1
errno: 00000045

real    0m11.31s
user    0m0.01s
sys     0m0.01s
(4)padmin@ms26-vio1:/home/padmin>

Auch LPM-Operationen dauern deutlich länger, da bei der Suche nach passenden FC-Ports für die nötigen NPIV-Mappings alle FC-Ports untersucht werden. Dies kann zu Verzögerungen im Minuten-Bereich führen, bevor die Migration dann letztlich gestartet wird.

Um diese unnötig langen Laufzeiten zu vermeiden, sollten nicht verkabelte FC-Ports nicht aktiviert werden. Das fscsi-Device besitzt das Attribut autoconfig mit den möglichen Werten defined und available. Per Default wird der Wert available verwendet, was dazu führt das der Kernel das Device konfiguriert und aktiviert, auch wenn es keinen Link besitzt, was zu den oben gezeigten Wartezeiten führt. Setzt man das Attribut autoconfig auf defined, dann wird das fscsi-Device nicht aktiviert, es bleibt dann im Zustand defined.

Im folgenden Beispiel wird gezeigt, wie man das Device fscsi1 umkonfiguriert:

$ vios chdev ms26-vio1 fscsi1 autoconfig=defined
$
(VIOS: chdev -dev fscsi1 -attr autoconfig=defined)
$
$ vios rmdev ms26-vio1 fscsi1
$
(VIOS: rmdev -dev fscsi1 –ucfg)
$
$ vios lsdev ms26-vio1 fscsi1
NAME    STATUS   PHYSLOC                     PARENT  DESCRIPTION
fscsi1  Defined  U78D3.001.XXXXXXX-P1-C2-T2  fcs1    FC SCSI I/O Controller Protocol Device
$
(VIOS: lsdev -dev fscsi1)
$
$  vios lsattr ms26-vio1 fscsi1
ATTRIBUTE     VALUE      DESCRIPTION                            USER_SETTABLE
attach        none       How this adapter is CONNECTED          False
autoconfig    defined    Configuration State                    True
dyntrk        yes        Dynamic Tracking of FC Devices         True+
fc_err_recov  fast_fail  FC Fabric Event Error RECOVERY Policy  True+
scsi_id       Adapter    SCSI ID                                False
sw_fc_class   3          FC Class for Fabric                    True
$
(VIOS: lsdev -dev fscsi1 –attr)
$

Durch das Attribut autoconfig=defined bleibt das fscsi-Device auch bei einem Lauf des cfgmgr auf defined!

Wiederholt man die Laufzeit-Messung der Kommandos oben, sieht man das die Laufzeit der Kommandos sich schon meßbar verbessert hat:

(0)padmin@ms26-vio1:/home/padmin> time netstat –cdlistats
…
Error opening device: /dev/fscsi1
errno: 00000005

Error opening device: /dev/fscsi2
errno: 00000045

Error opening device: /dev/fscsi3
errno: 00000045

Error opening device: /dev/fscsi5
errno: 00000045

Error opening device: /dev/fscsi6
errno: 00000045

Error opening device: /dev/fscsi7
errno: 00000045

real    1m1.02s
user    0m0.04s
sys     0m0.10s
(0)padmin@ms26-vio1:/home/padmin>
(0)padmin@ms26-vio1:/home/padmin> time lsnports
name             physloc                        fabric tports aports swwpns  awwpns
fcs0             U78D3.001.XXXXXXX-P1-C2-T1          1     64     64   3072    3072
fcs4             U78D3.001.XXXXXXX-P1-C7-T1          1     64     64   3072    3072

real    0m9.70s
user    0m0.00s
sys     0m0.01s
(0)padmin@ms26-vio1:/home/padmin>
(0)padmin@ms26-vio1:/home/padmin> time fcstat fcs1

Error opening device: /dev/fscsi1
errno: 00000005

real    0m0.00s
user    0m0.02s
sys     0m0.00s
(4)padmin@ms26-vio1:/home/padmin>

Die Laufzeit des netstat-Kommandos hat sich um 12 Sekunden verkürzt, das Komnando lsnports war ca 2 Sekunden schneller.

Wir setzen das autoconfig Attribut jetzt auch bei allen anderen unbenutzten FC-Ports auf defined:

$ for fscsi in fscsi2 fscsi3 fscsi5 fscsi6 fscsi7
> do
> vios chdev ms26-vio1 $fscsi autoconfig=defined
> vios rmdev ms26-vio1 $fscsi
> done
$

Jetzt wiederholen wir die Laufzeit-Messung der Kommandos erneut:

(0)padmin@ms26-vio1:/home/padmin> time netstat –cdlistats
…
Error opening device: /dev/fscsi1
errno: 00000005

Error opening device: /dev/fscsi2
errno: 00000005

Error opening device: /dev/fscsi3
errno: 00000005

Error opening device: /dev/fscsi5
errno: 00000005

Error opening device: /dev/fscsi6
errno: 00000005

Error opening device: /dev/fscsi7
errno: 00000005

real    0m0.81s
user    0m0.03s
sys     0m0.10s
(0)padmin@ms26-vio1:/home/padmin>
(0)padmin@ms26-vio1:/home/padmin> time lsnports         
name             physloc                        fabric tports aports swwpns  awwpns
fcs0             U78D3.001.XXXXXXX-P1-C2-T1          1     64     64   3072    3072
fcs4             U78D3.001.XXXXXXX-P1-C7-T1          1     64     64   3072    3072

real    0m0.00s
user    0m0.01s
sys     0m0.01s
(0)padmin@ms26-vio1:/home/padmin> time fcstat fcs1       

Error opening device: /dev/fscsi1
errno: 00000005

real    0m0.04s
user    0m0.00s
sys     0m0.00s
(4)padmin@ms26-vio1:/home/padmin>

Das Kommando netstat benötigt nun weniger als 1 Sekunde, das Kommando lsnports nur noch 0.1 Sekunden.

Es lohnt sich also das autoconfig Attribut für nicht-benutzte FC-Ports auf defined zu setzen!

 

HSCLB505 The partition cannot use hardware-accelerated encryption

Beim Verschieben einer LPAR mit LPM auf eine ältere Hardware kann der folgende Fehler auftreten:

HSCLB505 The partition cannot use hardware-accelerated encryption on the destination managed system because the destination managed system does not support hardware-accelerated encryption.

Dies bedeutet das Hardware-beschleunigte Verschlüsselung für die LPAR aktiviert ist, jedoch auf dem Ziel Managed System
nicht unterstützt ist.

Die Hardware-beschleunigte Verschlüsselung lässt sich mit dem LPAR-Tool ganz leicht ausschalten:

$ lpar -d chmem lpar01 hardware_mem_encryption=0
$

Ohne LPAR-Tool geht das natürlich auch, z.B. von der HMC-Kommandozeile:

chhwres -m ms01 -r mem -o s -p lpar01 -a 'hardware_mem_encryption=0'

Danach sollte die Validierung und Verschiebung mittels LPM funktionieren.

HSCLB504 The migrating partition cannot use hardware-accelerated Active Memory Expansion

Beim Verschieben einer LPAR mit LPM auf eine ältere Hardware kann der folgende Fehler auftreten:

HSCLB504 The migrating partition cannot use hardware-accelerated Active Memory Expansion on the destination managed system because the destination managed system does not support hardware-accelerated Active Memory Expansion.

Dies bedeutet das Hardware-beschleunigte aktive Memory Erweiterung (AME) für die LPAR aktiviert ist, jedoch auf dem Ziel
Managed System nicht unterstützt ist .

Die Hardware-beschleunigte aktive Memory Erweiterun lässt s ich mit dem LPAR-Tool ganz leicht ausschalten:

$ lpar -d chmem lpar01 hardware_mem_expansion=0
$

Ohne LPAR-Tool geht das natürlich auch, z.B. von der HMC-Kommandozeile:

chhwres -m ms01 -r mem -o s -p lpar01 -a 'hardware_mem_expansion=0'

Danach sollte die Validierung und Verschiebung mittels LPM funktionieren.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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!