VMAX, PowerMax: Häiriötön siirto IBMi-isäntäympäristöön

Tuettu ympäristö:
IBMi:n NDM on saatavilla tuetuille IBMi-isäntäjärjestelmille, jotka on liitetty VMAX- tai PowerMax-levyjärjestelmiin, joissa on PowerMaxOS-käyttöjärjestelmän

versio 5978.444.444 tai uudempi.Tämä koskee IBMi Logical Partition (LPAR) -osioita, jotka toimivat IBM Power Server -ympäristössä Power6 tai uudemmassa ja joiden käyttöjärjestelmä on IBMi-versio i6.1.1 tai uudempi. VMAX- tai PowerMax-yleisessä e-Lab-tukimatriisissa on tietoja tuetuista kuitukanavan (FC) IBMi I/O-sovittimista (IOA) eli isäntäväyläsovittimista (HBA). NDM:ää tuetaan myös silloin, kun IBMi on LPAR-asiakas, jolle on määritetty virtuaalisia I/O-resursseja IBM Virtual I/O Server (VIOS) -palvelimesta. IBM VIOS/VFC (NPIV) -ominaisuuden ansiosta asiakkaan LPAReihin määritetään virtuaaliset FC-sovittimet (vFC), jotta ne voidaan yhdistää tallennusjärjestelmään tuetuilla SAN-kytkimillä.

vFC: t toimivat isäntälevyyhteyden läpikulkuna; Isäntäpuolella tämä on täysin läpinäkyvää, ja kaikki tallennusjärjestelmän tukemat ominaisuudet ovat käytettävissä myös kyseisessä virtualisoidussa sovitinkokoonpanossa.

Taustan ja korkean tason siirtoskenaario:
Symmetrix Remote Data Facility (SRDF) kehitettiin 1990-luvun alussa Disaster Recovery (DR) -replikointiteknologiaksi Dell Enterprise Storage -tallennusjärjestelmiä varten. Sitä on myös käytetty useiden vuosien ajan tallennuspohjaisten siirtojen suorittamiseen yhdestä levyjärjestelmästä toiseen. Liitä siis OLD- ja NEW-levyjärjestelmän "back-to-back" ja kopioi tietotaltiot, kun suoritat tekniikan päivityksen ottamalla käyttöön uuden tallennusjärjestelmän. Vaikka tallennuslaitteiden tai loogisten yksiköiden (LUN) SRDF-kopiointiprosessi on läpinäkyvä liitetyille isäntäjärjestelmille, perinteisesti se vaati aina lyhyen offline-"cut-over" -ikkunan, kun kopiointiprosessi valmistui lähdetaltioista (R1). Kohdeasemat (uudet) (R2:t) olivat luku- ja kirjoituskäytössä, ja isäntäjärjestelmien FC-yhteydet osoitettiin (SAN-vyöhykkeiden ja maskauksen avulla) uuteen levyjärjestelmään. 

SRDF/Metro esiteltiin VMAX All Flash -tallennuslevyjärjestelmäperheen kanssa. SRDF/Metro tarjoaa todellisen aktiivisen/aktiivisen isännän pääsyn lähde- (R1) ja kohde- (R2) asemiin kummastakin tallennusjärjestelmästä. SRDF/Metro toimii tuettujen monipolkuisännän ohjainten kanssa levyn käyttöä varten. Tämä sisältää alkuperäisen IBMi Dynamic Multi Path (DMP) -suojauksen levypoluille. IBMi DMP tunnistaa automaattisesti, jos samaan levylaitteeseen on useita FC-polkuja. Se tarjoaa myös yksinkertaisen mutta tehokkaan "round robin" -kuormituksen tasapainotusmenetelmän, joka jakaa levyn I/O-kuormituksen käytettävissä oleville FC-sovitinpoluille. IBMi DMP mahdollistaa automaattisen polun vikasietoisuuden ohjaamalla levyn I/O-toiminnon johonkin jäljellä olevista aktiivisista poluista. Kun yhteyskatkokset palautetaan, IBMi palauttaa polut automaattisesti ja alkaa lähettää levyn I/O-toimintoja niihin uudelleen.

NDM, jossa on METRO ja esikopiointivaihtoehto, perustuu taustalla olevaan SRDF/Metro-tekniikkaan, joka mahdollistaa samanaikaisen pääsyn vanhaan ja uuteen tallennuslaitteeseen.

LUONTIVAIHE:
Kun SRDF/Metro-replikointilaitepari (R1>R2) luodaan, sama R1-laiteidentiteetti esitetään R2-laitteesta kohdelevyjärjestelmässä. Pohjimmiltaan sama levyn sarjanumerotunnus ja laite WWPN esitetään molemmista laitteista. Aluksi uusi R2-laite on tilassa AA-NR/DEV-INACT (aktiivinen / aktiivinen - ei valmis / laite ei ole aktiivinen). Kun R1>R2 -laitepari on synkronoitu, se voi siirtyä aktiiviseen/aktiiviseen tilaan sallimalla R2-aseman luku- ja kirjoitusoikeudet.

