25. April 2008

Migration virtualisierten Massespeichers

Inhalt

Einleitung
Was soll migriert werden?
Neue Storage verfügbar machen
Virtualisierung der neuen Storage
Kopieren der Daten auf der LPAR
Entfernen der alten Storage

1. Einleitung

Eine der großen Errungenschaften von IBMs power5-Architektur war die Hardwarevirtualisierung. Damit wurde praktisch jede Beschränkung der Zahl der logischer Partitionen pro p5-System aufgehoben.

Ein Nachteil aber ist, dass man nun leicht die Übersicht verlieren kann über die Verteilung der physikalischen Ressourcen auf die verschiedenen LPARs - dies gilt insbesondere für Massespeicher.

Das Szenario

Unser Beispielszenario besteht aus zwei Virtual-I/O-Servern (im Folgenden kurz VIOS oder VIO-Server genannt) und einer Anzahl vollständig virtualisierter logischer AIX-Partitionen, von denen wir beispielhaft nur eine betrachten werden (im Folgenden kurz LPAR genannt). Vollständig virtualisiert heißt, dass unsere LPAR über keinerlei dedizierte Adapter verfügt. Dies ist ein durchaus typisches Szenario. Mit nur einem VIOS würde man sich einen Single Point of Failure einhandeln, denn der Wegfall eines VIOS würde sämtliche LPARs ihrer I/O-Ressourcen berauben.

Massespeicher wird über ein SAN (Serial Atached Network) zur Verfügung gestellt. Die Aufgabe ist nun, Daten unserer LPARs auf neue Speicher-Hardware, also von Storage-Box 1 auf Storage-Box 2 zu migrieren.

Die SAN-Platten (Im Folgenden kurz LUNs) werden von den VIO-Servern direkt (ohne den Umweg über LVs) an die LPARs weitergegeben. Dabei sehen beide VIO-Server die gleichen Platten und geben sie als virtuelles SCSI-Device an die LPAR weiter, die LPAR hat dann zwei Pfade zur gleichen hdisk

Notationen

Da wir auf zwei verschiedenen VIO-Servern und auf unserer LPAR und auch noch unter verschiedenen Benutzern arbeiten werden, ein paar Notationen für die Befehlsfenster:

Einzugebene Befehle und ihre Ausgabe werden in hellgrauen Boxen dargestellt (unser Befehlsfenster). Darin wird alles, das der Benutzer eingibt, in schwarzen fett gedruckten Buchstaben dargestellt, die Befehlsausgaben dagegen in normaldicker Schrift. Der Prompt wird in blau dargestellt.

Wird der Befehl auf der LPAR eingegeben, zeigt der Prompt:

LPAR#

Wird der Befehl auf dem ersten VIOS als Benutzer padmin eingegeben dagegen zeigt der Prompt

VIOS1$

für den zweiten VIOS entsprechend

VIOS2$

oder

VIOS1+2$

falls derselbe Befehl auf beiden VIO-Servern nacheinander ausgeführt werden soll.

Wird ein Befehl exemplarisch für (irgend)einen VIO-Server gezeigt, fällt die Nummer weg und wir erhalten als Prompt:

VIOS$

Muss ein Befehl dagegen auf den VIO-Servern dagegen als root eingegeben werden (nach Eingabe von oem_setup_env als Benutzer padmin), enden die Prompts mit einer Raute statt dem Dollarzeichen:

VIOS1#
VIOS2#
VIOS1+2#
VIOS#

Wann immer ein kursiv geschriebenes Wort in den grauen Boxen auftaucht, muss dieses in der Realität durch einen Namen ersetzt werden.

Beispiel:

VIOS1# rmdev -dl vtscsi11
vtscsi11 deleted

Dies bedeutet: Sie geben auf dem ersten VIOS den Befehl rmdev -dl vtscsi11 ein, als Ausgabe erhalten Sie dann:
vtscsi11 deleted

Tip: Wenn Sie nicht immer zwischen den Benutzern root und padmin wechseln wollen können sie einfach immer als root arbeiten (nach Eingabe von oem_setup_env) und einen kleinen Alias setzen:
VIOS# alias i=/usr/ios/cli/ioscli
Nun lassen sich alle VIO-Befehle unter root mit einem vorangestellten i nutzen, also etwa
VIOS# i lsmap -all

2. Was soll migiert werden?

