VMAX, PowerMax: IBMi 호스트 플랫폼을 위한 무중단 마이그레이션

지원 환경:
IBMi용 NDM은 PowerMaxOS 릴리스 5978.444.444 이상을 실행하는 VMAX 또는 PowerMax 어레이에 연결되어 지원되는 IBMi 호스트 시스템에서 사용할 수 있습니다.

이는 IBM Power Server 플랫폼 Power6 이상에서 실행 중이고 IBMi 운영 체제 버전 i6.1.1 이상을 실행하는 IBMi 논리 파티션(LPAR)용입니다. VMAX 또는 PowerMax 일반 e-Lab Support Matrix는 지원되는 FC(Fibre Channel) IBMi IOA(I/O Adapter), 즉 HBA(Host Bus Adapter)에 대한 세부 정보와 목록을 제공합니다. IBMi가 IBM VIOS(Virtual I/O Server)에서 가상 I/O 리소스가 할당된 클라이언트 LPAR인 경우에도 NDM이 지원됩니다. IBM VIOS/VFC(NPIV) 기능을 사용하면 지원되는 SAN 스위치를 사용하여 스토리지 어레이에 연결할 수 있도록 vFC(Virtual FC Adapter)가 클라이언트 LPAR에 지정됩니다.

vFC는 호스트 디스크 연결을 위한 패스스루 역할을 합니다. 호스트 측에서는 완전히 투명하며 스토리지 어레이에서 지원되는 모든 기능을 가상화된 어댑터 설정에서도 사용할 수 있습니다.

백그라운드 및 고급 마이그레이션 시나리오:
SRDF(Symmetrix Remote Data Facility)는 1990년대 초반에 Dell Enterprise Storage 어레이를 위한 DR(Disaster Recovery) 복제 기술로 개발되었습니다. 또한 어레이 간에 스토리지 기반 마이그레이션을 수행하는 데에도 수년간 사용되어 왔습니다. 즉, 이전 어레이와 새 어레이의 "백-투-백"을 연결하고 새 스토리지 어레이를 구축하여 기술 갱신을 수행할 때 데이터 볼륨을 복제합니다. 볼륨 또는 LUN(Logical Unit)의 SRDF 복제 프로세스는 연결된 호스트 시스템에 영향을 미치지 않지만, 기존에는 소스 볼륨(R1)에서 복제 프로세스가 완료될 때 항상 짧은 오프라인 "컷오버" 기간이 필요했습니다. (새) 타겟 볼륨(R2)은 읽기/쓰기가 활성화되었으며 호스트 시스템의 FC 연결이 SAN 조닝 및 마스킹을 통해 새 어레이에 지정되었습니다. 

SRDF/Metro는 VMAX All Flash Storage 어레이 제품군과 함께 도입되었습니다. SRDF/Metro는 두 어레이 모두에서 소스(R1) 및 타겟(R2) 볼륨에 대한 진정한 Active/Active 호스트 액세스를 제공합니다. SRDF/Metro는 디스크 액세스를 위해 지원되는 호스트 다중 경로 드라이버와 함께 작동합니다. 여기에는 디스크 경로에 대한 기본 IBMi DMP(Dynamic Multi Path) 보호 기능이 포함됩니다. IBMi DMP는 동일한 디스크 디바이스에 대한 FC 경로가 여러 개 있는지 자동으로 탐지합니다. 또한 사용 가능한 FC 어댑터 경로에 디스크 I/O 워크로드를 분산시키기 위한 기본적이지만 효과적인 "라운드 로빈" 로드 밸런싱 체계를 제공합니다. IBMi DMP는 연결이 실패할 수 있는 경우 디스크 I/O 작업을 나머지 활성 경로 중 하나로 리디렉션하여 자동 경로 페일오버를 제공합니다. 실패한 연결이 복원되면 IBMi는 자동으로 해당 경로를 복구하고 이러한 경로로 디스크 I/O를 다시 전송하기 시작합니다.

METRO 및 사전 복제 옵션이 포함된 NDM은 기본 SRDF/Metro 기술을 기반으로 기존 스토리지 디바이스와 새 스토리지 디바이스에 동시에 액세스할 수 있도록 합니다.

생성 단계:
SRDF/Metro 복제 디바이스 페어(R1>R2)가 생성되면 타겟 어레이의 R2 디바이스에서 동일한 R1 디바이스 ID가 표시됩니다. 본질적으로 동일한 디스크 직렬 ID와 디바이스 WWPN이 두 디바이스에서 모두 제공됩니다. 처음에 새 R2 디바이스는 AA-NR/DEV-INACT(Active/active-Not Ready/Device Inactive) 상태입니다. R1>R2 디바이스 페어가 동기화되면 R2 볼륨에 대한 읽기 및 쓰기 액세스를 활성화하여 Active/Active 상태로 전환할 수 있습니다.

