Virtual Hive

[VMware] vRSLCM 바이너리 화일 맵핑 에러

yueisu — Thu, 24 Nov 2022 19:22:36 +0900

vRSLCM은 과거에도 소개했듯이 vRealize Suite 제품의 라이프사이클을 관리합니다. 때문에 vRSLCM에서 설치한 제품의 업그레이드는 vRSLCM에서 실행할 필요가 있습니다.

설치한 vRealize Suite 제품의 업그레이드는 간단합니다. 업그레이드용 바이너리 파일을 vRSLCM에 맵핑하여 업그레이드를 실행하기만 하면 됩니다. vRSLCM이 VMware Customer Connect 에 접근이 가능하다면 원스텝으로 바이너리 파일의 맵핑을 실행할 수 있습니다. 인터넷 접근이 안 되거나VMware Customer Connect 접근에 필요한 로그인 정보를 설정할 수 없을 경우는 수동으로 바이너리 파일을 다운로드하여 vRSLCM에 업로드 후 맵핑을 실행하면 됩니다.

검증 환경에서 SaltStack Config(SSC)의 업그레이드가 필요하여 업그레이드용 바이너리 파일을 다운로드, vRSLCM에 업로드 후 맵핑을 실행하였더니 다음과 같은 에러가 발생했습니다.

LCMSOURCEMAPPING10018
Selected files checksums does not match with any product versions supported by vRealize Lifecycle Manager.

vRSLCM과 vRA의 버전은 8.7로, SSC는 8.6.2가 설치되어있기 때문에 당연히 RSLCM가 지원하는 버전입니다. 다운로드한 파일의 해시값도 확인을 했습니다만 문제가 없었죠. 조사를 해보니 vRSLCM이 갖고 있는 vRealize Suite 제품의 해시값과 다운로드한 화일의 해시값이 다를 경우도 발생하는 에러인 것 같았습니다.

해결 방법은 vRSLCM을 업그레이드하거나 vRSLCM의 제품 지원 팩을 업그레이드하는 것이었습니다. 제경우는 vRSLCM의 제품 지원팩을 업그레이드하는 것으로 해결되었습니다.

방법은 간단합니다. VMware Customer Connect에서 vRSLCM의 제품 지원 팩의 최신판을 다운로드하여 vRSLCM의 「Settings」→ 「Product Support Pack」에서 최신 정보를 반영해주면 됩니다.

제품 지원 팩을 최신판으로 업데이트 후는 무사히 바이너리 파일이 맵핑되었습니다. ;)

[VMware] 게스트 OS의 지원 레벨에 대해서

yueisu — Wed, 19 Oct 2022 19:16:20 +0900

vSphere 8의 릴리스 노트에 ESXi 8에서 호환되는 게스트 OS에 대한 기재가 있습니다. 마이너 버전을 포함한 각 게스트 OS의 상세 정보는 「VMware Compatibility Guide」에서 확인할 필요가 있습니다만 이렇게 릴리스 노트에 리스트로 정리를 해주면 훨씬 알기 쉬운 거 같네요.

The following guest operating system releases are deprecated or terminated in this release. Future vSphere releases will not support these guest operating systems:

・ Windows Vista, Windows 2003 / R2, Windows XP: Deprecated
・ Oracle Linux 5.x: Deprecated
・ Oracle Linux 4.9: Terminated
・ CentOS 5.x: Deprecated
・ Asianux 3.0: Deprecated
・ SUSE Linux Enterprise Server 9 SP4: Terminated
・ SUSE Linux Enterprise Server 10 SP4: Deprecated
・ SUSE Linux Enterprise Desktop 12: Deprecated
・ Ubuntu releases 12.04, 18.10, 19.04 and 19.10: Terminated
・ Debian 7.x and 8.x: Deprecated
・ Debian 6.0: Terminated
・ Photon OS 1.0: Terminated
・ Flatcar Container Linux non-LTS releases: Terminated
・ All OS X and macOS releases: Terminated
・ FreeBSD 9.x and 10.x: Deprecated
・ FreeBSD 7.x and 8.x: Terminated
・ Solaris 10.x: Deprecated
・ All eComStation releases: Terminated
・ All SCO releases: Terminated
・ All CoreOS releases: Terminated