Zunächst sollten wir uns darüber klar werden, welche LUNs wir eigentlich migrieren wollen. Sagen wir, alle Daten in einer Volume Group ora01_vg sollen migriert werden, dann finden wir zunächst einmal die Mitglieder dieser VG:

LPAR# lspv | grep ora01_vg 
hdisk5          00c776905b11c503                    ora01_vg active
hdisk6          00c776905b11db8c                    ora01_vg active
hdisk9          00c776905b11dbd6                    ora01_vg active
hdisk14         00c776905b11e22a                    ora01_vg active

Mit dem Befehl bootinfo verschaffen wir uns einen Überblick über die Größe der LUNs:

LPAR# bootinfo -s hdisk5
5120
LPAR# bootinfo -s hdisk6
5120
LPAR# bootinfo -s hdisk9
32768
LPAR# bootinfo -s hdisk14
12288

Wir benötigen nun also Storage von mindestens 54 GB, um unsere Daten migrieren zu können. Wir wollen auch ein bisschen konsolidieren und entscheiden uns daher auf zwei neue 32GB LUNs zu migrieren.

3. Neue Storage verfügbar machen

Was auf Seiten der Speicherhardware und der SAN-Switches gemacht werden muss, damit wir letztendlich auf die Storage zugreifen können, geht über diesen Artikel (und letztendlich auch über den Kenntnisstand des Autors hinaus). In größeren IT-Umgebungen wird für Storage generell ein eigenes Team zuständig sein und als AIX-Administrator wird man neue LUNs über den einen oder anderen Weg dort beantragen.

Allerdings ein paar Angaben müssen wir natürlich machen, damit das Storageteam uns LUNs zuweisen kann. Neben der Größe, die wir bereits auf 2x32GB beziffert haben, auch die sogenannten WorldWideNumbers (WWN) der FiberChannel-Adapter, die auf die LUNs zugreifen sollen.

Die LPAR selbst hat ausschließch virtuelle Ressourcen - wir benötigen also die WWNs der VIO-Server! Beide VIO-Server haben typischerweise zwei FibreChannel-Adapter im SAN. Die WWN findet sich dann wie folgt:

VIOS$ oem_setup_env
VIOS# lscfg -vl fcs0
  fcs0             U7879.001.DQD142M-P1-C1-T1  FC Adapter

        Part Number.................03N5014
        EC Level....................A
        Serial Number...............1F7410C0AE
        Manufacturer................001F
        Device Specific.(CC)........280D
        FRU Number.................. 03N5014
        Device Specific.(ZM)........3
        Network Address.............10000000C96B68AD
        ROS Level and ID............02C82138
        Device Specific.(Z0)........1036406D
        Device Specific.(Z1)........00000000
        Device Specific.(Z2)........00000000
        Device Specific.(Z3)........03000909
        Device Specific.(Z4)........FFC01159
        Device Specific.(Z5)........02C82138
        Device Specific.(Z6)........06C32138
        Device Specific.(Z7)........07C32138
        Device Specific.(Z8)........20000000C96B68AD
        Device Specific.(Z9)........BS2.10X8 
        Device Specific.(ZA)........B1D2.10X8 
        Device Specific.(ZB)........B2D2.10X8 
        Device Specific.(YL)........U7879.001.DQD142M-P1-C1-T1

Die WWNs der FiberChannel-Adapter der beiden VIO-Server ermitteln wir dann beispielsweise so:

VIOS1$ oem_setup_env
VIOS1# lsdev | grep -w fcs. | while read fc rest ; do lscfg -vl $fc; done | grep Network
        Network Address.............10000000C96B68AD
        Network Address.............10000000C96BD4DC

und

VIOS2$ oem_setup_env
VIOS2# lsdev | grep -w fcs. | while read fc rest ; do lscfg -vl $fc; done | grep Network
        Network Address.............10000000C96AF273
        Network Address.............10000000C96AF694

Mit diesen Informationen beantragen wir dann die Storage von der neuen Hardware. Sobald das Storageteam seine Sache getan hat, können wir weitermachen mit der

4. Virtualisierung der neuen Storage

Es ist äußerst wichtig, die folgenden Schritte sequentiell durchzuführen! Arbeiten Sie nicht parallel auf den beiden VIO-Servern, sonst bekommen Sie Probleme mit der no_reverse_policy und den PVIDs!

Auf dem ersten VIO prüfen wir zunächst nach, ob wir die neue Storage tatsächlich sehen:

VIOS1$ lspv
NAME            PVID                                VG              STATUS
hdisk0          00c776a02c87830f                    rootvg          active
hdisk1          00c776a08510a5fa                    rootvg          active
hdisk2          00c776a03073e369                    None
hdisk3          00c776a0313ab36e                    None
hdisk4          none                                None
hdisk5          none                                None
hdisk6          none                                None
hdisk7          00c776905b11c503                    None
hdisk8          00c776905b11db8c                    None
hdisk9          00cb230dd4074c95                    None
hdisk10         none                                None
hdisk11         00c776905b11dbd6                    None
hdisk13         00cb230dd40753c2                    None
hdisk14         00c77690abfb76b2                    None
hdisk16         00c77690abf283db                    None
hdisk17         00c77690abfb64a4                    None
hdisk18         00c776905b11e22a                    None
hdisk19         00c77690abfb7669                    None
hdisk20         00c77690abf2841d                    None
hdisk21         00c77690abfb645d                    None
VIOS1$ cfgdev
VIOS1$ lspv
NAME            PVID                                VG              STATUS
hdisk0          00c776a02c87830f                    rootvg          active
hdisk1          00c776a08510a5fa                    rootvg          active
hdisk2          00c776a03073e369                    None
hdisk3          00c776a0313ab36e                    None
hdisk4          none                                None
hdisk5          none                                None
hdisk6          none                                None
hdisk7          00c776905b11c503                    None
hdisk8          00c776905b11db8c                    None
hdisk9          00cb230dd4074c95                    None
hdisk10         none                                None
hdisk11         00c776905b11dbd6                    None
hdisk13         00cb230dd40753c2                    None
hdisk14         00c77690abfb76b2                    None
hdisk16         00c77690abf283db                    None
hdisk17         00c77690abfb64a4                    None
hdisk18         00c776905b11e22a                    None
hdisk19         00c77690abfb7669                    None
hdisk20         00c77690abf2841d                    None
hdisk21         00c77690abfb645d                    None
hdisk22         none                                None
hdisk23         none                                None

Wir sehen unsere neue Storage also als hdisk22 und hdisk23.

Zur einfacheren Identifizierung später einmal, vergeben wir bereits auf dem ersten VIOS eine PVID für die neuen hdisks. Darüberhinaus sichern wir mit der no_reserve_policy, dass beide VIO-Server auf die LUNs zugreifen können.

Noch immer auf dem ersten VIOS:

VIOS1$ for pv in hdisk22 hdisk23; do
> chdev -dev $pv -attr pv=yes
> chdev -dev $pv -attr reserve_policy=no_reserve
> chdev -dev $pv -attr reserve_policy=no_reserve -perm
> done
VIOS1$ lspv | egrep '(hdisk22|hdisk23)
hdisk22         0009428a3e777a24                    None
hdisk23         0009428a54e24fd2                    None

Auf dem zweiten VIOS machen wir es nach, überspringen aber die Zuweisung einer PVID, da diese bereits vom ersten vergeben wurde.

VIOS2$ lspv | tail -5
hdisk17         00c77690abfb64a4                    None
hdisk18         00c776905b11e22a                    None
hdisk19         00c77690abfb7669                    None
hdisk20         00c77690abf2841d                    None
hdisk21         00c77690abfb645d                    None
VIOS2$ cfgdev
VIOS2$ lspv | tail -5
hdisk19         00c77690abfb7669                    None
hdisk20         00c77690abf2841d                    None
hdisk21         00c77690abfb645d                    None
hdisk22         0009428a3e777a24                    None
hdisk23         0009428a54e24fd2                    None
VIOS2$ for pv in hdisk22 hdisk23 ; do
> chdev -dev $pv -attr reserve_policy=no_reserve
> chdev -dev $pv -attr reserve_policy=no_reserve -perm
> done

Wir sehen die neuen hdisks also auch auf dem zweiten VIOS mit denselben PVIDs und denselben Nummern (22 und 23). Gut. So sollte es sein, wenn die beiden VIOS sauber gewartet werden! Es ist aber sehr wohl möglich, dass die Nummerierung nicht übereinstimmt. Die PVID stimmt aber natürlich überein.

Von der LPAR besorgen wir uns die Slot-Nummer unseres virtuellen SCSI-Hostadapters:

LPAR# lscfg -l vscsi0
vscsi0           U9117.570.65D830D-V11-C102-T1  Virtual SCSI Client Adapter
LPAR# lscfg -l vscsi1
vscsi1           U9117.570.65D830D-V11-C202-T1  Virtual SCSI Client Adapter

Wir sollten den ersten Slot auf einem VIOS und den zweiten dann auf dem anderen VIOS wiederfinden:

VIOS1$ lsmap -all | grep -E '(102|202)'
vhost1          U9117.570.65D830D-V11-C102                    0x0000000b

VIOS2$ lsmap -all | grep -E '(102|202)'
vhost1          U9117.570.65D830D-V11-C202                    0x0000000b

Wir erkennen, dass auf beiden VIO-Servern der virtuelle SCSI-Clientadapter vhost1 ist. Auch hier gilt wieder, dass bei gut aufgebauten und gewarteten VIOS die vhost-Nummern übereinstimmen sollten - dies muss aber nicht sein, also Achtung!

Nun können wir endlich die neuen LUNs mit den virtuellen Clientadaptern verbinden^¹:

VIOS1+2$ mkvdev -vdev hdisk22 -vadapter vhost1
vtscsi19 available
VIOS1+2$ mkvdev -vdev hdisk23 -vadapter vhost1
vtscsi20 available

Zurück auf unserer LPAR, starten wir den Konfigurationsmanager und erhalten zwei neue Platten:

LPAR# cfgmgr
LPAR# lspv|grep None
hdisk15         0009428a3e777a24                    None
hdisk16         0009428a54e24fd2                    None
LPAR# bootinfo -s hdisk15
32768
LPAR# bootinfo -s hdisk16
32768

5. Kopieren der Daten auf der LPAR

Die neuen hdisks werden zur Volume Group hinzugefügt:

LPAR# extendvg ora01_vg hdisk15 hdisk16

Dann können wir einen Spiegel über die neue Storage aufbauen. Wir warten mit der Synchronisierung zunächst (mirrorg -s)

LPAR# mirrorvg -s ora01_vg hdisk15 hdisk16

Alle Warnhinweise bezüglich Quorum können ignoriert werden, schließlich werden wir den Spiegel wieder aufbrechen.

Über Nacht können wir die Volume Group synchronisieren, indem wir das entsprechende varyonvg über das at-Kommando zu einer bestimmten Zeit (z.B. um 2:00 Uhr) ausführen lassen:

LPAR# echo varyonvg ora01_vg | at 2:00

Am nächsten Morgen sollte die ora01_vg dann synchronisiert sein und wir können die alte Storage - also hdisk5, hdisk6, hdisk9 und hdisk14 - aus der Volume Group herausnehmen:

LPAR# unmirrorvg ora01_vg hdisk5 hdisk6 hdisk9 hdisk14
LPAR# reducevg ora01_vg hdisk5 hdisk6 hdisk9 hdisk14

Die Daten sind jetzt auf die neue Storagebox migriert, alle Warnungen bezüglich Quorum können ignoriert werden.

6. Entfernen der alten Storage

Das endgültige Entfernen der alten Storage ist naturgemäß der gefährlichste Teil der Migration, da er nicht reversibel ist. Zunächst stellen wir sicher, dass wir auf dem VIOS wirklich nur die vtscsi-Devices löschen, die zur alten Storage gehören. Dazu finden wir zunächst auf der LPAR Slot-IDs und LUN IDs:

LPAR# lscfg -l vscsi0
vscsi0           U9117.570.65D830D-V11-C102-T1  Virtual SCSI Client Adapter
LPAR# lscfg -l vscsi1
vscsi1           U9117.570.65D830D-V11-C202-T1  Virtual SCSI Client Adapter
LPAR# HLIST=$(lspv|grep None^¹|awk '{print $1;}')
LPAR# for h in $HLIST; do lscfg -l $h ; done
  hdisk7           U9117.570.65D830D-V11-C102-T1-L820000000000  Virtual SCSI Disk Drive
  hdisk8           U9117.570.65D830D-V11-C102-T1-L830000000000  Virtual SCSI Disk Drive
  hdisk11          U9117.570.65D830D-V11-C102-T1-L8a0000000000  Virtual SCSI Disk Drive
  hdisk18          U9117.570.65D830D-V11-C102-T1-L8e0000000000  Virtual SCSI Disk Drive

¹ mit grep None finden wir die Platten, die keiner Volumegroup zugeordnet sind