READY_TARGET 단계:
이제 IBMi LPAR에서 R2 디바이스로의 경로가 사용 가능하면(SAN 조닝이 이미 설치되어 있고 NDM readytgt 명령으로 활성화된 새 어레이에 대한 마스킹) IBMi 호스트는 기존 디스크 디바이스에 대한 새 FC 경로를 검색합니다. IBMi NDM 시나리오에서는 활성/활성 R1 + R2 디바이스가 표시됩니다.

커밋 단계:
R1 디바이스에 대한 액세스를 제거하면 IBMi 호스트는 이제 이전 어레이의 경로에 액세스할 수 없게 되지만 새 어레이의 경로를 사용하여 R2 디바이스에서 계속 실행됩니다. 이 작업이 완료되면 이전 어레이에 대한 SAN 조닝을 제거할 수 있습니다. 이전의 비활성 경로 사용을 중지하고 현재 "누락된" 경로와 연관된 오류 메시지도 중지하려면 IBMi 시스템의 "다중 경로 재설정" 유틸리티를 실행해야 합니다. IBMi 호스트의 장치 구성 데이터베이스(IBMi 스토리지 관리 정보 저장소)에서 이전 비활성 경로 및 연관된 DMPxxx 디스크 하드웨어 자원을 영구적으로 제거하기 위해 초기 프로그램 로드(IPL)(일명 재부팅)가 필요할 수 있지만, 이는 필수 IPL이 아니며 다음 계획된 IPL까지 대기할 수도 있습니다. 이러한 "오래된" 디바이스를 제거하려면 다음을 수행합니다. STRSST>시작 서비스 툴>하드웨어 서비스 관리자>실패 및 보고 불가 하드웨어: 옵션 4를 사용하여 제거할 모든 이전 디스크 리소스 DMPxxx를 선택하고 Enter 키를 눌러 확인합니다.

Dell STM
사용 시 고려 사항STM은 VMAX용 IBMi 복제 제어를 위한 "스토리지 복제 서비스 툴킷"이라고도 합니다. PowerMax 스토리지는 하나 이상의 IBMi 호스트에서 기본 소프트웨어 애플리케이션으로 실행됩니다. 지원되는 SRDF 구성에 대한 원격 복제와 VMAX, PowerMax 어레이의 SnapVX 스냅샷에 대한 로컬 복제를 제어할 수 있습니다. STM은 두 가지 유형으로 제공됩니다. Standard Features Edition 및 Extended Features Edition

STM은 FC 경로 전반에서 스토리지 어레이에 대역 내 통신을 사용하며 시스템 호출을 위한 게이트키퍼라고도 하는 작은 전용 디바이스를 사용합니다. IBMi의 게이트키퍼는 구성되지 않은 디스크 장치 섹션에 남아 있는 특수한 소형 D910 GK 유형 장치입니다. 이러한 게이트키퍼는 다중 경로를 지원하지 않으며, 일반적으로 일반 ASP1 디스크에 사용되는 것과 동일한 이중화된 경로 세트에 여러 개의 단일 경로 게이트키퍼가 표시됩니다. 최소 4개의 게이트키퍼를 사용하는 것이 좋습니다. 게이트키퍼는 NDM 마이그레이션 프로세스의 일부가 아니므로 마이그레이션 후 이전 어레이의 게이트키퍼에 대한 액세스가 제거되고 새 어레이의 새 게이트키퍼가 표시됩니다.

표준 기능:
*SYSBAS 스토리지 구성만 사용하는 시스템에 사용됩니다. *SYSBAS는 시스템 ASP1 + 추가 사용자 ASP(ASP 2-32)를 의미합니다. STM은 소스 노드에만 설치되며 *SYSBAS의 모든 디스크에 대한 복제 쌍을 하나의 분할할 수 없는 엔티티로 제어합니다.  기본 디스크 구성에 변경 사항이 발생하는 경우 즉, NDM "스푸핑 해제" 조작으로 인한 디스크 일련 번호 변경의 경우, IBMi 소스 호스트에서 STM DISCOVER 명령을 수행하는 것으로 충분합니다. 새 어레이의 게이트키퍼가 표시되면 DISCOVER 옵션을 실행합니다. 이렇게 하면 호스트(location= /var/symapi/db)의 IFS(Integrated File System)에 로컬 symapi 데이터베이스가 업데이트됩니다. 이제 STM 화면에 새 디스크 일련 번호도 반영됩니다. STM 내의 복제 디바이스 페어링에서 문제가 발견될 경우 설치 옵션만 사용하여 새로운 구성 설정으로 시작할 수도 있습니다. 이는 VMAX-PowerMax 스토리지 어레이에 이미 구성된 복제 페어링 설정에는 영향을 미치지 않습니다. 클린 스크래치 설치/설정의 경우 먼저 현재 구성에서 관련 PATHS 및 STEPS를 문서화합니다(GO MAINCTL>1, IMAGES>아래 예와 같이 PATHS 화면에 대한 시스템 이미지> 생성 화면 캡처에 대해 옵션 2 선택).