가끔 게스트 OS의 호환성에 대해서 헷갈려 하시는 분들이 계신 거 같아서 간단하게 표로 정리를 해봤습니다. 일단 VMware에서는 게스트 OS에 대해 다음과 같은 지원 레벨을 정의하고 있습니다.

Understanding guest operating system support levels

Tech Preview
Supported
Legacy
Deprecated
Terminated
Unsupported

참고하세요~ ;)

[VMware] vSphere 릴리스 모델 변경에 대해서

yueisu — Fri, 14 Oct 2022 10:31:15 +0900

10월 11일, vSphere 8과 vSAN 8이 릴리스 되었습니다.
VMware vSphere 8.0 릴리스 정보

VMware vSAN 8.0 릴리스 정보

이번 vSphere 8부터 릴리스 모델이 변경되었기에 메모 겸 포스팅을 합니다.

New Release Model for vSphere 8

vSphere 7까지는 릴리스=GA(General Availability)이었습니다만 vSphere 8부터는 IA(Initial Availability)과 GA로 나뉘어 릴리스 된다고 합니다. 새롭게 등장한 IA은 GA과 동일한 품질의 "초기 제공"버전으로 물론 일반 이용자에게 제공됩니다. 아울러 OEM 파트너의 커스텀 이미지로 이용도 가능한 이제까지의 GA라고 생각하면 될 거 같습니다.

그렇다면 왜 굳이 IA와 GA로 나눈 것인가 하는건데요. 아무래도 1) 새 버전을 하루빨리 이용하고 싶은 유저를 위함, 2) 릴리스 직후 가장 많아 발생하는 피드백을 수집, 다음의 GA에 반영하기 위함이 아닐까 생각됩니다. vSphere 7이 IA, vSphere 7 Update 1이 GA라면 이해가 쉽지 않을까 합니다.

GA는 IA 릴리스후 약 4~6주 후 릴리스 예정이라고 합니다. GA 릴리스 6개월 뒤에 Update 1이 릴리스 되었던 지금까지의 주기를 생각한다면 단기간에 버그 수정을 포함한 피드백의 대응이 가능하여 보다 빨리 그리고 신뢰성 높은 제품을 제공할 수 있게 되겠네요. ;)

[VMware] vCenter Converter 부활했습니다!

yueisu — Wed, 12 Oct 2022 19:51:38 +0900

축! vCenter Converter Standalone이 부활했습니다!

올해 2월 VMware 제품 다운로드 리스트에서 삭제되어 사실상 은퇴한 vCenter Converter Standalone이 부활했습니다.

VMware vCenter Converter Standalone 6.3 Release Notes

은퇴 후는 차기 vCenter Converter로 어플라이언스 버전을 릴리스 예정이라고 들은 거 같습니다만 이용자로부터의 요망이 많았던 걸까요? 일단은 최신 vSphere과의 호환성을 맞춘 버전 6.3이 릴리스 되었습니다.

VMware vSphere 7.0 ~ Update 3
VMware vSphere 6.7 Update 3
VMware vSphere 6.5 Update 3

이용을 하려면 이전처럼 Windows Server상에 어플리케이션으로 설치를 해야 됩니다.

상세 정보는 제품 공식문서를 확인하세요.

VMware vCenter Converter Standalone Documentation

[VMware] vSAN 8 ESA에 대해서

yueisu — Thu, 6 Oct 2022 23:24:43 +0900

오랜만에 포스팅을 합니다. 업무상 예전처럼 마음대로 검증을 할 수가 없다 보니 포스팅할 주제도 찾기가 힘들더군요. 쩝... (；・∀・)