Nun müssen wir auf dem VIOS nur noch den dazugehörigen vhost finden. Dabei ist äußerste Vorsicht angesagt, denn die LUN IDs (0x8200000000000000 etc) wiederholen sich für jeden vhost!

Achtung: Hier war ein Fehler in der ersten Version dieses Artikels! Die besagten LUN-IDs können sich auf den beiden VIO-Servern unterscheiden! Der Location Code im obigen Listing zeigt uns aber an, dass die LUN-IDs vom ersten VIO-Server kommen (Slot C102). Dort können wir die Platte identifizieren (über datapath query oder powermt display oder ähnliche Tools anderer Hersteller).

Die Verbindung zwischen vhost und LPAR ist die Slot-ID (-C102- bzw. -C202- in der obigen lscfg-Ausgabe). Mit diese Information suchen wir auf dem VIOS unseren vhost:

VIOS$ lsmap -all | grep -E '(102|202)'
vhost1          U9117.570.65D830D-V11-C202                    0x0000000b

Die LUNs, die an diesem vhost hängen, finden wir dann mit wieder mit lsmap:

VIOS$ lsmap -vadapter vhost1
SVSA            Physloc                                      Client Partition ID
--------------- -------------------------------------------- ------------------
vhost1          U9117.570.65D830D-V11-C102                    0x0000000b

VTD                   vtscsi1
LUN                   0x8100000000000000
Backing device        hdisk3
Physloc               U7879.001.DQD142M-P1-C1-T1-W50050763041882AA-L40AB400200000000

VTD                   vtscsi4
LUN                   0x8200000000000000
Backing device        hdisk7
Physloc               U7879.001.DQD142M-P1-C1-T1-W500507630E800DF5-L4011400100000000

VTD                   vtscsi5
LUN                   0x8300000000000000
Backing device        hdisk8
Physloc               U7879.001.DQD142M-P1-C1-T1-W500507630E800DF5-L4012400100000000

VTD                   vtscsi8
LUN                   0x8a00000000000000
Backing device        hdisk11
Physloc               U7879.001.DQD142M-P1-C1-T1-W500507630E800DF5-L4013400100000000

VTD                   vtscsi14
LUN                   0x8b00000000000000
Backing device        hdisk17
Physloc               U7879.001.DQD142M-P1-C1-T1-W50050763041882AA-L40AB400200000000

VTD                   vtscsi15
LUN                   0x8e00000000000000
Backing device        hdisk18
Physloc               U7879.001.DQD142M-P1-C1-T1-W500507630E800DF5-L4010400100000000

(Auschnitt)

Nun löschen wir die entsprechenden vtscsi-Devices, dies sind:

LUN 0x8200000000000000 = vtscsi4
LUN 0x8300000000000000 = vtscsi5
LUN 0x8a00000000000000 = vtscsi8
LUN 0x8e00000000000000 = vtscsi15

VIOS1$ oem_setup_env
VIOS1# rmdev -dl vtscsi4
vtscsi4 deleted
VIOS1# rmdev -dl vtscsi5
vtscsi5 deleted
VIOS1# rmdev -dl vtscsi8
vtscsi8 deleted
VIOS1# rmdev -dl vtscsi15
vtscsi15 deleted

Die Backend-Devices (hdisk7, hdisk8, hdisk11, hdisk18) lassen wir zunächst noch stehen.

Diese Schritte werden auf dem zweiten VIOS wiederholt.

Wie bereits eingangs erwähnt, können sich die virtuellen LUN-IDs zwischen den beiden VIO-Servern unterscheiden. Dies ist mit den gerätetreiberspezifischen Kommandos zu überprüfen!

Das Storage-Team benötigt die LUN-IDs, um sie aus dem Zoning zu entfernen und auf der Storage-Box wieder verfügbar zu machen. Diese Informationen findet sich in der lscfg-Ausgabe unter den gerätespezifischen Angaben Z1...Z6 und ist abhängig von der verwendeten Storage-Hardware¹. Das folgende Beispiel gilt für DS6000-Storage.

Diese LUN-IDs sind auch der einzig wirklich eindeutige Link zur gleichen Platte auf den beiden VIO-Servern. Die virtuelle LUN-ID (0x8...) kann sich theoretisch auch zwischen den VIO-Servern unterscheiden. Dies geschieht, wenn Platten auf den VIO-Servern in unterschiedlicher Reihenfolge an einen vhost gebunden werden.