STM을 종료하고 /var/symapi 폴더와 해당 하위 폴더를 삭제합니다. EMCCTL 라이브러리를 삭제합니다. STM을 실행하여 프로그램을 다시 설치합니다. CRTSYMAPI를 실행합니다. MAINCTL로 이동하여 이전에 구성한 것과 동일한 경로를 다시 연결합니다. 이제 STM이 VMAX-PowerMax 스토리지 어레이에서 활성 복제 페어링의 상태를 감지하고 표시합니다. 이제 STM 작업을 재개할 준비가 되었습니다.

확장 기능:
이는 하나 이상의 "전환 가능한" iASP(독립 ASP)와 함께 IBMi PowerHA 클러스터 설정을 사용하는 시스템에 사용됩니다. 이 시나리오에서는 iASP만 복제되고 이 iASP 또는 복제본을 PowerHA 클러스터 내의 노드에 표시할 수 있습니다. 각 클러스터 노드는 자체 *SYSBAS(ASP1)에서 이미 활성 상태입니다. iASP는 공유 클러스터 장치 도메인 내에서 교환 가능한 자원으로 구성됩니다. 클러스터에는 일반적으로 2개 또는 4개의 노드가 있습니다. 이는 운영 노드를 소스로 사용하고 양측에 원격 DR 타겟 노드와 SnapVX 백업 노드가 있는 4노드 클러스터에 대한 아래 다이어그램의 예와 같습니다.

iASP 또는 해당 복제본을 사용하기 위해 노드의 IPL이 필요하지 않습니다. iASP 디스크가 클러스터 내의 노드에 표시되는 경우 해당 노드에서 iASP를 사용할 수 있도록 하려면 VARY ON 명령이 필요합니다. PowerHA 설정에서 STM 소스 버전은 소스 노드(EMCCTL 라이브러리)에 설치됩니다. 다른 모든 노드(SRDF 또는 SnapVX 타겟 복제본)에는 타겟 버전이 설치됩니다(EMCCTLC 라이브러리). 모든 노드가 활성 상태인 경우 iASP가 여전히 해당 노드에 대해 VARY ON 상태인 경우 노드에 대한 디스크 액세스를 제거하는 이 설정의 특정 조작에 대해 STM에 종속성 및 견제 및 균형이 내장되어 있습니다. 노드 간 통신의 경우 모든 노드의 EMCCTL 서브시스템에서 STM 서버 작업이 실행됩니다. 이 작업은 클러스터 IP 인터페이스를 통해 노드 내에서 통신합니다. 일반적인 STM 작업은 클러스터 내의 모든 노드에서 실행할 수 있습니다. 이를 위해서는 각 노드에서 동일한 STM 디스크, 어댑터 및 경로 구성 파일 세트를 사용할 수 있어야 합니다. PowerHA용 STM의 초기 설정 중에 이러한 파일은 소스 노드에서 MAINCTL 옵션-16을 사용하여 구성되며, 이러한 파일은 STM 설치 라이브러리 EMCCTL 및 EMCCTLC의 IASPS, ISRCIOA 및 IMAGE 파일인 대상 노드에도 전파됩니다. DSPPM EMCCTL/IMAGE를 사용하여 이러한 파일도 표시할 수 있습니다. 파일에는 iASP 구성에 사용되는 디스크 및 디스크 어댑터에 대한 정보가 들어 있습니다. 어댑터 ID 및 디스크 일련 번호는 이러한 파일에 저장되고 STM 조작에 사용됩니다.

이제 NDM 스푸핑 해제 작업이 수행될 때 발생하는 디스크 일련 번호 변경의 영향을 고려합니다. STM 구성 파일에는 여전히 이전 디스크 일련 번호가 포함되어 있습니다. 대부분의 STM 작업은 이러한 구성 파일이 업데이트될 때까지 더 이상 작동하지 않습니다. 이러한 파일의 업데이트 및 전파는 각 PATH-STEP의 대상 노드에서 iASP 디스크를 사용할 수 있도록 하는 동안 MAINCTL>옵션-16(iASP 구성)이 실행될 때 초기 STM 설치 중과 동일한 프로세스를 수행하여 수행할 수 있습니다. 이러한 파일이 업데이트되면 STM iASP 작업이 다시 예상대로 작동합니다. 문제가 발생하면 iASP 경로/단계를 구성하고 STM 구성 파일을 만들거나 전파하는 옵션-16을 포함하여 소스 및 대상 노드에 대해 STM의 스크래치 설치만 다시 실행하는 것이 좋습니다.