지난달 vSphere 8과 함께 vSAN 8 도 발표되었죠.
Announcing vSAN 8

새로운 기능을 추가와 함께 기존 기능을 개선해왔던 지금까지의 신버전과는 달리 vSAN 8 에선 새로운 아키텍처가 소개되었습니다.

vSAN 7까지 vSAN 아키텍처를 OSA(Original Storage Architecture)로 정의해 새롭게 ESA(Express Storage Architecture)가 소개되었습니다. 또 새로운 단어가 등장했네요... 흐흐 ;)

위의 그림처럼 ESXi 호스트에 캐시/용량 디바이스로 구성된 디스크 그룹을 작성하여 vSAN 데이터스토어를 구성하는 종래의 vSAN이 vSAN OSA입니다. vSAN OSA는 용도에 따라 SSD/HDD를 유연히 선택할 수 있기에 폭넓은 기업에서 도입되었죠. 근래 들어 All-Flash 구성이나 10 Gbps 네트워크 구성이 디펙트 스탠더드가 되어 최근 1~2년 전부터는 NVMe와 같은 고속 인터페이스나 25/40/100 Gbps 네트워크 어댑터 등 고성능 디바이스를 탑재하는 하드웨어도 많아지고 있죠. 이런 고성능 디바이스의 능력을 최대한 활용하고자 하는 목적으로 소개된 것이 바로 이 vSAN ESA입니다.

vSAN ESA는 "싱글 티어" 아키텍처입니다. vSAN OSA는 캐시 디바이스와 용량 디바이스가 각각 성능과 용량을 제공하고 있습니다만 vSAN ESA는 구성하는 모든 스토리지 디바이스(NVMe)가 성능과 용량을 동시에 제공합니다. "싱글 티어" 구성이기 때문에 vSAN OSA과 같은 디스크 그룹은 작성하지 않습니다. 대신에 ESXi 호스트별로 "Storage pool"을 작성하여 디바이스를 추가하기만 하면 됩니다. "Storage pool"에 추가되는 디바이스를 독립된 관리 도메인과 폴트 도메인이 되기 때문에 보수 유지성과 가용성이 크게 향상됩니다. (캐시 디바이스 교환 후 재작성이 필요한 디스크 그룹과 비교를 하면 운용 부하가 얼마나 다른지 짐작하실 수 있을 겁니다)

또한 새로운 오브젝트 포맷으로 성능 렉(Performance Leg)과 용량 렉(Capacity Leg)을 채용하여 "싱글 티어" 구성에서의 데이터 쓰기(vSAN OSA의 캐시 티어)와 데이터 보존 (vSAN OSA의 용량 티어)을 수행하도록 되었습니다.

vSAN ESA는 vSAN 7이나 vSAN 8 OSA 과의 호환성도 갖고 있기 때문에 Advanced Cross vCenter vMotion을 이용하여 가상 머신을 vSAN ESA 클러스터에 이행할 수 있습니다.

그 외에도 vSAN 8 은 많은 기능 강화나 개선이 있습니다. 일부를 소개하자면…

새로운 로그 구조 파일 시스템을 채용하여 RAID 5/6의 Erasure Coding 성능을 RAID 1과 동등할 정도로 향상했습니다. 아울러 RAID 5에 대해서는 4+1 또는 2+1 구성을 ESXi 호스트 수에 따라 자동적으로 조정하도록 되었습니다.
스토리지 정책에서 압축 기능의 유효화/무효화를 설정할 수 있습니다. 아울러 압축률은 4KB 블록에 대해 최대 8:1까지 실현하였습니다.
vSAN 네트워크 상의 가상 머신 트래픽과 재동기 트래픽의 비율을 자동적으로 조정하게 되었습니다.
vsanSparse의 개량으로 스냅숏 작성/삭제 성능이 최대 100배 고속화되었으며 Degraded 상태의 오브젝트에 대해서도 스냅숏을 작성할 수 있게 되었습니다.
vSAN 클러스터의 정지 방법이 강화되었습니다.
디스크 그룹의 캐시 디바이스의 버퍼 사이즈가 600GB 에서 1.6TB로 증가되었습니다. (vSAN 8 OSA)
CEIP 유효화/무효화, 인터넷 접근 가능/불가능에 맞춰 헬스 서비스가 강화되었습니다.

