VMAX, PowerMax: Migracja niewpływająca na pracę użytkowników platformy hosta IBMi

Środowisko wsparcia:
Program NDM dla IBMi jest dostępny dla obsługiwanych systemów hostów IBMi, które są podłączone do macierzy VMAX lub PowerMax z systemem PowerMaxOS w wersji 5978.444.444 lub nowszej.

Dotyczy to partycji logicznych IBMi (LPAR) działających na platformie IBM Power Server Power6 lub nowszej i z systemem operacyjnym IBMi w wersji i6.1.1 lub nowszej. Ogólna macierz zgodności VMAX lub PowerMax e-Lab zawiera szczegółowe informacje i listę obsługiwanych kart we/wy IBMi (IOA) protokołu Fibre Channel (FC), czyli adapterów magistrali hosta (Host Bus Adapter, HBA). NDM jest również obsługiwany, gdy IBMi jest LPAR klienta z przypisanymi wirtualnymi zasobami we/wy z serwera wirtualnego we/wy IBM (VIOS). Dzięki funkcji IBM VIOS/VFC (NPIV) wirtualne adaptery FC (vFC) są przypisywane do LPAR klienta w celu nawiązania połączenia z macierzą pamięci masowej za pomocą obsługiwanych przełączników SAN.

vFC działają jako przekazywanie dla łączności dysku hosta; Z punktu widzenia hosta jest ona w pełni przezroczysta, a wszystkie funkcje macierzy pamięci masowej są dostępne również w konfiguracji zwirtualizowanej karty.

Scenariusz migracji w tle i wysokiego poziomu:
Rozwiązanie Symmetrix Remote Data Facility (SRDF) zostało opracowane na początku lat dziewięćdziesiątych XX wieku jako technologia replikacji do odtwarzania po awarii (DR) dla macierzy pamięci masowej Dell klasy enterprise. Jest on również używany od wielu lat do przeprowadzania migracji opartych na pamięci masowej z jednej macierzy do drugiej. Oznacza to podłączenie „symetryczne” starej i nowej macierzy oraz skopiowanie woluminów danych podczas odświeżania technologii poprzez wdrożenie nowej macierzy pamięci masowej. Mimo że proces kopiowania SRDF woluminów lub jednostek logicznych (LUN) jest niewidoczny dla podłączonych systemów hostów, tradycyjnie zawsze wymagał krótkiego okna "odcięcia" w trybie offline po zakończeniu procesu kopiowania z woluminów źródłowych (R1). Docelowe (nowe) woluminy (R2) były włączone do odczytu/zapisu, a połączenia FC systemów hostów były kierowane (przez podział na strefy i maskowanie SAN) do nowej macierzy. 

Rozwiązanie SRDF/Metro zostało wprowadzone wraz z rodziną macierzy pamięci masowej VMAX All Flash Storage. SRDF/Metro zapewnia rzeczywisty dostęp hosta aktywny/aktywny do woluminów źródłowych (R1) i docelowych (R2) z obu macierzy. Rozwiązanie SRDF/Metro współpracuje z obsługiwanymi sterownikami wielościeżkowymi hosta w celu uzyskania dostępu do dysków. Obejmuje to natywną ochronę IBMi Dynamic Multi Path (DMP) dla ścieżek dyskowych. Ochrona IBMi DMP automatycznie wykrywa, czy istnieje wiele ścieżek FC do tego samego urządzenia dyskowego. Zapewnia również podstawowy, ale skuteczny „algorytm karuzelowy” schematu równoważenia obciążenia w celu rozłożenia obciążenia roboczego we/wy dysku na dostępnych ścieżkach adaptera FC. Ochrona IBMi DMP zapewnia automatyczne awaryjne przełączanie ścieżek, gdy połączenia mogą ulec awarii, poprzez przekierowanie operacji we/wy dysku do jednej z pozostałych aktywnych ścieżek. Po przywróceniu nieudanych połączeń IBMi automatycznie odzyskuje te ścieżki i ponownie rozpoczyna wysyłanie we/wy dysku do tych ścieżek.

NDM z opcją METRO i precopy jest oparta na podstawowej technologii SRDF/Metro w celu zapewnienia jednoczesnego dostępu do starych i nowych urządzeń pamięci masowej.