READY_TARGET vaihe:
Kun polku IBMi LPARista R2-laitteeseen on nyt käytössä (SAN-vyöhykkeistys on jo käytössä ja uuden levyjärjestelmän peittäminen aktivoitu NDM readytgt -komennolla), IBMi-isäntä löytää uusia FC-polkuja olemassa olevalle levylaitteelle. IBMi NDM -skenaariossa esitetään aktiiviset/aktiiviset R1 + R2 -laitteet.

COMMIT-vaihe:
Kun R1-laitteiden käyttöoikeus poistetaan, IBMi-isäntä menettää pääsyn vanhan levyjärjestelmän polkuihin, mutta toimii edelleen R2-laitteissa uuden levyjärjestelmän polkujen avulla. Tämän jälkeen vanhan levyjärjestelmän SAN-vyöhyke voidaan poistaa. IBMi-järjestelmässä on suoritettava nollausmonipolku, jotta voit lopettaa vanhojen passiivisten polkujen käytön ja pysäyttää myös näihin nyt puuttuviin polkuihin liittyvät virheilmoitukset. Vanhat passiiviset polut ja niihin liittyvät DMPxxx-levylaitteistoresurssit IBMi-isäntien laitemääritystietokannasta (IBMi-tallennuksen hallinnan tietovarasto) voidaan poistaa pysyvästi IPL (IPL) eli uudelleenkäynnistys, mutta tämä ei ole pakollinen IPL, vaan se voi myös odottaa seuraavaan suunniteltuun IPL:ään. Näiden "vanhentuneiden" laitteiden poistamiseksi: STRSST>Käynnistä huoltotyökalu>Laitteisto Service Manager>epäonnistui ja ei raportoi Laitteisto: valitse kaikki vanhat levyresurssit DMPxxx poistettavaksi vaihtoehdolla 4 ja vahvista se painamalla Enter.

Huomioon otettavia seikkoja käytettäessä Dell STM:
ääSTM, joka mainitaan usein myös VMAXin IBMi-replikoinnin hallinnan tallennuskopiointipalvelujen työkalupakettina, PowerMax-tallennus toimii natiiviohjelmistosovelluksena yhdessä tai useassa IBMi-isännässä. Se voi hallita etäreplikointia tuetuille SRDF-kokoonpanoille ja paikallista replikointia SnapVX-tilannevedoksille VMAX- ja PowerMax-levyjärjestelmissä. STM: ää on kahta makua: Standard Features -versio ja Extended Features -versio.

STM käyttää kaistansisäistä viestintää tallennusjärjestelmään FC-polkujen kautta, se käyttää pieniä erityisiä laitteita, jotka mainitaan myös portinvartijoina järjestelmäkutsuilleen. IBMi: n portinvartijat ovat erityisiä pieniä D910 GK -tyyppisiä laitteita, jotka jäävät konfiguroimattomien levyyksiköiden osaan. Nämä portinvartijat eivät tue monipolkuisia, useita yksipolkuisia portinvartijoita on tyypillisesti samoilla redundanteilla poluilla, joita käytetään tavallisissa ASP1-levyissä. On suositeltavaa käyttää vähintään neljää portinvartijaa. Portinvartijat eivät ole osa NDM-siirtoprosessia, joten siirron jälkeen portinvartijoiden käyttöoikeus vanhasta järjestelmästä poistetaan ja uusia portinvartijoita esitellään uudesta järjestelmästä.