2년 만의 메이저 버전이긴 하지만 신기능의 추가는 그다지 없었던 것 같습니다. 뭐, vSAN 7에서 File Service 나 HCI Mesh, Native KMS에 의한 암호화 등 스토리지로써의 기능은 대부분 갖춰졌기 때문에 성능이나 가용성, 운용 효율면에서 확실히 향상되는 것이 이용자 입장에서는 만족할 부분이 되지 않을까 싶네요. 앞으로 검증을 통해 보다 상세한 내용들을 소개해 드리도록 하겠습니다.

[VMware] vCenter Converter의 은퇴

yueisu — Thu, 10 Feb 2022 20:39:27 +0900

vCenter Converter를 다운로드할 수 없게 되었습니다.

vCenter Converter Unavailable for Download

위의 공식 블로그에 의하면 제품 다운로드 리스트에서 vCenter Converter를 삭제했다고 합니다.

2018년 릴리스된 버전 6.2.0.1을 마지막으로 새로운 버전도 없었기 때문에 vSphere 6.7 이후와는 호환성도 없습니다만 마이그레이션 안건에서는 꽤나 신세를 진 제품이기에 섭섭하네요...

무상임에도 불구하고 P2V나 RDM 구성의 VM 마이그레이션에서도 이용이 가능한 편리한 제품이었죠. 아직도 물리 서버를 운용하고 있어 P2V를 검토하고있는 관리자도 안타까운 소식이 아닐까 싶네요.

하지만! 제품 자체가 완전히 사라지는 건 아니고 새로운 버전을 개발 중이라고 하니 조만간 새로운 모습으로 재등장할 겁니다. 기다리죠!

[VMware] Inclusive Naming Initiative 에 대해서

yueisu — Thu, 23 Dec 2021 19:11:24 +0900

오랜만입니다.

오늘은 VMware만의 내용은 아닙니다만, 언젠가는 여러분들에게도 영향을 줄 수 있을 거 같아서 짧지만 소개를 하려고 합니다.

IT 업계에 있다면 평상시 아무런 생각없이 사용하고 있지만 그 의미나 연상되는 이미지가 그다지 좋지 않은 단어가 있습니다. 예를 들어 ”master”나 ”slave”, ”whitelist”나 ”blacklist” 등이 그런 단어라고 할 수 있겠습니다. 업무상 이런 단어는 거의 매일 사용을 하고 있을 겁니다만 그 의미(사전적인 의미나 비유적인 표현)를 신경 쓰는 경우는 거의 없지 않을 듯싶습니다. 사실 저도 그렇거든요.

이런 단어를 다른 단어로 바꾸자는 움직임이 있습니다. 작년 11월에 설립된 ”Inclusive Naming Initiative” 도 그런 움직임의 하나입니다.

”Inclusive Naming Initiative” 는 주종관계나 차별의 의미를 갖고 있거나 연상시키는 단어를 대체하자는 것이 목적이라고 할 수 있습니다. 이 이니셔티브에는 Red Hat이나 IBM 같은 여러 IT 기업이 참가하고 있으며 VMware도 참가하고 있습니다.

VMware에서는 어떤 식으로 대응을 하고 있는지 예를들자면

과 같이 대체 단어를 장려하거나 공식 문서의 단어를 수정하기 시작했습니다.