Faza tworzenia:
Po utworzeniu pary urządzeń replikacji SRDF/Metro (R1>R2) ta sama tożsamość urządzenia R1 jest prezentowana z urządzenia R2 w macierzy docelowej. Zasadniczo ten sam seryjny identyfikator dysku i ta sama nazwa WWPN urządzenia są prezentowane z obu urządzeń. Początkowo nowe urządzenie R2 jest w stanie AA-NR/DEV-INACT (Active/Active-Not Ready/ Device Inactive). Po zsynchronizowaniu pary urządzeń R1>R2 można przejść w stan aktywny/aktywny, umożliwiając dostęp do odczytu i zapisu na woluminie R2.

Faza READY_TARGET:
Kiedy ścieżka z LPAR IBMi do urządzenia R2 jest już włączona (strefowanie SAN już działa i maskowanie nowej macierzy aktywowane komendą NDM readytgt), host IBMi wykrywa nowe ścieżki FC do istniejącego urządzenia dyskowego. W scenariuszu IBMi NDM prezentowane są aktywne/aktywne urządzenia R1 + R2.

Faza zatwierdzenia:
Po usunięciu dostępu do urządzeń R1 host IBMi traci dostęp do ścieżek starej macierzy, ale nadal działa na urządzeniach R2 przy użyciu ścieżek do nowej macierzy. Po wykonaniu tej czynności można usunąć podział na strefy SAN do starej macierzy. Należy uruchomić narzędzie "reset multipath" w systemie IBMi, aby zatrzymać korzystanie ze starych, nieaktywnych ścieżek, a także zatrzymać wszelkie komunikaty o błędach związane z tymi "brakującymi" ścieżkami. Trwałe usunięcie starych nieaktywnych ścieżek i powiązanych z nimi zasobów sprzętowych DMPxxx z bazy danych konfiguracji urządzeń hostów IBMi (repozytorium informacji o zarządzaniu pamięcią masową IBMi) może wymagać wstępnego załadowania programu (IPL), ale nie jest to obowiązkowy IPL, może również poczekać do następnego planowanego IPL. W celu usunięcia tych "przestarzałych" urządzeń: STRSST>Uruchom narzędzie>serwisowe Menedżer>usług sprzętowych Niepowodzenie i Sprzęt nie zgłasza: wybierz wszystkie stare zasoby dyskowe DMPxxx do usunięcia za pomocą opcji 4 i potwierdź to, naciskając Enter.

Uwagi dotyczące korzystania z Dell STM
Pamięć masowa PowerMax PowerMax, często nazywana również "zestawem narzędzi usług kopiowania pamięci masowej" do sterowania replikacją IBMi dla VMAX, działa jako natywna aplikacja na co najmniej jednym hoście IBMi. Może sterować zdalną replikacją dla obsługiwanych konfiguracji SRDF i lokalną replikacją migawek SnapVX w macierzach VMAX, PowerMax. STM występuje w dwóch smakach: Edycja Standard Features i Extended Features.

STM wykorzystuje komunikację wewnątrz-pasmową z macierzą pamięci masowej na ścieżkach FC, używa małych dedykowanych urządzeń, nazywanych również strażnikami wywołań systemowych. Gatekeeperami dla IBMi są specjalne małe urządzenia typu D910 GK, które pozostają w sekcji nieskonfigurowanych jednostek dyskowych. Ci strażnicy nie obsługują wielu ścieżek. Wiele jednościeżkowych gatekeeperów jest zwykle prezentowanych w tym samym nadmiarowym zestawie ścieżek, które są używane dla zwykłych dysków ASP1. Zaleca się użycie co najmniej czterech strażników. Strażnicy bram nie są częścią procesu migracji NDM, dlatego po migracji dostęp do strażników ze starej macierzy jest usuwany, a nowi strażnicy z nowej macierzy są prezentowani.

