7.5.2. Zuordnen von virtuellen Target-Devices (Mapping)

Damit in der Client-LPAR auf Storage über einen virtuellen SCSI-Client Adapter zugegriffen werden kann, muß auf dem Virtual-I/O-Server erst einmal dem zugehörigen virtuellen SCSI-Server Adapter Storage zugeordnet werden (VSCSI-Mapping). In diesem Kapitel geht es um das Mapping von Platten und Logical Volumes, die Möglichkeit auch Dateien zuzuordnen werden später separat im Kapitel 8 (Virtual-I/O-Server) betrachtet.

Welche virtuellen SCSI-Server Adapter es auf einem Virtual-I/O-Server gibt, lässt sich mit dem Kommando „vios lsvscsi“ (list VSCSI) anzeigen:

$ vios lsvscsi ms03-vio1
SVSA    SLOT  CLIENT    LUNS
vhost0  C33   aix22(5)  0
$

Das Kommando zeigt alle virtuellen SCSI-Server Adapter zusammen mit der virtuellen Slot-Nummer des Adapters und dem Namen der zugehörigen Client-LPAR an. In der Spalte LUNS wird die Anzahl der zugewiesenen virtuellen Target-Devices angegeben. Der Geräte-Name der virtuellen SCSI-Server Adapter auf den Virtual-I/O-Servern ist vhost mit einer fortlaufenden Nummer.

Neben dem vhost-Adapter auf welchen ein Gerät gemappt werden soll, benötigt man noch ein verfügbares Gerät das zugeordnet werden soll (Platte oder Logical Volume). Welche Platten auf einem Virtual-I/O-Server verfügbar sind, kann mit dem Kommando „vios lspv“ (list physical volumes) angezeigt werden:

$ vios lspv ms03-vio1
PVNAME  PVID              VGNAME  PVSTATE
hdisk0  00dead00beef0003  None    -
hdisk1  00dead00beef0005  rootvg  active
hdisk2  00dead00beef0008  rootvg  active
hdisk3  00dead00beef000e  None    -
hdisk4  00dead00beef0001  None    -
$

Neben den beiden Platten hdisk1 und hdisk2 der rootvg gibt es noch 3 weitere Platten, welche aktuell nicht in Benutzung sind. Wir verwenden als Beispiel für ein VSCSI-Mapping die freie hdisk0.

Hinweis: Bei Platten, welche auf vhost-Adapter gemappt werden sollen, sollte das Platten-Attribut reserve_policy auf no_reserve gesetzt werden. Dies lässt sich mit dem Kommando „vios chdev“ durchführen:

$ vios chdev ms03-vio1 hdisk0 reserve_policy=no_reserve
$ vios chdev ms03-vio1 hdisk3 reserve_policy=no_reserve
$ vios chdev ms03-vio1 hdisk4 reserve_policy=no_reserve
$

Wird eine externe Platte (LUN) über mehr als einen Virtual-I/O-Server gemappt, ist dies zwingend erforderlich, da ansonsten der erste Virtual-I/O-Server die Platte reserviert und die weiteren Virtual-I/O-Server dann nicht auf die Platte zugreifen können.

Das Mapping kann mit dem Kommando „vios map“ (map SCSI target device) durchgeführt werden. Dabei muß mindestens das zu mappende Gerät und der vhost-Adapter angegeben werden:

$ vios map ms03-vio1 hdisk0 vhost0
$

Das VSCSI-Mapping erzeugt ein Kind-Gerät des virtuellen SCSI-Server Adapter vhost0. Das Kind-Gerät hat per Default den Namen vtscsi mit einer fortlaufenden eindeutigen Nummer. Bild 7.15 zeigt die Platten als Kind-Geräte des SAS-Adapters sas0 bzw. des FC Protokoll-Geräts fscsi4 und das virtuelle Target-Gerät vtscsi0 als Kind-Gerät des virtuellen SCSI-Server Adapters vhost0. Die Zuordnung zur Platte hdisk0 als sogenanntes Backing-Device erfolgt dabei über das Attribut aix_tdev von vtscsi0, welches auf die Platte hdisk0 verweist.

Mapping of hdisk0 to the adapter vhost0
Bild 7.15: Mapping von hdisk0 auf den Adapter vhost0

Auf die gleiche Weise können weitere Geräte dem Adapter vhost0 und damit dem zugehörigen virtuellen SCSI-Client Adapter hinzugefügt werden. Eine kurze Überprüfung der virtuellen SCSI-Server Adapter zeigt das nun eine LUN dem Adapter vhost0 zugeordnet ist:

$ vios lsvscsi ms03-vio1
SVSA    SLOT  CLIENT    LUNS
vhost0  C33   aix22(5)  1
$

Natürlich lassen sich die zugeordneten LUNs auch anzeigen. Dazu muß man lediglich als weiteres Argument einen der vhost-Adapter angeben:

$ vios lsvscsi ms03-vio1 vhost0
VTD      STATUS     BACKING  BDPHYSLOC  MIRRORED  LUN
vtscsi0  Available  hdisk0   -          N/A       0x8100000000000000
$

Beim Mapping wird also ein neues virtuelles Gerät (vtscsi0) als Kind des virtuellen SCSI-Server Adapter vhost0 erzeugt:

$ vios lsdev ms03-vio1 vtscsi0
NAME     STATUS     PHYSLOC                      PARENT  DESCRIPTION
vtscsi0  Available  U9009.22A.8991971-V1-C33-L1  vhost0  Virtual Target Device - Disk
$

Das Gerät besitzt die folgenden Attribute:

$ vios lsattr ms03-vio1 vtscsi0
ATTRIBUTE        VALUE               DESCRIPTION                          USER_SETTABLE
LogicalUnitAddr  0x8100000000000000  Logical Unit Address                 False
aix_tdev         hdisk0              Target Device Name                   False
allow520blocks   yes                 Allow 520-byte blocks, if supported  False
client_reserve   no                  Client Reserve                       True
mig_name                             N/A                                  True
mirrored         false               Metro/Global Mirror                  True
$

Beim Erzeugen des Geräts mit dem Kommando „vios map“ wird das Attribut aix_tdev auf das angegebene Ziel des Mappings gesetzt (hier hdisk0). Das Attribut kann nach dem Erzeugen nicht mehr geändert werden.

Damit die „neue“ Platte auf dem Client verfügbar ist, muß unter AIX der Config-Manager cfgmgr gestartet werden:

aix22 # cfgmgr -l vscsi0 -v
----------------
Attempting to configure device 'vscsi0'
Time: 0 LEDS: 0x25b3
Invoking /usr/lib/methods/cfg_vclient -l vscsi0
Number of running methods: 1
----------------
Completed method for: vscsi0, Elapsed time = 0
Return code = 0
***** stdout *****
hdisk9
*** no stderr ****
----------------
Time: 0 LEDS: 0x539
Number of running methods: 0
----------------
Attempting to configure device 'hdisk9'
Time: 0 LEDS: 0x25b4
Invoking /etc/methods/cfgscsidisk -l hdisk9
Number of running methods: 1
----------------
Completed method for: hdisk9, Elapsed time = 1
Return code = 0

aix22 #

(Über die Option „-l vscsi0“ wurde der Config-Manager angewiesen den Geräte-Teilbaum ab dem Gerät vscsi0 neu zu scannen.)

In der Ausgabe von cfgmgr ist zu sehen, das die Platte hdisk9 erkannt worden ist. Die Platte ist vom Typ „Virtual SCSI Disk Drive“:

aix22 # lscfg -l hdisk9
  hdisk9           U9009.22A.8991971-V5-C11-T1-L8100000000000000  Virtual SCSI Disk Drive
aix22 #

Über den Physical Location Code lässt sich auch die Zuordnung zum entsprechenden virtuellen Target Device auf dem Virtual-I/O-Server herstellen. Der Teil „V5-C11-T1“ ist der virtuelle Slot 11 der LPAR, dort wurde der virtuelle SCSI-Client Adapter angelegt. Der hintere Teil „L8100000000000000“ gibt die LUN-ID an, das ist der Wert des Attributs LogicalUnitAddr des virtuellen Target Devices vtscsi0 auf dem Virtual-I/O-Server.

Device trees on virtual I/O server and client LPAR and the I/O path.
Bild 7.16: Gerätebaum auf Virtual-/O-Server und Client-LPAR und I/O-Pfad.

Das Bild 7.16 zeigt den für VSCSI relevanten Teil der Gerätebäume auf Virtual-I/O-Server und Client-LPAR. Zusätzlich ist auch der I/O-Pfad beim Zugriff auf eine VSCSI-LUN (hdisk9) auf der Client-LPAR eingezeichnet.

Der Default Name vtscsi0 für das virtuelle Target Device gibt keinen Hinweis welchem Client dieses zugeordnet ist. Bei ein paar hundert VSCSI-Mappings kann es von Vorteil sein einem virtuellen Target Device einen beschreibenden Namen zu geben, der darauf hinweist zu welchem Client das Gerät gehört und eventuell auch welchem Gerät (hdisk) dieses auf dem Client entspricht. Beim Mappen mit „vios map“ kann optional ein Gerätename für das virtuelle Target Device angegeben werden. Im folgenden Beispiel wird das Logical Volume lv00 dem virtuellen SCSI-Server Adapter vhost0 zugeordnet, wobei dem erzeugten virtuellen Target Device der Name aix22_hd01 gegeben wird:

$ vios map ms03-vio1 lv00 vhost0 aix22_hd01
$

Das Logical Volume muß vor dem Mapping schon existieren, es wird durch das Mapping nicht angelegt! Der Client-LPAR aix22 sind jetzt 2 Geräte zugeordnet:

$ vios lsvscsi ms03-vio1 vhost0
VTD         STATUS     BACKING  BDPHYSLOC  MIRRORED  LUN
aix22_hd01  Available  lv00     -          N/A       0x8200000000000000
vtscsi0     Available  hdisk0   -          N/A       0x8100000000000000
$

Auf der AIX LPAR ist ein weiterer Lauf des Config-Managers notwendig, damit AIX das neue Gerät erkennt.

Hinweis: Sollen Logical Volumes oder Dateien als Backing-Devices (Ziel des virtuellen Target Devices) zugeordnet werden, dann geht dies um einiges komfortabler über die Verwendung von Storage-Pools. Diese werden in einem eigenen Unterkapitel in Kapitel 8 ausführlich besprochen.