하지만 방대한 양의 공식 문서나 UI를 짧은 기간에 변경하는 것은 불가능하기에 장기간에 걸친 대응이 되리라 생각합니다. 실제로 일부 문서에서는 단어의 변경이 명기되어 있습니다만 동시에 변경이 완료되는 것은 시간이 걸린다는 것도 쓰여 있습니다.

개인적으로는 솔직히 그렇게까지 할 필요가 있을까라는 생각도 있습니다만 근래의 국제정세상 이러한 단어가 좋은 의미로 이용되는 경우는 없으리라 생각도 있네요. 이러한 움직임에 대해서 납득됩니다. 제자신, 항상 인식하지 않고있으면 잊어버릴 거 같네요. 습관이란 게 무섭네요. 흐흐

이러한 움직임은 업계를 선도하고있는 기업이 적극적으로 참가함으로써 가속되리라 생각합니다. 물론 더 빨리 보급되기 위해서는 이용자 측에서도 의식의 전환이 필요하겠죠. :)

더욱 자세히 알고 싶으시다면 아래의 링크를 확인하세요.

Inclusive Naming Initiative

VMware의 대응
VMware’s Inclusive Terminology Journey

Replacing Problematic Terminology

[VMware] vCenter Client에서 ESXi 호스트의 권한이 표시되지 않음

yueisu — Mon, 4 Oct 2021 20:26:04 +0900

오랜만입니다....

vCenter Server 7.0 U2 환경에서 ESXi 호스트의 [권한] 탭을 선택해도 아래 그림처럼 아무것도 표시되지 않을 수가 있습니다.

■ 원인

이 현상은 vCenter Server 7.0 U2의 known issue인 것 같습니다. 영향을 받는 빌드는 다음과 같습니다.

vCenter Server 7.0 U2
vCenter Server 7.0 U2a
vCenter Server 7.0 U2b

■ 해결책

아래의 KB에 기재되어있듯이 vCenter Server 7.0 U2c로 업데이트를 하면 해결된다고 합니다.

Unable to see ESXi host permissions in the vSphere Client

오랜만의 포스팅이 이런 간단한 내용이네요. 흐흐

[VMware] vRealize Automation 8.3 ~ 멀티 테넌시의 구성 (3)

yueisu — Sat, 8 May 2021 09:24:36 +0900

이번에는 vRSLCM에서 만든 테넌트에 리소스를 할당하는 방법에 대해서 소개를 하겠습니다. 멀티 테넌시 시리즈는 이번 회로 끝날 예정입니다. ;)

지난 회에 테넌트를 작성했죠. 이 테넌트를 vRA에서 이용할 경우는 리소스를 할당해줘야 됩니다. 테넌트에 할당 가능한 리소스는 다음과 같습니다.

컴퓨팅
네트워크
스토리지
이미지
플레이버

위의 리소스 중에서 "컴퓨팅", "네트워크", "스토리지"는 하나의 프로파일로 모아서 할당할 수 있습니다. 이것을 담당하는 것이 VPZ(Virtual Private Zones)입니다. VPZ는 vRA 8.2에서 새롭게 추가된 기능으로 간단히 설명을 하자면 Cloud Zone＋Network Profile＋Storage Profile의 집합체라고 할 수 있겠네요. 테넌트는 이 VPZ를 프로젝트의 존으로 이용합니다. 물론 각 테넌트에서 통상의 Cloud Zone이나 Network Profile, Storage Profile을 작성하여 이용할 수도 있습니다. 테넌트에서 할 수 없는 것은 VPZ 작성 정도가 아닐까 합니다. VPZ의 작성은 디폴트 vRA에서만 할 수 있습니다)

"이미지"나 "플레이버"는 테넌트 사이에서 공유할 수도 있고 테넌트 전용으로 작성을 할 수도 있습니다. 이용할 "이미지"나 "플레이버"가 관리하기가 부담스럽다면 공유하는 것도 문제가 없겠습니다만 개인적으로는 테넌트 주소나 존을 나누기 때문에 "이미지"나 "플레이버"도 테넌트별로 이용을 하는 것이 좋다고 생각합니다.