Vakio-ominaisuudet:
Tätä käytetään järjestelmissä, joissa on käytössä vain *SYSBAS-tallennuskokoonpano. *SYSBAS tarkoittaa järjestelmää ASP1 + muita käyttäjän asp:itä (ASP 2–32). STM asennetaan vain lähdesolmuun, ja se hallitsee kaikkien *SYSBAS-levyjen replikointipareja yhtenä jakamattomana kokonaisuutena.  Kun taustalla olevan levyn kokoonpanossa tapahtuu muutoksia; eli levyjen sarjanumeroiden muutokset, jotka johtuvat NDM:n huijauksen poistosta, riittää, kun suoritat STM DISCOVER -komennon IBMi-lähdeisännässä. Suorita DISCOVER-vaihtoehto, kun uuden levyjärjestelmän portinvartijat esitetään. Tämä päivittää paikallisen symapi-tietokannan isännän integroidussa tiedostojärjestelmässä (IFS) (location= /var/symapi/db). STM-näytöissä näkyvät nyt myös uudet levyjen sarjanumerot. Jos STM:n replikointilaitteen pariliitoksessa havaitaan ongelmia, on myös mahdollista käyttää asennusvaihtoehtoa vain aloittaaksesi uudella kokoonpanoasetuksella. Tällä ei ole vaikutusta replikointiparin määritykseen, joka on jo määritetty VMAX-PowerMax-tallennusjärjestelmässä. Jotta asennus tai määritys sujuu siististi, dokumentoi ensin nykyisen kokoonpanon liittyvät polut ja VAIHEET (GO MAINCTL>1, IMAGES>valitse vaihtoehto 2, SYSTEM-kuvaa> varten luo kuvakaappaus PATHS-näyttöön alla olevan esimerkin mukaisesti:

Sulje STM ja poista /var/symapi-kansio ja sen alikansiot. Poista EMCCTL-kirjasto. Suorita STM, asenna ohjelma uudelleen. Suorita CRTSYMAPI. GO MAINCTL ja liitä uudelleen samat polut kuin aiemmin määritettiin. STM tunnistaa ja näyttää nyt aktiivisen replikointiparin tilan VMAX-PowerMax-tallennusjärjestelmästä. STM-toiminta on nyt valmis jatkettavaksi.

Laajennetut ominaisuudet:
Sitä käytetään järjestelmissä, joissa on IBMi PowerHA -klusterikokoonpano, jossa on vähintään yksi "vaihdettava" iASP (itsenäinen ASP). Tässä skenaariossa vain iASP replikoidaan ja tämä iASP tai sen replika voidaan esittää PowerHA-klusterin solmuille. Jokainen klusterisolmu on jo aktiivinen omassa *SYSBAS (ASP1). iASP määritetään vaihdettavaksi resurssiksi jaetun klusterilaitteen toimialueella. Klusterissa on tyypillisesti kaksi tai neljä solmua; Tämä on alla olevan esimerkkikaavion mukaisesti 4-solmuiselle klusterille, jonka lähteenä on tuotantosolmu ja jonka molemmilla puolilla on DR-kohdesolmu ja SnapVX-varmuuskopiosolmu:

iASP:n tai sen replikoiden käyttämiseen ei tarvita minkään solmun IPL:ää. Kun iASP-levyt esitetään jollekin klusterin solmulle, tarvitaan VARY ON -komento, jotta iASP on kyseisen solmun käytettävissä. PowerHA-asetuksissa STM-lähdeversio asennetaan lähdesolmuun (EMCCTL-kirjastoon). Kaikkiin muihin solmuihin (joko SRDF- tai SnapVX-kohdereplikoihin) asennetaan kohdeversio (EMCCTLC-kirjastoon). Kun kaikki solmut ovat aktiivisia, STM:ään sisältyy riippuvuuksia sekä tarkistuksia ja saldoja tietyille tämän määrityksen toiminnoille, jotka poistavat pääsyn solmuun solmulta, jos iASP on edelleen kyseisen solmun VARY ON -tilassa. Solmujen välistä tiedonsiirtoa varten EMCCTL-alijärjestelmässä on käynnissä STM-palvelintyö kaikissa solmuissa. Tämä työ kommunikoi klusterin IP-liittymien solmujen sisällä. Tyypillisiä STM-toimintoja voidaan suorittaa mistä tahansa klusterin solmusta. Tämä edellyttää, että kussakin solmussa on käytettävissä joukko samoja STM-levyjä, sovittimia ja polkumääritystiedostoja. PowerHA:n STM:n alkuasennuksen aikana nämä tiedostot määritetään käyttämällä lähdesolmun MAINCTL-vaihtoehtoa 16, ja tämä välittää nämä tiedostot myös kohdesolmuihin, jotka ovat IASPS-, ISRCIOA- ja IMAGE-tiedostoja STM:n EMCCTL- ja EMCCTLC-asennuskirjastoissa. Myös nämä tiedostot voidaan näyttää eli DSPPFM EMCCTL/IMAGE. Tiedostot sisältävät tietoja iASP-määrityksessä käytetyistä levyistä ja levysovittimista. Sovitintunnukset ja levyn sarjanumerot tallennetaan näihin tiedostoihin ja niitä käytetään STM-toiminnoissa.

Mieti nyt, mitä vaikutusta levyn sarjanumeron muutoksella on, kun NDM-huijauksen poisto on valmis. STM-kokoonpanotiedostot sisältävät edelleen vanhat levyn sarjanumerot. Useimmat STM-toiminnot eivät enää toimi, ennen kuin nämä määritystiedostot päivitetään. Nämä tiedostot voidaan päivittää ja levittää samalla tavalla kuin ensimmäisessä STM-asennuksessa, kun MAINCTL>Option-16 (määritä iASP) suoritetaan, kun iASP-levyt ovat kohdesolmujen käytettävissä vastaavassa PATH-STEP-vaiheessa. Kun tiedostot on päivitetty, STM iASP -toiminnot toimivat jälleen odotetulla tavalla. Jos ongelmia ilmenee, suosittelemme STM:n scratch-asennuksen suorittamista uudelleen vain lähde- ja kohdesolmuille, mukaan lukien vaihtoehto 16, jolla määritetään iASP-polut/STEP-polut ja luodaan tai levitetään STM-määritystiedostoja.

Rekisteröityneet käyttäjät, joilla on Dell-tukitili, voivat katsoa IBM i:n SRDF/TimeFinder Managerista lisätietoja näistä STM-versioista.

Huomioon otettavia seikkoja seuraavassa IPL:ssä laiteidentiteetin nollauksen eli huijauksen poistotoiminnon
jälkeenNDM-huijauksen poistotoiminto muuttaa levyn sarjanumeroita. Tämä onnistuu vain, kun IBMi LPAR ei ole toiminnassa. Kun tämä toiminto suoritetaan siirron jälkeen suunnitellussa offline-huoltopaikassa, huomioon otetaan joitakin seikkoja. IBMi LPARin aktivointia ohjataan IBM PowerServer Hardware Management Console (HMC) -konsolista. HMC tarjoaa Hypervisor-toiminnon IBM PowerVM -virtualisointia varten. Tässä HMC:ssä jokaisella LPAR:lla on vähintään yksi LPAR-profiili, joka sisältää tietoja LPAR-kokoonpanosta eli CPU/MEM, sovittimet jne. Kun LPAR on IPL-ed (IPL= Initial Program Load = boot sequence) ensimmäistä kertaa, se lukee valitun profiilin kokoonpanotiedot. Profiilin erityinen välilehti on nimeltään "Merkitty I / O".  Merkityt I/O-asetukset määrittävät, mistä LPAR:n on etsittävä latauslähdettä (LS) (= käynnistyslevyke) B-tyypin IPL:n aikana ja "vaihtoehtoista uudelleenkäynnistyslaitetta" D-tyypin IPL:n aikana, eli DVD:tä tai nauhaa. Jos LPAR on onnistuneesti IPL-ed ensimmäistä kertaa, sen ei tarvitse lukea profiilia uudelleen, koska viimeiset IPL-tiedot tallennetaan hypervisoriin. Seuraavassa IPL:ssä käytetään oletusasetusta "nykyinen kokoonpano", ellei LPAR-profiilia valita erikseen uudelleen. Jos LS-ohjaimeen tai LS-levyn tietoihin tehdään erityisiä muutoksia IPL-levyjen välillä, LPAR ei hyväksy muutettua LS-levyä ja IPL epäonnistuu. Näin tapahtuu, jos: LPAR aktivoidaan "current configuration" -vaihtoehdolla tai jos Tagged I/O LS -sovittimen asetuksena on "none". LS-levyn sarjanumeron muutos on sellainen muutos, että LPAR ei hyväksy sitä ja jossa tarvitaan aktivointi oikealla profiililla.

Alla olevassa näyttökuvassa näkyy perinteinen HMC LPAR -profiilinäkymä, jossa kelvollinen LS-sovitin on valittuna:

Alla olevassa kuvassa näytetään samat tiedot HMC v10:n nykyaikaisessa versionäkymässä, jossa on VIOS 3.x / 4.x.

 

Muita hyödyllisiä tietoja on PowerMaxissa ja VMAXissa: Ei-häiritsevä ja minimaalisesti häiritsevä siirto Parhaat käytännöt ja toimintaopas

======================================================================================

KÄYTÄNNÖN IBMi NDM -menettely:

#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.

Vain peittämättömät laitteet voidaan poistaa väärentämällä, joten tallenna ensin nykyisen maskausnäkymän tiedot, poista sitten MV, poista huijaus ja luo sitten MV uudelleen.

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

Näytä levyn tunnistetiedot:

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

Yksittäinen laite:

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

Eri laitteet:

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>

Tarkista IBM HMC:stä, että LPAR-profiilin "Tagged I/O" -välilehdessä LS-ohjaimen asetuksena on oikea FC-sovitin.

ÄLÄ jätä "Tagged I/O" LS -ohjaimen asetusta tyhjäksi "ei mitään" valittuna.

IPL B-Normal-vaihtoehdolla ja valitse IPL:n LPAR-profiili, ÄLÄ jätä sitä oletusvaihtoehdon "nykyinen kokoonpano" varaan.

Suorita nyt IPL LPAR ja kun järjestelmä on taas toiminnassa, tarkista levyn sarjanumerot SST:stä.

Sarjatunnusten pitäisi nyt kuvastaa uutta levyjärjestelmätunnusta, symdev-tunnusta ja järjestelmän sarjanumeroa.

=== End of Procedure ===