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.

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.

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.
Du muss angemeldet sein, um einen Kommentar zu veröffentlichen.