그럼 간단하게 순서를 보도록 하죠.

먼저 디폴트 vRA에 로그인하여 Cloud Assembly의 「Infrastructure」에서 「Virtual Private Zones」를 작성합니다.

"Summary", "Compute", "Storage", "Network"별로 설정을 하게 됩니다. Network에서 태그 작성 부분이 적거나 복수의 Storage Profile을 작성할 수 없습니다만 기본적으로는 통상의 Cloud Zone 작성과 같습니다.

VPZ이 작성된 것을 확인합니다.

VPZ을 만들었다면 「Tenant Management」로 이동합니다. vRSLCM에서 작성한 테넌트가 표시되어 있을 겁니다. VPZ를 할당할 테넌트를 선택합니다.

「Infrastructure Management」로부터 「ALLOCATE INFRASTRUCTURE」를 클릭합니다.

할당할 VPZ를 선택합니다.

다음에는 「Image Mappings」에서 이미지를 추가합니다.

추가할 이미지가 저장되어있는 "Cloud Account", "이미지 이름", "VM 템플릿"을 선택후 다른 테넌트와의 공유 유무도 지정을 합니다.

같은 방법으로 플레이버로 작성을 합니다. 이것으로 준비 끝입니다.

남은건 테넌트에서 프로젝트를 작성, 프로비저닝 존으로 할당한 VPZ를 지정하기만 하면 됩니다.

여기까지 3회에 걸쳐 vRA 8.3의 멀티 테넌시 구성에 대해서고 소개를 했습니다. 솔직히 vRA 7에 비하자면 여러 제품을 조작하거나 인증서를 업데이트해야 하는 등 번잡해진 느낌입니다. 하지만 한번 구성해 놓으면 테넌트별로 격리되기 때문에 보안을 중시하는 테넌트 운용을 검토 중인 관리자 분들은 한 번 검증해 보시길 바랍니다.

그럼...

[VMware] vRealize Automation 8.3 ~ 멀티 테넌시의 구성 (2)

yueisu — Mon, 3 May 2021 11:01:51 +0900

오늘은 지난 회에 이어 멀티 테넌시의 유효화와 테넌트 작성에 대해서 소개를 하다로고 하겠습니다.

작업은 각 제품별로 실시할 필요가 있습니다.

vRSLCM：멀티 테넌시 기능의 유효화와 테넌트 작성
vRA：테넌트에 리소스(VPZ, Flavor, Image) 할당
vIDM：테넌트 인증에 필요한 디렉토리 추가와 유저/그룹의 동기

「Identity and Tenant Management」의 「Tenant Management」에서 「ENABLE TENANCY」를 실행합니다. (이 페이지에는 ~~스트레스없이~~ 에러없이 구성하기 위한 확인 사항이 기재되어 있으므로 유효화전에 반드시 확인하시길...)

인증서 업데이트시처럼 인벤토리 정보의 동기와 스냅숏을 작성합니다. 인벤토리 정보의 동기는 유효화 작업에 필수 조작이기 때문에 실시하지 않으면 다음으로 넘어갈 수 없습니다.

vIDM의 마스터 테넌트 이름을 입력합니다. 마스터 테넌트 이름은 지난 회에 DNS 서버에서 작성한 "멀티 테넌시 디폴트 vIDM이름"으로 멀티 테넌시 유효화로 인해 리다이렉트되어지는 디폴트 vIDM 이름을 대신하게 되죠. 이 마스터 테넌트 vDIM에 재등록할 제품으로 vRA을 선택합니다.

멀티 테넌시의 유효화가 실행됩니다. 진행 상태는 「Requests」에서 확인할 수 있습니다.

vIDM의 인증 프로바이더 업데이트나 vRA의 구성 등 유효화에 걸린 시간은 30분 정도였던거 같습니다.