Dell 지원 계정이 있는 등록 사용자는 SRDF/TimeFinder Manager for IBM i 에서 이러한 STM 에디션에 대한 추가 관련 정보를 확인할 수 있습니다.

디바이스 ID 재설정 후 다음 IPL에 대한 고려사항(일명 "unspoof" 조작
)NDM 스푸핑 해제 작업을 수행하면 디스크 일련 번호가 변경됩니다. 이는 IBMi LPAR이 작동 중지된 경우에만 수행할 수 있습니다. 마이그레이션 후 계획된 오프라인 유지 관리 슬롯에서 이 작업을 수행할 때 몇 가지 고려 사항이 있습니다. IBMi LPAR의 활성화는 IBM PowerServer Hardware Management Console(HMC)에서 제어되며, HMC는 IBM PowerVM 가상화를 위한 하이퍼바이저 기능을 제공합니다. 이 HMC에서 각 LPAR에는 LPAR 구성(즉, CPU/MEM, 어댑터 등)에 대한 세부사항이 있는 하나 이상의 LPAR 프로파일이 있습니다. LPAR이 처음으로 IPL(IPL= Initial Program Load = 부트 시퀀스)되면 선택된 프로파일에서 구성 세부사항을 읽습니다. 프로파일의 특수 탭을 "태그가 지정된 I/O"라고 합니다.  태그가 지정된 I/O 설정은 LPAR이 B 유형 IPL 중에 로드 소스(LS)(= bootdisk)를 검색하고 D 유형 IPL 중에 "대체 재시작 장치"(DVD 또는 테이프)를 검색해야 하는 위치를 정의합니다. LPAR이 처음으로 IPL에 성공한 경우, 마지막 IPL 정보가 하이퍼바이저에 저장되므로 프로파일을 다시 읽을 필요가 없습니다. 다음 IPL에서는 LPAR 프로파일이 특별히 다시 선택되지 않는 한 "현재 구성"의 기본 설정이 사용됩니다. IPL 사이에 LS 제어기 또는 LS 디스크 세부사항에 대한 특정 변경사항이 있는 경우, LPAR은 변경된 LS 디스크를 승인하지 않고 IPL이 실패합니다. 다음과 같은 경우 이 문제가 발생합니다. LPAR은 "현재 구성" 옵션 또는 태그가 지정된 I/O LS 어댑터가 "none"으로 설정된 경우 활성화됩니다. LS 디스크 일련 번호의 변경은 LPAR이 이를 승인하지 않고 선택한 올바른 프로파일을 사용한 활성화가 필요한 변경입니다.

아래 화면 캡처는 유효한 LS 어댑터가 선택된 기존 HMC LPAR 프로파일 보기를 보여줍니다.

아래 이미지는 VIOS 3.x/4.x를 사용하는 HMC v10의 최신 버전 보기에서 동일한 정보를 보여줍니다.

 

기타 유용한 정보는 PowerMax 및 VMAX에 포함되어 있습니다. 운영 중단 및 운영 중단을 최소화하는 무중단 마이그레이션 모범 사례 및 운영 가이드

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

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

마스킹되지 않은 디바이스만 스푸핑 해제할 수 있으므로 먼저 현재 마스킹 뷰의 세부 정보를 기록하고 저장한 다음 MV를 삭제하고 스푸핑을 해제한 다음 MV를 다시 만듭니다.

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

디스크 ID 세부 정보를 표시합니다.

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

단일 디바이스의 경우:

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

다양한 디바이스의 경우:

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>

IBM HMC의 LPAR 프로파일에 있는 "태그가 지정된 I/O" 탭에서 LS 제어기가 올바른 FC 어댑터로 설정되어 있는지 확인하십시오.

"none"을 선택한 상태에서 "태그 지정된 I/O" LS 컨트롤러 설정을 비워 두지 마십시오.

B-Normal 옵션을 사용하여 IPL을 수행하고 IPL에 대한 LPAR 프로파일을 선택하고, 디폴트 옵션인 "현재 구성"으로 두지 마십시오.

이제 LPAR에 IPL을 수행하고 시스템이 다시 온라인 상태가 된 후 SST에서 디스크 일련 번호를 확인하십시오.

이제 일련 번호 ID에 새 어레이 symdev ID와 어레이 일련 번호가 반영됩니다.

=== End of Procedure ===