Cechy standardowe:
Jest to używane w systemach, które używają tylko konfiguracji pamięci masowej *SYSBAS. *SYSBAS oznacza systemowy ASP1 + wszelkie dodatkowe ASP użytkownika (ASP 2-32). STM jest zainstalowany tylko w węźle źródłowym i steruje parami replikacji dla wszystkich dysków w *SYSBAS jako jedna niepodzielna jednostka.  W przypadku wystąpienia zmian w konfiguracji dysku bazowego; czyli zmiany numeru seryjnego dysku spowodowane operacją "unspoofingu" NDM, wystarczy wykonać komendę STM DISCOVER na hoście źródłowym IBMi. Uruchom opcję DISCOVER po przedstawieniu gatekeeperów z nowej macierzy. Spowoduje to aktualizację lokalnej bazy danych symapi w zintegrowanym systemie plików (IFS) na hoście (location= /var/symapi/db). Ekrany STM odzwierciedlają teraz również nowe numery seryjne dysków. W przypadku zaobserwowania jakichkolwiek problemów podczas parowania urządzeń replikacji w STM możliwe jest również użycie opcji instalacji tylko w celu rozpoczęcia od nowej konfiguracji konfiguracji. Nie ma to wpływu na konfigurację parowania replikacji, która jest już skonfigurowana w macierzy pamięci masowej VMAX-PowerMax. Aby przeprowadzić czystą instalację/konfigurację tymczasową, najpierw udokumentuj powiązane ŚCIEŻKI i KROKI w bieżącej konfiguracji (PRZEJDŹ MAINCTL>1, IMAGES>wybierz opcję 2, dla obrazu> SYSTEMU utwórz zrzut ekranu dla ekranu PATHS zgodnie z poniższym przykładem:

Wyjdź z STM, usuń folder /var/symapi i jego podfoldery. Usuń bibliotekę EMCCTL. Uruchom STM i zainstaluj program ponownie. Uruchom polecenie CRTSYMAPI. GO MAINCTL, ponownie skojarz te same PATHS, które zostały skonfigurowane wcześniej. STM wykrywa teraz i wyświetla stan parowania aktywnej replikacji z macierzy pamięci masowej VMAX-PowerMax. Operacje STM są teraz gotowe do wznowienia.

Funkcje rozszerzone:
Jest to używane w przypadku systemów korzystających z konfiguracji klastra IBMi PowerHA z co najmniej jedną "przełączalną" substancją iASP (niezależną ASP). W tym scenariuszu replikowany jest tylko iASP i ten iASP lub jego repliki mogą być prezentowane węzłom w klastrze PowerHA. Każdy węzeł klastra jest już aktywny w swoim własnym systemie *SYSBAS (ASP1). Karta iASP jest skonfigurowana jako zasób przełączany w domenie udostępnionego urządzenia klastra. W klastrze znajdują się zazwyczaj dwa lub cztery węzły; zgodnie z poniższym przykładowym diagramem dla klastra 4-węzłowego z węzłem produkcyjnym jako źródłem oraz ze zdalnym węzłem docelowym DR i węzłem zapasowym SnapVX po obu stronach:

Do korzystania z iASP lub jego replik nie jest wymagany żaden IPL z żadnego węzła. Gdy dyski iASP są prezentowane w dowolnym węźle w klastrze, udostępnienie iASP dla tego węzła wymaga polecenia VARY ON. W przypadku konfiguracji PowerHA wersja źródłowa STM jest instalowana w węźle źródłowym (w bibliotece EMCCTL). We wszystkich pozostałych węzłach (replikach SRDF lub SnapVX) wersja docelowa jest instalowana (w bibliotece EMCCTLC). Ponieważ wszystkie węzły są aktywne, w STM wbudowane są zależności oraz mechanizmy kontroli i równowagi dla niektórych operacji w tej konfiguracji, co oznacza, że usunięcie dostępu do dysku dla węzła jest zabronione, jeśli iASP jest nadal w stanie VARY ON dla tego węzła. W przypadku komunikacji międzywęzłowej zadanie serwera STM jest uruchomione w podsystemie EMCCTL na wszystkich węzłach. To zadanie komunikuje się między węzłami na interfejsach IP klastra. Typowe operacje STM można uruchomić z dowolnego węzła w klastrze. Wymaga to udostępnienia zestawu tych samych dysków STM, adapterów i plików konfiguracji ścieżek w każdym węźle. Podczas wstępnej konfiguracji STM dla PowerHA, pliki te są konfigurowane przy użyciu opcji MAINCTL-16 z węzła źródłowego, co również propaguje te pliki do węzłów docelowych, którymi są pliki IASPS, ISRCIOA i IMAGE w bibliotekach instalacyjnych STM EMCCTL i EMCCTLC. Pliki te mogą być również wyświetlane, czyli za pomocą DSPPFM EMCCTL/IMAGE. Pliki zawierają informacje o dyskach i adapterach dysków używanych do konfiguracji iASP. Identyfikatory adapterów i numery seryjne dysków są przechowywane w tych plikach i używane w operacjach STM.

Rozważmy teraz wpływ zmiany numeru seryjnego dysku, która ma miejsce po zakończeniu operacji usuwania fałszowania NDM. Pliki konfiguracyjne STM nadal zawierają stare numery seryjne dysków. Większość operacji STM nie będzie już działać, dopóki te pliki konfiguracyjne nie zostaną zaktualizowane. Aktualizowanie i propagowanie tych plików można wykonać, wykonując ten sam proces, co podczas początkowej instalacji STM, gdy uruchomiona jest opcja MAINCTL-16>(konfiguracja iASP), gdy dyski iASP są udostępniane węzłom docelowym w odpowiednim PATH-STEP. Po zaktualizowaniu tych plików operacje STM iASP działają ponownie zgodnie z oczekiwaniami. Jeśli pojawią się jakiekolwiek problemy, rozważ ponowne uruchomienie tylko tymczasowej instalacji STM dla węzłów źródłowych i docelowych, w tym opcję 16 do konfiguracji ścieżek/STEP iASP i utworzenia lub rozpowszechnienia plików konfiguracyjnych STM.

Zarejestrowani użytkownicy z kontem pomocy technicznej firmy Dell mogą wyświetlić SRDF/TimeFinder Manager dla systemu IBM i w celu uzyskania dalszych istotnych informacji na temat tych edycji STM.

Zagadnienia dotyczące następnego IPL po zresetowaniu tożsamości urządzenia, czyli operacji
"unspoof"Operacja usuwania fałszerstw NDM zmienia numery seryjne dysków. Można to zrobić tylko wtedy, gdy LPAR IBMi nie działa. Jeśli ta operacja jest wykonywana po migracji w planowanym miejscu konserwacji w trybie offline, należy wziąć pod uwagę pewne kwestie. Aktywacja LPAR IBMi jest kontrolowana z poziomu konsoli IBM PowerServer Hardware Management Console (HMC), konsola HMC udostępnia funkcję Hypervisor dla wirtualizacji IBM PowerVM. W tej konsoli HMC każdy LPAR ma co najmniej jeden profil LPAR ze szczegółowymi informacjami na temat konfiguracji LPAR, czyli procesora/pamięci, adapterów itd. Gdy LPAR jest IPL (IPL = początkowe ładowanie programu = sekwencja rozruchu) po raz pierwszy, odczytuje szczegóły konfiguracji z wybranego profilu. Specjalna karta w profilu nazywa się "Oznaczone wejścia/wyjścia".  Oznaczone ustawienia we/wy określają, gdzie LPAR musi szukać źródła obciążenia (LS) (= dysku rozruchowego) podczas IPL typu B oraz "alternatywnego urządzenia restartu" podczas IPL typu D, czyli DVD lub taśmy. Jeśli LPAR pomyślnie IPL został przeprowadzony po raz pierwszy, nie musi ponownie odczytywać profilu, ponieważ ostatnie informacje IPL są przechowywane w monitorze maszyny wirtualnej. Podczas następnego IPL używane jest domyślne ustawienie "bieżąca konfiguracja", chyba że profil LPAR zostanie wybrany ponownie. Jeśli między kolejnymi IPL nastąpią określone zmiany dotyczące kontrolera LS lub szczegółów dysku LS, LPAR nie zaakceptuje zmienionego dysku LS, a IPL zakończy się niepowodzeniem. Dzieje się tak, jeśli: LPAR jest aktywowany przy użyciu opcji "current configuration" lub jeśli oznaczona karta we/wy LS jest ustawiona na "brak". Zmiana numeru seryjnego dysku LS jest zmianą o tyle dużą, że LPAR jej nie akceptuje i wymagana jest aktywacja z wybranym prawidłowym profilem.

Poniższy zrzut ekranu przedstawia tradycyjny widok profilu HMC LPAR z wybranym prawidłowym adapterem LS:

Na ilustracji poniżej przedstawiono te same informacje w widoku nowoczesnej wersji konsoli HMC v10 z programem VIOS 3.x/4.x.

 

Inne przydatne informacje znajdują się w systemach PowerMax i VMAX: Najlepsze praktyki w zakresie migracji niezakłócającej pracy i minimalnie zakłócająca pracy oraz przewodnik

operacyjny======================================================================================

PRAKTYCZNA procedura IBMi NDM:

#NDM (Non Disruptive Migration) procedure for IBMi host environments.
#From VMAX>>>VMAX, VMAX>>>PMAX, PMAX>>>PMAX
#Written: Q4-2021
#Author: Wopke Hoekstra CSA IBMi Global Practice
#Version: 5
==========================================================================================

# Just for reference: PowerMax OS 5978 Levels:

Name        Release Level/Code  
Elm         5978.144.144
Elm SR      5978.221.221
Foxtail     5978.444.444
Foxtail SR  5978.479.479
Hickory     5978.669.669
Hickory SR  5978.711.711
==========================================================================================
#PREREQS:
# MINIMUM Microcode Requirements: Foxtail (NDM IBMi support and NDM METRO-Mode available)
# MINIMUM of 2 RF directors per array are required
# Central external UniSphere/SE (SymCLI) server required with access to the source and target arrays
# MINIMUM SE version of 9.1
====================================================================================================

#Actual Customer Environment where this procedure was used:
# "OLD" VMAX: SN# ckxxxxxxxxx/ckxxxxxxxxx / 5978.479.479
# "NEW" PMAX: SN# ckxxxxxxxxx/ckxxxxxxxxx / 5978.479.479 

============================================================================================================
#Suggested NDM procedure: METRO NDM with Pre-Copy
#Also refer to the DELL EMC PowerMax NDM Whitepaper: Paragraph 3.2.4 / page 120
============================================================================================================

#PROCEDURE: Metro-based NDM with precopy 
#NOTE: (NDM with precopy allows end users to copy application data from the source array to target array while the application is still running on the source array)

#SAN requirements:
#Existing Host FC IOA ports/WWPN's will be used to also zone to the new target array's FA-ports. NO NEED for additional host FC connections.
#NOTE: The NEW array needs to be connected to the same SAN Fabric's as the OLD array.
#For each zone; add the desired target-array's FA-port WWPN into the existing zone (already containing the host initiator WWPN and OLD array FA-port WWPN)
#Or alternatively create new zones with same initiators to the new target-array's FA-ports

#NOTE: For LPAR's using VIOS/VFC(NPIV) connections and when the environment is setup for Live Partition Mobility, the vFC's secondary WWPN will be included in the zoning/masking.
#The secondary WWPN's will not be active and are not in the source array's Login History Table. NDM does not accept inactive WWPN's to be in the IG of the source host, hence the NDM VALIDATE and CREATE commands will fail.
#WORKAROUND: Temporarily remove the secondary WWPN's from the source LPAR IG. After the migration, simply add these secondary WWPN's back into the new IG on the target array. 

#Setup-phase: 
#symdm –src_sid <SN of Source> -tgt_sid <SN of target> environment -setup
symdm -sid 008 -tgt_sid 661 environment setup
#NDM RDFGroup will be created.

Now modify the SAN zoning to include the target-array FA-ports.
#NOTE: No devices are presented from the target-array yet.
#NOTE: You can already check if the existing initiator-WWPN's are actively logging in to the new array
symaccess -sid 661 list logins -dirport 1d:4

#To check the environment at any time:
#symdm –src_sid <SN of Source> -tgt_sid <SN of target> environment -validate
symdm -src_sid 336 -tgt_sid 662 environment -validate
symdm -src_sid 008 -tgt_sid 661 environment -validate

Other commands to display further details:
symdm -sid 336 -environment list
symcfg -sid 336 list -rdfg all
symcfg -sid 008 list -rdfg all

#NOTE: Take a copy of the source-array's masking database before the activity:
symaccess -sid 336 list view -all -v -detail>masking336_24Nov2021.txt
symaccess -sid 008 list view -all -v -detail>masking008_24Nov2021.txt

#Create Phase (with precopy: (run validation prior to execution))
#This creates an SRDF/Metro session with NDM attributes and puts the SRDF/Metro pair into adaptive copy disk mode. 
#It starts syncing data from R1 to R2. 
#Bias is on the Metro-based NDM source.
#symdm create –src_sid <SN of Source> -tgt_sid <SN of target> -sg <SG to be Migrated> [-tgt_srp <target SRP>] [-tgt_pg <target PG>] -precopy 
#First validate:
symdm create -src_sid 008 -tgt_sid 661 -sg SG_IBMPROD1_1 -precopy -validate
#Then execute:
symdm create -src_sid 008 -tgt_sid 661 -sg SG_IBMPROD1_1 -precopy

#Check NDM status:
#symdm –sid xxx list (-v) (-detail)
#symdm –sid<SN of SRC or TGT> -sg <SG to be Migrated> list –v –pairs_info -detail (shows device pairing)
#symrdf list -sid xxx (-rdfg xxx) (-sg xxx)
#symstat –sid <SRC SN> –rdfg<RDFG of Migration> –type RDF –i xx
symdm -sid 008 list

#ReadyTGT Phase: 
#Moves RDF pair state from adaptive copy mode to Active/Active(in case of witness protection) or Active/Bias (without witness protection).
#Target devices are moved into a read/write mode, It puts the NDM pair in Active/Active or Active/Bias mode
#Masking view is created on the target array using the masking elements created during the create command.
#symdm –sid <SRC or TGT SN> -sg <SG to be Migrated> readytgt
symdm -sid 008 -sg SG_IBMPROD1_1 readytgt

#Check status:
#symdm –sid xxx list (-v) (-detail)
#symrdf list -sid xxx (-rdfg xxx) (-sg xxx)
symdm -sid 008 list

#On the IBMi LPAR, check for new detected FC paths (to the devices on new PowerMax)
#Logon to LPAR, go into System Service Tools: STRSST and go to "work with disks"> "disk configuration"> "9.Disk Paths"
#Let the system discover the paths, this may take a few minutes, just hit F5 to refresh the disk path status screen and verify all disks have the new paths added.

#Commit Phase (this is the actual cutover to the new array):
#symdm –sid <SRC or TGT SN> -sg <SG to be Migrated> commit
symdm -sid 008 -sg SG_IBMPROD1_1 commit

#The masking views will be removed on the old source array.
#On the IBMi LPAR, check for the old paths going into "failed" status (these failing paths are the paths to the old source array)
#Zoning cleanup: Remove the old array's FA-ports from the respective zones for this LPAR.
#Use SST procedure to run MULTIPATH RESETTER macro (this will prevent further error messages being sent to the QSYSOPR MSGQ until the system is IPL-ed)
#After next planned IPL, the path status will be correct again, with only the new active paths listed.

#ONLINE MIGRATION COMPLETED!
============================

#Remove NDM environment (ONLY after last migration is completed):
#symdm -sid xxx -environment -list
#symdm –src_sid <SN of Source> -tgt_sid <SN of target> environment -remove
symdm -sid 008 -tgt_sid 661 environment -remove
============================================================================================================

#Reset Device external Identity (un-Spoof) (Optional OFFLINE operation).
#Resetting the target's device external identity back to the original array-based identity of the NEW array (changes the IBMi disk serial number (= Vol.ID + Array-ID))
#THIS REQUIRES A SHUTDOWN OF THE IBMi LPAR!
#Can be done as planned activity when the IBMi LPAR is doing an offline activity, and will be re-IPL-ed... I.e. for full backup, scheduled IPL, etc.

#NOTE: When STM (SRDF/TimeFinder Manager for IBMi) is used on the migrated LPAR, it requires a reconfiguration or as a minimum a DISCOVER command action, due to the changing of the LPAR's disk serial numbers.
#Refer to KB article 193832 for more info and procedure.

Tylko niezamaskowane urządzenia mogą zostać niesfałszowane, dlatego najpierw zapisz i zapisz szczegóły bieżącego widoku maskowania, a następnie usuń MV, usuń fałszerstwo, a następnie ponownie utwórz MV.

symaccess -sid xxx show view -name xxxxxxxx >masking_xxxxxxxx.txt
symaccess -sid xxx delete view -name xxxxxxxx 

Wyświetl szczegóły tożsamości dysku:

symdev -sid xxx list -identity_set
symdev -sid xxx list -identity -sg <sg-name>

Dla pojedynczego urządzenia:

symdev -sid xxx reset -identity -dev xxx -nop

Dla szeregu urządzeń:

symdev -sid xxx reset -identity -devs xxx:xxx -nop

symaccess -sid xxx create view -name xxxxxxxx -sg xxxxxxxx -pg xxxxxxxx -ig xxxxxxxx 
symdev -sid xxx list -identity -sg <sg-name>

W konsoli HMC IBM sprawdź, czy w profilu LPAR na karcie "Oznaczone we/wy" ustawiono prawidłowy adapter FC dla kontrolera LS.

NIE pozostawiaj pustego ustawienia kontrolera LS "Oznaczone wejścia/wyjścia" z zaznaczoną opcją "brak".

IPL z opcją B-Normal i wybierz profil LPAR dla IPL; NIE pozostawiaj domyślnej opcji "bieżąca konfiguracja".

Teraz IPL LPAR i po powrocie systemu do trybu online sprawdź numery seryjne dysków z SST.

Identyfikatory szeregowe powinny teraz odzwierciedlać nowe macierze: identyfikator symdev i numer seryjny macierzy.

=== End of Procedure ===