유효화가 정상적으로 끝났으면 「Tenant Management」에서 테넌트를 작성할 수 있게 됩니다. 만들어 보도록 하죠.

테넌트 작성에 필요한 정보를 입력합니다. 여기서 입력하는 정보는 필수 항목이기 때문에 모두 입력을 합니다. 이중에서도 중요한 정보는 아래와 같습니다.

Tenant Name：지난 회 DNS에서 작성한 CNAME
Username：작성한 테넌트의 디폴트 관리자

다음에는 마스터 테넌트로부터 이행이 필요한 디렉토리를 추가합니다. 없으면 아무런 설정없이 다음으로 넘어갑니다. 테넌트를 작성한 뒤에도 디렉토리를 추가할 수 있습니다.

테넌트에서 이용할 제품을 선택합니다. 물론 vRA입니다.

「PRECHECK」을 실시후 실패나 경고가 없는 것을 확인합니다. 참고로 지난 회의 작업(DNS나 인증서) 관련에 문제가 있다면 여기서 실패를 합니다. 이 실패나 경고를 무시하고 진행을 할 경우 vRA의 이름 확인이 정상적으로 이루어지지 않아 서비스가 시작하지 않게 될 수 있습니다. 최악의 경우는 vRA의 재도입이 필요하게 됩니다. (；´Д｀) 뭐, DNS 서버에서 CNAME을 삭제하면 일단 vRA 서비스는 시작됩니다만 한번 실패한 멀티 테넌시의 유효화는 꽤 높은 확율로 실패합니다. 제 경우는 vIDM의 레코드와 vRA의 CNAME에서 "-(하이픈)"과 ".(도트)"를 틀리게 설정한 탓에 여기서 실패했었죠. 흐음...

그럼 테넌트를 만들겠습니다.

테넌트 작성 상태는 「Requests」에서 확인을 할 수 있습니다.

테넌트 작성은 몇분 않걸립니다.

테넌트가 만들어졌습니다. 제 경우는 테넌트를 2개 더 만들었습니다. :)

작성한 테넌트에서는 "테넌트 관리가", "디렉토리", "제품의 연결"을 조작할 수 있습니다. 여기서 추가하는 디렉토리는 마스터 테넌트에 추가되어있는 디렉토리가 후보로써 표시됩니다. vRSLCM의 「Tenant Management」에서 디렉토리를 인증 프로바이더로 추가할 수 없습니다. 또한 다른 테넌트에서도 같은 디렉토리를 추가하지 않는한 해당 디렉토리의 유저나 그룹이 다른 테넌트에서 이용되는 일은 없습니다.

테넌트에 접근해 보겠습니다. 이번에 작성한 테넌트의 주소는 지난 회 작성한 "CNAME(테넌트 이름).vRA FQDN"이 됩니다. 여기서의 예로써는 terran.vra-23.kiiro2.lab 이 테넌트의 주소가 됩니다.

웹 브라우저에서 terran.vra-23.kiiro2.lab 에 접근하면 vRA의 톱페이지가 표시될 겁니다. 로그인 화면으로 이동해 보겠습니다.

인증 프로바이더인 vIDM로 리다이렉트됩니다만 그 주소는 지난 회 작성한 vIDM의 테넌트 주소인 terran.kiiro2.lab 인 것을 확인할 수 있죠.

정상적으로 로그인되어 terran.vra-23.kiiro2.lab 의 클라우드 서비스 콘솔이 표시되었습니다. 이걸로 테넌트의 작성은 끝입니다.

2회에 걸쳐 멀티 테넌시에 대해 소개를 하려고 했습니다만 의외로 길어졌습니다. 따라서 추가로 1회를 늘려 다음 회에는 작성한 테넌트에 vRA의 리소스를 할당하는 순서에 대해 소개를 하도록 하겠습니다.

그럼...