Ein kleines Skript hilft uns bei der Identifizierung der richtigen LUNs:

oem_setup_env
DISKS=$(lsdev -Cc disk | grep MPIO^¹ | awk '{print $1}')

clear ; \
print " Disk    |Size    |ID      |LUN|Used" ; \
for DISK in $DISKS
do
  SIZE=$(getconf DISK_SIZE /dev/${DISK} 2> /dev/null)
  ID=$(lscfg -l ${DISK} -vps | grep "Serial Number" | sed -e 's/\./ /g' | awk '{print $3}')
  LUN=$(lscfg -l ${DISK} -vps | grep "(Z1)" | sed -e 's/\./ /g' | awk '{print $4}')
  USED=$(/usr/ios/cli/ioscli lsmap -all | grep -i Backing | grep -w ${DISK})

  [ -z "${SIZE}" ] && SIZE="NOT VALID"
  [ -z "${USED}" ] && USED="No" || USED="Yes"

  printf " %-8s|%8s|%s|%s|%s\n" "${DISK}" "${SIZE}" "${ID}" "${LUN}" "${USED}"
done
exit

¹im Falle von MPIO (Multipath-I/O). Andere Beispiele sind PowerPath für EMC²-Symmetrix oder vpath, falls IBMs sdd-Treiber benutzt werden.

Das Skript müssen wir nur auf einem der beiden VIO-Servern ausführen, die LUNs sind schließlich dieselben, aber wir müssen die WWNs beider VIO-Server aufschreiben, damit das Storage-Team die Zuweisungen löschen kann...

Das Skript schreibt folgende Ausgabe:

Disk    |Size    |ID      |LUN|Used
hdisk2  |   20480|75BHDZ10|A01|Yes
hdisk3  |  138240|75BHDZ10|B00|Yes
hdisk4  |   81920|75BHDZ10|C01|Yes
hdisk5  |   81920|75BHDZ10|D01|Yes
hdisk6  |   81920|75BHDZ11|002|Yes
hdisk7  |    5120|75BHDZ11|B02|No
hdisk8  |    5120|75BHDZ11|C01|No
hdisk9  |    4096|75BHDZ1E|001|Yes
hdisk10 |    4096|75BHDZ1E|005|Yes
hdisk11 |   32768|75BHDZ1E|006|No
hdisk13 |   32768|75BHDZ1E|007|Yes
hdisk14 |   32768|75BHDZ1E|102|Yes
hdisk16 |    5120|75BHDZ1E|1FF|Yes
hdisk17 |    5120|75BHDZ1E|200|Yes
hdisk18 |   12288|75BHDZ1E|205|No
hdisk19 |   32768|68808431|400|Yes
hdisk20 |   32768|68808431|500|Yes
hdisk21 |   32768|68808431|600|Yes
hdisk22 |   32768|68808432|A00|Yes
hdisk23 |   32768|68808432|B00|Yes

Wir sehen unter ID und LUN die wesentlichen Informationen. Die letzte Spalte zeigt uns noch einmal, ob ein virtuelles vtscsi-Device über der entsprechenden hdisk besteht. Unsere zu löschenden LUNs sind natürlich frei und wir sehen 'No'.

Auf beiden VIO-Servern können nun auch die Backend-Devices gelöscht werden:

VIOS1$ oem_setup_env
VIOS1# rmdev -dl hdisk7
hdisk7 deleted
VIOS1# rmdev -dl hdisk8
hdisk8 deleted
VIOS1# rmdev -dl hdisk11
hdisk11 deleted
VIOS1# rmdev -dl hdisk18
hdisk18 deleted

Das gleiche auf VIOS2. Bei guter Pflege der VIO-Server sollten die Backend-Devices die gleichen sein, das muss aber durchaus nicht sein!

Geschafft! Die Daten sind migriert.

¹ zur Ermittlung der LUN-ID lassen sich auch die entsprechenden treiberspezifischen Kommandos nutzen, wie das datapath query der sdd-Treiber oder das powermt display der EMC²-Treiber.

² Die vtscsi-Devices werden einfach hochgezählt. Um den VIOS übersichtlicher zu halten, kann für vtscsiXX auch ein Name gesetzt werden, der z.B. das Backend-Device und den Hostnamen der LPAR enthält:
# mkvdev -vdev hdisk22 -dev vthdisk22_barney -vadapter vhost1
vthdisk22_barney available