이전의 알려진 문제는 다음과 같이 그룹화되어 있습니다.
- vCenter 업그레이드/마이그레이션 사전 확인이 "예기치 않은 오류 87"과 함께 실패함
STS(Security Token Service) 인증서에 SAN(주체 대체 이름) 필드가 포함되어 있지 않으면 vCenter Server 업그레이드/마이그레이션 사전 확인이 실패합니다. 이 상황은 vCenter 5.5 Single Sign-on 인증서를 SAN 필드가 없는 사용자 지정 인증서로 교체하고 vCenter Server 7.0으로 업그레이드하려고 할 때 발생합니다. 업그레이드 시 STS 인증서가 유효하지 않은 것으로 간주되고 사전 확인은 업그레이드 프로세스 진행을 차단합니다.
해결 방법: STS 인증서를 SAN 필드가 포함된 유효한 인증서로 바꾼 다음 vCenter Server 7.0 업그레이드/마이그레이션을 진행합니다.
- 기존 CIM 제공자를 사용하여 vSphere 7.0으로 업그레이드할 때 문제가 발생함
업그레이드 후에는 ESXi에 64비트 CIM 제공자가 필요하기 때문에 이전에 설치된 32비트 CIM 제공자의 작동이 중지됩니다. 고객은 CIMPDK, NDDK(네이티브 DDK), HEXDK, VAIODK(IO 필터)와 관련된 관리 API 기능을 사용하지 못할 수 있으며 uwglibc 종속성과 관련된 오류를 볼 수 있습니다.
Syslog에서 모듈 누락을 보고합니다. "32비트 공유 라이브러리가 로드되지 않았습니다."
해결 방법: 해결 방법이 없습니다. 이 문제의 수정 방법은 벤더로부터 새로운 64비트 CIM 제공자를 다운로드하는 것입니다.
- ESXi 7.0 호스트에 7.0 업데이트 1 드라이버 설치가 실패할 수 있음
ESXi 7.0 또는 7.0b를 실행하는 호스트에는 ESXi 7.0 업데이트 1에 적용되는 드라이버를 설치할 수 없습니다.
다음과 같은 오류가 발생하여 작업이 실패합니다.
VMW_bootbank_qedrntv_3.40.4.0-12vmw.701.0.0.xxxxxxx에 vmkapi_2_7_0_0이 필요하지만 ImageProfile로 요구 사항을 충족할 수 없습니다.
Please refer to the log file for more details.
해결 방법: ESXi 호스트를 7.0 업데이트 1로 업데이트합니다. 드라이버 설치를 다시 시도합니다.
- ESXi 7.0 이전 버전에서 ESXi 7.0 업데이트 2로 업데이트하는 동안 ESXi 호스트의 UEFI 부팅이 오류로 인해 중지될 수 있음
vSphere Lifecycle Manager 패치 기준선을 사용하여 ESXi 7.0 이전 버전에서 7.0 업데이트 2로 환경을 업데이트하려고 하면 ESXi 호스트의 UEFI 부팅이 중지되고 다음과 같은 오류가 표시될 수 있습니다.
/boot.cfg 로드 중
crypto64.efi 로드 실패
치명적 오류: 15 (찾을 수 없음)
해결 방법: 자세한 내용은 VMware 기술 자료 문서 83063 및 83107을 참조하십시오.
- ESXi 호스트에서 기존 VIB를 사용 중이면 vSphere Lifecycle Manager는 새 클러스터에 시드하는 데 필요한 소프트웨어 규격을 추출할 수 없음
vCenter Server 7.0 업데이트 2를 사용하면 단일 참조 호스트에서 원하는 소프트웨어 규격을 가져와서 새 클러스터를 생성할 수 있습니다. 하지만 ESXi 호스트에서 기존 VIB를 사용 중이면 vSphere Lifecycle Manager는 클러스터를 생성한 vCenter Server 인스턴스에서 해당 호스트의 참조 소프트웨어 규격을 추출할 수 없습니다. /var/log/lifecycle.log에 다음과 같은 메시지가 표시됩니다.
020-11-11T06:54:03Z lifecycle: 1000082644: HostSeeding:499 ERROR Extract depot failed: Checksum doesn't match. Calculated 5b404e28e83b1387841bb417da93c8c796ef2497c8af0f79583fd54e789d8826, expected: 0947542e30b794c721e21fb595f1851b247711d0619c55489a6a8cae6675e796 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:366 ERROR Extract depot failed. 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:145 ERROR [VibChecksumError]
해결 방법: VMware 기술 자료 문서 83042에 설명된 단계를 따르십시오.
- ESXi를 부팅할 때마다 syslog.log에 로그 메시지의 짧은 버스트가 표시됨
ESXi 7.0 업데이트 2로 업데이트한 후에 ESXi를 부팅할 때마다 로그 메시지의 짧은 버스트가 표시될 수 있습니다.
이러한 로그는 ESXi 관련 문제를 나타내지 않으며 해당 메시지를 무시할 수 있습니다. 예:
2021-01-19T22:44:22Z watchdog-vaai-nasd: '/usr/lib/vmware/nfs/bin/vaai-nasd -f' exited after 0 seconds (quick failure 127) 1
2021-01-19T22:44:22Z watchdog-vaai-nasd: Executing '/usr/lib/vmware/nfs/bin/vaai-nasd -f'
2021-01-19T22:44:22.990Z aainasd[1000051135]: Log for VAAI-NAS Daemon for NFS version=1.0 build=build-00000 option=DEBUG
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoadFile: No entries loaded by dictionary.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "/usr/lib/vmware/config": 해당 파일 또는 디렉토리가 없습니다.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "//.vmware/config": 해당 파일 또는 디렉토리가 없습니다.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: Cannot open file "//.vmware/preferences": 해당 파일 또는 디렉토리가 없습니다.
2021-01-19T22:44:22.990Z vaainasd[1000051135]: Switching to VMware syslog extensions
2021-01-19T22:44:22.992Z vaainasd[1000051135]: Loading VAAI-NAS plugin(s).
2021-01-19T22:44:22.992Z vaainasd[1000051135]: DISKLIB-PLUGIN : Not loading plugin /usr/lib/vmware/nas_plugins/lib64: Not a shared library.
해결 방법: 없음
- vSphere Quick Boot 호환성 검사 보고서에 VIB 누락에 대한 주의 메시지가 표시됨
ESXi 7.0 업데이트 2로 업그레이드한 후 /usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py 명령을 사용하여 환경의 vSphere Quick Boot 호환성을 확인하면 셸에서 누락된 VIB에 대한 주의 메시지가 표시될 수 있습니다. 예:
Cannot find VIB(s) ... in the given VIB collection.
Ignoring missing reserved VIB(s) ..., they are removed from reserved VIB IDs.
이러한 주의는 호환성 문제를 나타내지 않습니다.
해결 방법: 누락된 VIB 메시지는 무시해도 안전하며 vSphere Quick Boot 호환성 보고에 영향을 주지 않습니다. loadESXCheckCompat 명령의 최종 출력 줄은 호스트가 호환되는지를 분명하게 나타냅니다.
- vSphere Lifecycle Manager 이미지로 관리하는 클러스터를 자동 부트스트랩하면 오류로 인해 실패함
vSphere Lifecycle Manager 이미지로 관리하는 클러스터를 자동 부트스트랩하여 상태 저장 설치를 수행하고 VMFS 파티션을 덮어쓰려고 하면 오류가 발생하여 작업이 실패합니다. 지원 번들에 다음과 같은 메시지가 표시됩니다.
2021-02-11T19:37:43Z Host Profiles[265671 opID=MainThread]: 오류: EngineModule::ApplyHostConfig. 예외: [Errno 30] Read-only file system
해결 방법: 벤더 지침에 따라 대상 호스트의 VMFS 파티션을 정리하고 작업을 다시 시도합니다. 또는 빈 디스크를 사용합니다. ESXi의 디스크 파티셔닝 유틸리티에 대한 자세한 내용은 VMware 기술 자료 문서 1036609를 참조하십시오.
- ESXCLI를 사용하여 6.5.x 및 6.7.0에서 ESXi 7.x로 업그레이드하면 공간 제한으로 인해 실패할 수 있음
esxcli software profile update 또는 esxcli software profile install ESXCLI 명령을 사용하여 6.5.x 및 6.7.0에서 ESXi 7.x로 업그레이드하면 실패할 수 있습니다. ESXi 부팅 뱅크가 이미지 프로파일의 크기보다 작을 수 있기 때문입니다. ESXi Shell 또는 PowerCLI 셸에 다음과 같은 오류가 표시됩니다.
[InstallationError]
The pending transaction requires 244 MB free space, however the maximum supported size is 239 MB.
Please refer to the log file for more details.
이 문제는 ESXCLI 명령 esxcli software vib update 또는 esxcli software vib install을 사용하여 ESXi 호스트 업그레이드를 시도할 때도 발생합니다.
해결 방법: esxcli software profile update 명령을 사용하여 ESXi 호스트를 ESXi 6.7 업데이트 1 이상으로 업데이트한 다음, 7.0 업데이트 1c로 업데이트하는 두 단계로 업그레이드를 수행할 수 있습니다. 또는 ISO 이미지와 vSphere Lifecycle Manager를 사용하여 업그레이드를 실행할 수 있습니다.
- sensord 데몬이 ESXi 호스트 하드웨어 상태를 보고하지 못함
IPMI SDR 유효성 검사의 논리 오류로 인해 sensord가 전원 공급 정보의 소스를 식별하지 못할 수 있습니다. 그 결과 vsish -e get /power/hostStats 명령을 실행하면 출력이 표시되지 않을 수 있습니다.
해결 방법: 없음
- Hitachi 스토리지 어레이에서 brcmfcoe 드라이버를 업그레이드한 후 ESXi 호스트의 연결이 끊어질 수 있음
Hitachi 스토리지 어레이에서 brcmfcoe 드라이버를 업그레이드한 후 ESXi 호스트가 부팅되지 못하고 연결이 끊어질 수 있습니다.
해결 방법: 없음.
- vCenter Server 7.0으로 업그레이드한 후 스마트 카드 및 RSA SecurID 인증이 작동하지 않을 수 있음
vCenter Server를 스마트 카드 또는 RSA SecurID 인증에 대해 구성한 경우 vSphere 7.0 업그레이드 프로세스를 시작하기 전에 https://kb.vmware.com/s/article/78057에서 VMware 기술 자료 문서를 참조하십시오. KB에 설명된 대로 해결 방법을 수행하지 않으면 다음과 같은 오류 메시지가 표시될 수 있으며 스마트 카드 또는 RSA SecurID 인증이 작동하지 않을 수 있습니다.
"스마트 카드 인증의 작동이 중지될 수 있습니다. 스마트 카드 설정이 유지되지 않을 수 있으며 스마트 카드 인증의 작동이 중지될 수 있습니다."
또는
"RSA SecurID 인증의 작동이 중지될 수 있습니다. RSA SecurID 설정이 유지되지 않을 수 있으며 RSA SecurID 인증의 작동이 중지될 수 있습니다."
해결 방법: vSphere 7.0으로 업그레이드하기 전에 https://kb.vmware.com/s/article/78057에서 VMware 기술 자료 문서를 참조하십시오.
- 외부 Platform Services Controller가 있는 vCenter Server를 6.7u3에서 7.0으로 업그레이드하면 VMAFD 오류와 함께 실패함
외부 Platform Services Controller를 사용하는 vCenter Server 배포를 업그레이드하는 경우 Platform Services Controller를 vCenter Server Appliance로 컨버전스합니다. 업그레이드가 실패하고 install.vmafd.vmdir_vdcpromo_error_21 오류가 표시되면 VMAFD firstboot 프로세스가 실패한 것입니다. VMAFD firstboot 프로세스는 VMware Directory Service 데이터베이스(data.mdb)를 소스 Platform Services Controller 및 복제 파트너 vCenter Server Appliance에서 복사합니다.
해결 방법: 외부 Platform Services Controller가 있는 vCenter Server를 업그레이드하기 전에 소스 Platform Services Controller 또는 복제 파트너 vCenter Server Appliance의 이더넷 어댑터에서 TSO(TCP 세분화 오프로드) 및 GSO(일반 세분화 오프로드)를 사용하지 않도록 설정합니다. 기술 자료 문서 https://kb.vmware.com/s/article/74678을 참조하십시오.
- vCenter Server 업그레이드 중에 스마트 카드 및 RSA SecurID 설정이 유지되지 않을 수 있음
vCenter Server 7.0으로 업그레이드한 후 RSA SecurID를 사용한 인증이 작동하지 않습니다. RSA SecurID 로그인을 사용하여 로그인하려고 하면 오류 메시지가 표시됩니다.
해결 방법: 스마트 카드 또는 RSA SecureID를 재구성합니다.
- Windows용 vCenter Server를 vCenter Server Appliance 7.0으로 마이그레이션하는 작업이 네트워크 오류 메시지와 함께 실패함
Windows용 vCenter Server를 vCenter Server Appliance 7.0으로 마이그레이션하는 작업이 실패하고 네트워크에 IP가 이미 있습니다.라는 오류 메시지가 표시됩니다. 이로 인해 마이그레이션 프로세스가 새 vCenter Server Appliance에서 네트워크 매개 변수를 구성하지 못합니다. 자세한 내용은 로그 파일을 확인하십시오. /var/log/vmware/upgrade/UpgradeRunner.log
해결 방법:
- Windows용 vCenter Server 인스턴스에서 모든 Windows 업데이트가 완료되었는지 확인하거나 마이그레이션이 완료될 때까지 Windows 자동 업데이트를 사용하지 않도록 설정합니다.
- Windows용 vCenter Server를 vCenter Server Appliance 7.0으로 마이그레이션하는 작업을 다시 시도합니다.
- max_vfs 모듈 매개 변수를 사용하여 SR-IOV 디바이스의 가상 기능 수를 구성하는 경우 변경 내용이 적용되지 않을 수 있음
vSphere 7.0에서는 예를 들어 vSphere Client를 통해 VIM(가상 인프라 관리) API를 사용하여 SR-IOV 디바이스의 가상 기능 수를 구성할 수 있습니다. 이 작업은 ESXi 호스트를 재부팅할 필요가 없습니다. VIM API 구성을 사용한 후 max_vfs 모듈 매개 변수를 사용하여 SR-IOV 가상 기능 수를 구성하려고 하면 VIM API 구성에서 변경 내용을 재정의하기 때문에 변경 내용이 적용되지 않을 수 있습니다.
해결 방법: 없음. SR-IOV 디바이스의 가상 기능 수를 구성하려면 매번 동일한 방법을 사용합니다. VIM API를 사용하거나 max_vfs 모듈 매개 변수를 사용하고 ESXi 호스트를 재부팅합니다.
- 업그레이드된 vCenter Server Appliance 인스턴스가 소스 인스턴스의 일부 보조 네트워크(NIC)를 유지하지 않음
주요 업그레이드 중 vCenter Server Appliance의 소스 인스턴스가 VCHA NIC가 아닌 여러 개의 보조 네트워크로 구성된 경우 대상 vCenter Server 인스턴스는 VCHA NIC 이외의 보조 네트워크를 유지하지 않습니다. 소스 인스턴스가 DVS 포트 그룹의 일부인 여러 NIC로 구성된 경우에는 업그레이드 중에 NIC 구성이 유지되지 않습니다. 표준 포트 그룹의 일부인 vCenter Server Appliance 인스턴스에 대한 구성이 유지됩니다.
해결 방법: 없음. 대상 vCenter Server Appliance 인스턴스에서 보조 네트워크를 수동으로 구성합니다.
- 외부 Platform Services Controller가 있는 vCenter Server를 업그레이드하거나 마이그레이션한 후 Active Directory를 사용하여 인증하는 사용자가 새로 업그레이드된 vCenter Server 인스턴스에 액세스할 수 없음
외부 Platform Services Controller가 있는 vCenter Server를 업그레이드하거나 마이그레이션한 경우 새로 업그레이드된 vCenter Server가 Active Directory 도메인에 가입되지 않았다면 Active Directory를 사용하여 인증하는 사용자는 vCenter Server 인스턴스에 액세스할 수 없게 됩니다.
해결 방법: 새 vCenter Server 인스턴스가 Active Directory 도메인에 가입되어 있는지 확인합니다. 기술 자료 문서 https://kb.vmware.com/s/article/2118543을 참조하십시오.
- Oracle 데이터베이스를 사용하여 외부 Platform Services Controller가 있는 Windows용 vCenter Server를 마이그레이션할 수 없음
Oracle 이벤트 및 작업 테이블에 ASCII가 아닌 문자열이 있는 경우 이벤트 및 작업 데이터를 내보낼 때 마이그레이션이 실패할 수 있습니다. 다음 오류 메시지가 표시됩니다. UnicodeDecodeError
해결 방법: 없음.
- ESXi 호스트를 업그레이드한 후, 호스트 프로파일 규정 준수 검사에서 비준수 상태가 표시되고 호스트 업데이트 적용 작업이 실패함
비준수 상태는 프로파일과 호스트 간의 불일치를 나타냅니다.
ESXi 7.0은 중복된 클레임 규칙을 허용하지 않지만 사용하는 프로파일에 중복된 규칙이 포함되어 있기 때문에 이러한 불일치가 발생할 수 있습니다. 예를 들어, ESXi 6.5 또는 ESXi 6.7을 버전 7.0으로 업그레이드하기 전에 호스트에서 추출한 호스트 프로파일을 사용하려고 할 때 호스트 프로파일에 시스템 기본 규칙의 중복된 클레임 규칙이 포함되어 있으면 문제가 발생할 수 있습니다.
해결 방법:
- 호스트 프로파일 문서에서 시스템 기본 규칙의 중복된 클레임 규칙을 모두 제거합니다.
- 규정 준수 상태를 확인합니다.
- 호스트에 업데이트를 적용합니다.
- 이전 단계가 도움이 되지 않으면 호스트를 재부팅합니다.
- vCenter Server 관리 인터페이스에 오류 메시지가 표시됨
vCenter Server 7.0을 설치하거나 이 버전으로 업그레이드한 후 vCenter Server 관리 인터페이스 내에서 [업데이트] 패널로 이동하면 "URL 확인 후 다시 시도"라는 오류 메시지가 표시됩니다. 오류 메시지는 [업데이트] 패널 내에서 기능을 사용하는 것을 방지하지 않으며 사용 가능한 업데이트를 보고, 스테이징하고, 설치할 수 있습니다.
해결 방법: 없음.
- Intel 82599/X540/X550 NIC에서 네트워킹 성능의 처리량이 감소함
Intel 82599EB/X540/X550 시리즈 NIC에서 네트워킹 성능을 향상시키기 위해 ixgben 드라이버에 추가된 새 대기열-쌍 기능으로 vSphere 6.7에 비해 vSphere 7.0의 일부 워크로드에서 처리량이 감소할 수 있습니다.
해결 방법: vSphere 6.7과 동일한 네트워킹 성능을 얻으려는 경우 모듈 매개 변수를 사용하여 대기열-쌍을 사용하지 않도록 설정할 수 있습니다. 대기열-쌍을 사용하지 않도록 설정하려면 다음 명령을 실행합니다.
# esxcli system module parameters set -p "QPair=0,0,0,0..." -m ixgben
명령을 실행한 후 재부팅합니다.
- AMD IOMMU가 사용 중일 때 하나 이상의 I/O 디바이스가 인터럽트를 생성하지 않음
ESXi 호스트의 I/O 디바이스가 총 512개 이상의 개별 인터럽트 소스를 제공하는 경우, 일부 소스에 AMD IOMMU에서 최대 값보다 큰 IRTE(인터럽트 재매핑 테이블 엔트리) 인덱스가 잘못 할당됩니다. 이러한 소스의 인터럽트는 손실되므로 해당 I/O 디바이스는 인터럽트가 비활성화된 것처럼 작동합니다.
해결 방법: ESXCLI 명령 esxcli system settings kernel set -s iovDisableIR -v true를 사용하여 AMD IOMMU 인터럽트 리매퍼를 사용하지 않도록 설정합니다. 명령이 적용되도록 ESXi 호스트를 재부팅합니다.
- 네트워크 어댑터에서 자동 협상을 설정할 때 디바이스가 실패 할 수 있음
일부 환경에서 esxcli network nic set -a -n vmmicx 명령을 사용하여 네트워크 어댑터에 대한 링크 속도를 자동 협상으로 설정하면 디바이스가 실패하고 재부팅해도 연결을 복구되지 못할 수 있습니다. 이 문제는 자동 협상 속도/이중 방식 시나리오가 지원되지 않는 일부 Intel X710/X722 네트워크 어댑터, SFP+ 모듈 및 물리적 스위치의 조합에만 발생합니다.
해결 방법: Intel 브랜드의 SFP+ 모듈을 사용해야합니다. 또는 DAC Direct Attach Copper) 케이블을 사용하십시오.
- PVRDMA(반가상화 RDMA) 네트워크 어댑터가 NSX 네트워킹 정책을 지원하지 않음
PVRDMA 트래픽에 사용할 NSX 분산 가상 포트를 구성하는 경우, PVRDMA 네트워크 어댑터를 통한 RDMA 프로토콜 트래픽이 NSX 네트워크 정책을 준수하지 않습니다.
해결 방법: PVRDMA 트래픽에 사용할 NSX 분산 가상 포트를 구성하지 마십시오.
- 1x100G 포트 모드로 구성된 Solarflare x2542 및 x2541 네트워크 어댑터가 vSphere 환경에서 최대 70Gbps의 처리량을 달성함
vSphere 7.0 업데이트 2는 1x100G 포트 모드로 구성된 Solarflare x2542 및 x2541 네트워크 어댑터를 지원합니다. 하지만 디바이스의 하드웨어 제한으로 인해 vSphere 환경에서 실제 처리량은 최대 70Gbps가 될 수 있습니다.
해결 방법: 없음
- NIC 재설정 후 VLAN 트래픽이 실패할 수 있음
PCI 디바이스 ID가 8086:1537인 NIC를 재설정(예: vsish -e set /net/pNics/vmnic0/reset 1 명령을 사용) 후 VLAN 태그가 지정된 패킷의 송신 및 수신이 중지될 수 있습니다.
해결 방법: NIC를 재설정하지 마십시오. 이미 문제가 발생한 경우 다음 명령을 사용하여 VLAN 기능을 복원합니다(예: vmnic0:).
# esxcli network nic software set --tagging=1 -n vmnic0
# esxcli network nic software set --tagging=0 -n vmnic0
- NetQueue 밸런서 설정을 변경하면 ESXi 호스트 재부팅 후 NetQueue가 사용되지 않도록 설정됨
esxcli/localcli network nic queue loadbalancer set -n <nicname> --<lb_setting> 명령을 사용하여 NetQueue 밸런서 설정을 변경하면 NetQueue(기본적으로 사용되도록 설정됨)가 ESXi 호스트 재부팅 후에 사용되지 않도록 설정됩니다.
해결 방법: NetQueue 밸런서 설정이 변경되고 호스트가 재부팅되면 configstorecli config current get -c esx -g network -k nics 명령을 사용하여 ConfigStore 데이터를 검색하고 /esx/network/nics/net_queue/load_balancer/enable이 예상대로 작동하는지 확인합니다.
명령을 실행하면 다음과 유사한 출력이 표시됩니다.
{
"mac": "02:00:0e:6d:14:3e",
"name": "vmnic1",
"net_queue": {
"load_balancer": {
"dynamic_pool": true,
"enable": true
}
},
"virtual_mac": "00:50:56:5a:21:11"
}
출력이 예상과 다르면(예: "load_balancer": "enable": false") 다음 명령을 실행합니다.
esxcli/localcli network nic queue loadbalancer state set -n <nicname> -e true
- NetIOC(Network I/O Control)를 사용하도록 설정하면 처리량이 높은 가상 시스템에서 네트워크 성능 저하가 발생할 수 있음
NetIOC를 사용하도록 설정하고 vSphere 6.7에서 vSphere 7.0으로 업그레이드하는 경우 높은 네트워크 처리량이 필요한 가상 시스템에서 처리량 저하가 발생할 수 있습니다.
해결 방법: 여러 환경을 사용하도록 설정하려면 ethernetx.ctxPerDev 설정을 조정합니다.
- IPv6 트래픽이 IPsec을 사용하여 VMkernel 포트를 통과하지 못함
VMkernel 포트를 한 포트 그룹에서 다른 포트 그룹으로 마이그레이션할 때 IPv6 트래픽이 IPsec을 사용하여 VMkernel 포트를 통과하지 않습니다.
해결 방법: 영향받는 서버에서 IPsec SA(보안 연결)를 제거한 다음 SA를 다시 적용합니다. IPsec SA를 설정 및 제거하는 방법을 알아보려면 vSphere 보안 설명서를 참조하십시오.
- CPU 사용량 증가에 따라 ESX 네트워크 성능이 향상될 수 있음
CPU 사용량에 따라 ESX 네트워크 성능이 향상될 수 있습니다.
해결 방법: 1개의 rx 디스패치 대기열만 있는 네트워크 인터페이스를 제거하고 추가합니다. 예:
esxcli network ip interface remove --interface-name=vmk1
esxcli network ip interface add --interface-name=vmk1 --num-rxqueue=1
- 무중단 추가, 무중단 제거 또는 Storage vMotion 후 VM에서 이더넷 트래픽이 손실될 수 있음
무중단 추가, 무중단 제거 또는 Storage vMotion 후 VM의 이더넷 트래픽 수신이 중단될 수 있습니다. 이 문제는 VNIC의 업링크에서 SR-IOV를 사용하도록 설정한 VM에 영향을 줍니다. 가상 네트워크의 업링크가 Mellanox RDMA 지원 NIC이고 RDMA 네임스페이스가 구성된 경우 PVRDMA 가상 NIC에서 이 문제가 발생합니다.
해결 방법: VM의 영향을 받는 이더넷 NIC를 무중단 제거하고 무중단 추가하여 트래픽을 복원할 수 있습니다. Linux 게스트 운영 체제에서 네트워크를 다시 시작하는 경우 문제가 해결될 수도 있습니다. 이러한 해결 방법이 효과가 없다면 VM을 재부팅하여 네트워크 연결을 복원할 수 있습니다.
- 정적 IP 주소로 배포된 VCSA의 IP 주소를 변경하려면 DNS 레코드를 미리 생성해야 함
DDNS의 도입으로 DNS 레코드 업데이트는 DHCP 구성 네트워킹으로 배포된 VCSA에 대해서만 작동합니다. VAMI를 통해 vCenter Server의 IP 주소를 변경하는 동안 다음 오류가 표시됩니다.
지정된 IP 주소를 지정된 호스트 이름으로 확인할 수 없습니다.
해결 방법: 가능한 해결 방법에는 두 가지가 있습니다.
- 동일한 FQDN과 원하는 IP 주소로 추가 DNS 항목을 생성합니다. VAMI에 로그인하고 단계에 따라 IP 주소를 변경합니다.
- SSH를 사용하여 VCSA에 로그인합니다. 다음 스크립트를 실행합니다.
./opt/vmware/share/vami/vami_config_net
옵션 6을 사용하여 eth0의 IP 주소를 변경합니다. 변경 후 다음 스크립트를 실행합니다.
./opt/likewise/bin/lw-update-dns
VCSA의 모든 서비스를 다시 시작하여 DNS 서버의 IP 정보를 업데이트합니다.
- NSX Manager에서 해당 논리적 스위치를 삭제한 후 NSX DVPG(NSX 분산 가상 포트 그룹)를 제거하는 데 몇 초 정도 걸릴 수 있습니다.
논리적 스위치의 수가 증가할수록 NSX Manager에서 해당 논리적 스위치를 삭제한 후 vCenter Server의 NSX DVPG를 제거하는 데 더 많은 시간이 걸릴 수 있습니다. 12000개의 논리적 스위치가 있는 환경에서는 vCenter Server에서 NSX DVPG를 삭제하는 데 약 10초 정도가 소요됩니다.
해결 방법: 없음.
- 다수의 NSX 분산 가상 포트 그룹이 생성되면 Hostd가 메모리 부족으로 인해 실패합니다.
vSphere 7.0에서 NSX 분산 가상 포트 그룹은 불투명 네트워크보다 훨씬 많은 양의 메모리를 소비합니다. 이러한 이유 때문에 NSX 분산 가상 포트 그룹은 동일한 양의 메모리가 지정된 불투명 네트워크와 동일한 규모를 지원할 수 없습니다.
해결 방법: NSX 분산 가상 포트 그룹 사용을 지원하려면 ESXi 호스트의 메모리 양을 늘리십시오. 시스템에 VM을 지원하기에 충분한 메모리가 있는지 확인하는 경우, 다음 명령을 사용하여 hostd의 메모리를 직접 늘일 수 있습니다.
localcli --plugin-dir /usr/lib/vmware/esxcli/int/ sched group setmemconfig --group-path host/vim/vmvisor/hostd --units mb --min 2048 --max 2048
이렇게 하면 환경의 VM에 대해 일반적으로 예약된 메모리를 hostd가 사용할 수 있습니다. 그러면 ESXi 호스트가 지원할 수 있는 VM 수를 줄이는 데 영향을 줄 수 있습니다.
- 네트워크 예약이 VM에 구성된 경우 DRS가 vMotion를 잘못 시작할 수 있음
네트워크 예약이 VM에 구성된 경우, DRS는 지정된 요구 사항을 충족하는 호스트로만 VM을 마이그레이션할 것으로 예상됩니다. NSX 전송 노드가 있는 클러스터에서, 일부 전송 노드는 N-VDS(NSX-T 가상 Distributed Switch)를 사용하여 전송 영역에 가입하고 다른 노드는 VDS(vSphere Distributed Switch) 7.0을 사용하여 가입하면, DRS가 vMotion을 잘못 시작할 수 있습니다. 이런 문제는 다음과 같은 경우에 발생할 수 있습니다.
- VM이 네트워크 예약으로 구성된 NSX 논리적 스위치에 연결됩니다.
- 일부 전송 노드는 N-VDS를 사용하여 전송 영역에 가입하고 다른 노드는 VDS 7.0을 사용하여 가입하거나, 전송 노드가 다른 VDS 7.0 인스턴스를 통해 전송 영역에 가입합니다.
해결 방법: 모든 전송 노드가 N-VDS 또는 동일한 VDS 7.0 인스턴스를 통해 전송 영역에 가입되도록 합니다.
- NSX 포트 그룹에 vmknic(VMkernel NIC)를 추가하면 vCenter Server는 "상태 비저장 호스트의 NSX 포트 그룹에 VMkernel 어댑터를 연결하는 작업은 지원되지 않습니다. 대신 분산 포트 그룹을 사용하십시오."라는 오류를 보고합니다.
- DVS(분산 가상 스위치)의 상태 비저장 ESXi에 대해서는 NSX 포트 그룹의 vmknic가 차단됩니다. 분산 포트 그룹을 대신 사용해야 합니다.
- DVS의 상태 저장 ESXi에 대해서는 NSX 포트 그룹의 vmknic가 지원되지만, NSX 포트 그룹에서 vmknic를 사용하는 경우 vSAN에 문제가 발생할 수 있습니다.
해결 방법: 동일한 DVS의 분산 포트 그룹을 사용합니다.
- QLogic 4x10GE QL41164HFCU CNA에 대해 vCenter에서 SRIOV를 사용하도록 설정하지 못할 수 있음
QLogic 4x10GE QL41164HFCU CNA를 사용하는 경우, 물리적 네트워크 어댑터에 대한 설정 편집 대화 상자로 이동하여 SR-IOV를 사용하도록 설정하려고 하면 작업이 실패할 수 있습니다. SR-IOV를 사용하도록 설정하려고 하면 ESXi 호스트의 네트워크가 중단될 수 있습니다.
해결 방법: ESXi 호스트에서 다음 명령을 사용하여 SRIOV를 사용하도록 설정합니다.
esxcfg-module
- DRS(Distributed Resource Scheduler)를 사용하는 클러스터의 호스트가 다른 VDS(가상 Distributed Switch) 또는 NVDS(NSX-T 가상 Distributed Switch) 및 VDS의 조합을 사용하는 NSX-T 네트워킹에 가입하는 경우 vCenter Server가 실패함
vSphere 7.0에서, DRS 클러스터를 사용하는 vSphere VDS에서 NSX-T 네트워킹을 사용하는 경우 호스트가 동일한 VDS 또는 NVDS를 사용하는 NSX 전송 영역에 가입하지 않으면 vCenter Server가 실패할 수 있습니다.
해결 방법: DRS 클러스터의 호스트를 동일한 VDS 또는 NVDS를 사용하는 NSX 전송 영역에 가입합니다.
- SmartPQI 컨트롤러를 사용하는 HPE Gen10 서버에서 무중단 제거 및 무중단 삽입 후 VMFS 데이터스토어가 자동으로 마운트되지 않음
확장기 없이 SmartPQI 컨트롤러를 사용하는 HPE Gen10 서버에서 SATA 디스크를 무중단 제거하고 동일한 시스템의 다른 디스크 베이로 다시 무중단 삽입하는 경우 또는 여러 디스크를 무중단 제거하고 다른 순서로 다시 무중단 삽입한 경우에는 종종 새 로컬 이름이 디스크에 할당됩니다. 디바이스 이름이 변경되었기 때문에 해당 디스크의 VMFS 데이터스토어가 스냅샷으로 나타나고 자동으로 다시 마운트되지 않습니다.
해결 방법: 없음. SmartPQI 컨트롤러는 순서가 지정되지 않은 무중단 제거 및 무중단 삽입 작업을 지원하지 않습니다.
- 모든 활성 경로의 오류로 인해 ESXi가 디바이스에 대한 I/O를 종료할 수 있음
경우에 따라 NVMeOF 디바이스에 대한 모든 활성 경로는 링크 문제 또는 컨트롤러 상태에 따른 I/O 오류를 등록합니다. 경로 중 하나의 상태가 [비활성]으로 변경될 때 많은 오류가 표시되면 HPP(High Performance Plug-in)가 다른 경로를 선택하지 않을 수 있습니다. 결과적으로 I/O가 실패합니다.
해결 방법: /Misc/HppManageDegradedPaths 구성 옵션을 사용하지 않도록 설정하여 I/O를 차단 해제합니다.
- NVMe 기반 VMFS 데이터스토어에 대한 VOMA 검사가 오류와 함께 실패함
VOMA 검사는 NVMe 기반 VMFS 데이터스토어에 대해 지원되지 않으며 다음 오류와 함께 실패합니다.
ERROR: 디바이스를 예약하지 못했습니다. 기능이 구현되지 않음
예:
# voma -m vmfs -f check -d /vmfs/devices/disks/: <partition#>
검사 모드에서 VMFS Checker 버전 2.1 실행 중
LVM 메타데이터 초기화 중, 기본 검사가 수행됩니다.
파일 시스템 활동을 확인하는 중
파일 시스템 작동 여부 검사 수행 중...|VMFS-6 호스트 활동 검색 중(4096바이트/HB, 1024HB).
ERROR: 디바이스를 예약하지 못했습니다. 기능이 구현되지 않음
VMFS 볼륨 검사 중단 중
VOMA가 디바이스를 검사하지 못함: 일반 오류
해결 방법: 없음. VMFS 메타데이터를 분석하려면 -l 옵션을 사용하여 수집한 후 VMware 고객 지원에 전달합니다. 덤프를 수집하는 명령은 다음과 같습니다.
voma -l -f dump -d /vmfs/devices/disks/:<partition#>
- VM 재구성 API를 사용하여 암호화된 가상 시스템에 암호화된 First Class Disk를 연결하면 오류와 함께 실패할 수 있음
FCD와 VM이 서로 다른 암호화 키로 암호화된 경우 VM 재구성 API를 사용하여 암호화된 FCD를 암호화된 VM에 연결하려고 하면 다음 오류 메시지와 함께 작업이 실패합니다.
키 또는 암호가 잘못되었기 때문에 디스크의 암호를 해독할 수 없습니다.
해결 방법: 암호화된 FCD를 암호화된 VM에 연결하려면 VM 재구성 API가 아닌 attachDisk API를 사용합니다.
- ESXi 호스트의 확장된 VMFS 데이터스토어 비헤드 익스텐트가 PDL(영구적 디바이스 손실) 상태로 전환되면 ESXi 호스트가 응답하지 않는 상태가 될 수 있음
이 문제는 확장된 VMFS 데이터스토어의 비헤드 익스텐트가 헤드 익스텐트와 함께 실패할 경우에는 발생하지 않습니다. 이 경우 전체 데이터스토어에 액세스할 수 없게 되고 더 이상 I/O를 허용하지 않습니다.
반면 비헤드 익스텐트만 실패하고 헤드 익스텐트는 액세스 가능한 상태로 유지되면 데이터스토어 하트비트가 정상 상태로 표시됩니다. 호스트와 데이터스토어 간의 I/O는 계속됩니다. 그러나 실패한 비헤드 익스텐트에 의존하는 I/O는 마찬가지로 모두 실패합니다. 다른 I/O 트랜잭션은 실패한 I/O가 해결될 때까지 기다리는 동안 누적될 수 있으며 이로 인해 호스트가 응답하지 않는 상태가 될 수 있습니다.
해결 방법: 이 문제를 해결하려면 비헤드 익스텐트의 PDL 상태를 수정합니다.
- 가상 NVMe 컨트롤러는 Windows 10 게스트 운영 체제의 기본 디스크 컨트롤러입니다.
가상 NVMe 컨트롤러는 하드웨어 버전 15 이상을 사용할 때 다음 게스트 운영 체제의 기본 디스크 컨트롤러입니다.
Windows 10
Windows Server 2016
Windows Server 2019
가상 NVMe 컨트롤러를 사용하는 경우 일부 기능을 사용하지 못할 수 있습니다. 자세한 내용은 https://kb.vmware.com/s/article/2147714를 참조하십시오.
참고: 일부 클라이언트는 이전 기본값인 LSI Logic SAS를 사용합니다. 여기에는 ESXi Host Client 및 PowerCLI가 포함됩니다.
해결 방법: 가상 NVMe에서 사용할 수 없는 기능이 필요한 경우 VMware PVSCSI(VMware 반가상화 SCSI) 또는 LSI Logic SAS로 전환합니다. VMware PVSCSI(VMware 반가상화 SCSI) 사용에 대한 자세한 내용은 https://kb.vmware.com/s/article/1010398을 참조하십시오.
- ESXi 호스트를 vSphere 7.0으로 업그레이드한 후 중복된 코어 클레임 규칙이 있으면 예기치 않은 동작이 발생할 수 있음
클레임 규칙은 특정 스토리지 디바이스 경로를 소유하는 다중 경로 지정 플러그인(예: NMP, HPP 등)을 결정합니다. ESXi 7.0은 중복된 클레임 규칙을 지원하지 않습니다. 하지만 레거시 릴리스에서 업그레이드를 통해 상속된 기존 클레임 규칙에 중복 규칙을 추가하는 경우 ESXi 7.0 호스트에서 경고하지 않습니다. 중복 규칙을 사용하면 의도하지 않은 플러그인이 스토리지 디바이스를 클레임할 수 있으며 이로 인해 예기치 않은 결과가 발생할 수 있습니다.
해결 방법: 중복된 코어 클레임 규칙을 사용하지 마십시오. 새 클레임 규칙을 추가하기 전에 일치하는 기존 클레임 규칙이 있으면 삭제하십시오.
- 규정 준수 상태 필터가 설정된 CNS 쿼리를 완료하는 데 비정상적으로 오랜 시간이 걸릴 수 있음
CNS QueryVolume API를 사용하면 볼륨 상태 및 규정 준수 상태와 같은 CNS 볼륨에 대한 정보를 가져올 수 있습니다. 개별 볼륨의 규정 준수 상태를 확인하면 결과를 빠르게 얻을 수 있습니다. 그러나 CNS QueryVolume API를 호출하여 여러 볼륨(수십 또는 수백 개)의 규정 준수 상태를 확인할 때에는 쿼리가 느리게 실행될 수 있습니다.
해결 방법: 대량의 쿼리를 사용하지 않습니다. 규정 준수 상태를 얻어야 하는 경우 한 번에 하나의 볼륨을 쿼리하거나 쿼리 API의 볼륨 수를 20개 이하로 제한합니다. 쿼리를 사용하는 동안에는 최상의 성능을 얻기 위해 다른 CNS 작업을 실행하지 않습니다.
- NVMe over Fabrics 네임스페이스 또는 디바이스로 지원되는 VMFS 데이터스토어가 APD 또는 PDL 장애에서 복구된 후 영구적 액세스 불가 상태가 될 수 있음
ESXi 호스트의 VMFS 데이터스토어가 NVMe over Fabrics 네임스페이스 또는 디바이스로 지원되면, APD(모든 경로 다운) 또는 PDL(Permanent Device Loss) 오류가 발생한 경우 복구 후에도 데이터스토어에 액세스하지 못할 수 있습니다. ESXi 호스트와 vCenter Server 시스템 중 하나에서 데이터스토어에 액세스할 수 없습니다.
해결 방법: 이 상태에서 복구하려면 호스트 또는 클러스터 수준에서 다시 검색을 수행합니다. 자세한 내용은 스토리지 다시 검색 수행을 참조하십시오.
- 삭제된 CNS 볼륨이 일시적으로 CNS UI에 있는 것처럼 나타날 수 있음
CNS 볼륨을 지원하는 FCD 디스크를 삭제한 후에도 볼륨이 여전히 CNS UI에 있는 것처럼 나타날 수 있습니다. 하지만 볼륨 삭제 시도는 실패합니다. 다음과 유사한 오류 메시지가 표시될 수 있습니다.
참조된 개체 또는 항목을 찾을 수 없습니다.
해결 방법: 다음에 전체 동기화를 수행하면 불일치 문제가 해결되고 CNS UI가 올바로 업데이트됩니다.
- 여러 CNS 볼륨을 동일한 포드에 연결하려고 시도하면 종종 오류와 함께 작업이 실패할 수 있음
여러 볼륨을 동일한 포드에 동시에 연결하는 경우 연결 작업에서 종종 동일한 컨트롤러 슬롯을 선택합니다. 그 결과 하나의 작업만 성공하고 다른 볼륨 마운트는 실패합니다.
해결 방법: 노드 VM에 사용 가능한 컨트롤러 슬롯이 있는 경우 Kubernetes가 실패한 작업을 재시도하면 작업이 성공합니다.
- 특정 상황에서, CNS 작업이 실패했는데도 vSphere Client에서 작업 상태가 성공으로 나타남
이러한 문제는 예를 들어 호환되지 않는 스토리지 정책을 사용하여 CNS 볼륨을 생성하는 경우에 발생할 수 있습니다. 작업이 실패했지만 vSphere Client는 작업 상태를 성공으로 표시합니다.
해결 방법: vSphere Client에서 작업 상태가 성공으로 나타난다고 해서 CNS 작업이 성공했다고 단정할 수 없습니다. 작업의 성공 여부를 확인하려면 그 결과를 검토해야 합니다.
- CNS 영구 볼륨에 대한 삭제 작업에 실패하면 vSphere 데이터스토어에서 볼륨이 삭제되지 않은 상태로 남을 수 있음
이 문제는 CNS Delete API가 포드에 아직 연결되어 있는 영구 볼륨을 삭제하려고 할 때 발생할 수 있습니다. 예를 들어, 포드가 실행되는 Kubernetes 네임스페이스를 삭제하면, 결과적으로, CNS에서 볼륨이 지워지고 CNS 쿼리 작업이 볼륨을 반환하지 않습니다. 하지만 볼륨은 데이터스토어에 계속 상주하며, CNS Delete API 작업을 반복해도 삭제할 수 없습니다.
해결 방법: 없음.
- PNID 변경 후 벤더 제공자가 오프라인으로 전환됨
vCenter IP 주소를 변경하면(PNID 변경) 등록된 벤더 제공자가 오프라인으로 전환됩니다.
해결 방법: 벤더 제공자를 다시 등록합니다.
- 가상 시스템의 크로스 vCenter 마이그레이션이 오류와 함께 실패함
크로스 vCenter vMotion을 사용하여 VM의 스토리지 및 호스트를 다른 vCenter Server 인스턴스로 이동하는 경우 현재 상태에서 허용되지 않는 작업입니다. 오류가 표시될 수 있습니다.
이 오류는 VM에 암호화 또는 기타 IO 필터 규칙과 같은 호스트 기반 규칙이 포함된 스토리지 정책이 할당되어 있는 경우 호스트 선택 단계 후 그리고 데이터스토어 선택 단계 전에 UI 마법사에 표시됩니다.
해결 방법: 호스트 기반 규칙 없이 VM 및 해당 디스크를 스토리지 정책에 할당합니다. 소스 VM이 암호화된 경우 VM의 암호를 해독해야 할 수 있습니다. 그런 다음 크로스 vCenter vMotion 작업을 다시 시도합니다.
- vCenter UI, 호스트 UI 및 MOB의 [하드웨어 상태] 탭에서 스토리지 센서 정보에 잘못된 값이 표시됨
vCenter UI에서 호스트 > 모니터 > 하드웨어 상태 > 스토리지 센서로 이동했을 때 스토리지 정보에 잘못된 값 또는 알 수 없는 값이 표시됩니다. 호스트 UI 및 MOB 경로 "runtime.hardwareStatusInfo.storageStatusInfo"에서도 같은 문제가 발생합니다.
해결 방법: 없음.
- vSphere UI 호스트 고급 설정에 현재 제품 잠금 관리자 위치와 기본값이 빈 상태로 표시됨
vSphere UI 호스트 고급 설정에 현재 제품 잠금 관리자 위치와 기본값이 빈 상태로 표시됩니다. 실제로는 제품 위치 symlink가 생성되고 유효하므로 서로 일치하지 않습니다. 이는 사용자에게 혼란을 줍니다. 기본값은 UI에서 수정할 수 없습니다.
해결 방법: 사용자는 호스트에서 esxcli 명령을 사용하여 아래와 같이 현재 제품 잠금 관리자 위치 기본값을 수정할 수 있습니다.
1. 다음을 사용하여 기존 제품 잠금 관리자 위치 설정을 제거합니다. "esxcli system settings advanced remove -o ProductLockerLocation"
2. 적절한 기본값으로 제품 잠금 관리자 위치 설정을 다시 추가합니다.
2. a. ESXi가 전체 설치인 경우 기본값은 "/locker/packages/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/locker/packages/vmtoolsRepo"입니다.
2. b. ESXi가 autodeploy와 같은 PXEboot 구성인 경우 기본값은: "/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/vmtoolsRepo"입니다.
다음 명령을 실행하여 위치를 자동으로 파악합니다. export PRODUCT_LOCKER_DEFAULT=`readlink /productLocker`
다음 설정을 추가합니다. esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s $PRODUCT_LOCKER_DEFAULT
단일 명령을 실행하여 2단계에서 위의 모든 단계를 결합할 수 있습니다.
esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s `readlink /productLocker`
- vCenter Cloud Gateway가 SDDC에 연결된 경우, 온-프레미스 vSphere Client에 연결된 SDDC(소프트웨어 정의 데이터 센터) vCenter Server 인스턴스가 표시됨
vCenter Cloud Gateway가 온-프레미스 vCenter Server와 동일한 환경에 배포되고 SDDC에 연결되면 온-프레미스 vSphere Client에 SDDC vCenter Server가 나타납니다. 이것은 예기치 않은 동작이며 연결된 SDDC vCenter Server는 무시해야 합니다. 연결된 SDDC vCenter Server와 관련된 모든 작업은 vCenter Cloud Gateway 내에서 실행 중인 vSphere Client에서 수행해야 합니다.
해결 방법: 없음.
- 모든 호스트의 이미지 설정 및 업데이트를 집합적으로 관리하도록 이미 설정된 클러스터에서 NSX-T를 사용하도록 설정할 수 없음
NSX-T는 이미지 관리를 위한 vSphere Lifecycle Manager 기능과 호환되지 않습니다. 클러스터에 있는 모든 호스트의 이미지 설정 및 업데이트를 집합적으로 관리하도록 클러스터를 설정하면 해당 클러스터에서 NSX-T를 사용하도록 설정할 수 없습니다. 그러나 이 클러스터에 NSX Edge를 배포할 수 있습니다.
해결 방법: 기준선을 사용하여 관리할 수 있는 새 클러스터로 호스트를 이동하고 이 새 클러스터에서 NSX-T를 사용하도록 설정합니다.
- vSphere Lifecycle Manager 및 vSAN 파일 서비스를 vSphere 7.0 릴리스의 vSAN 클러스터에서 동시에 사용하도록 설정할 수 없음
클러스터에서 vSphere Lifecycle Manager를 사용하도록 설정한 경우에는 동일한 클러스터에서 vSAN 파일 서비스를 사용하도록 설정할 수 없으며 그 반대의 경우도 마찬가지입니다. VSAN 파일 서비스를 사용하도록 설정된 클러스터에서 vSphere Lifecycle Manager를 사용하도록 설정하려면 먼저 vSAN 파일 서비스를 사용하지 않도록 설정하고 작업을 다시 시도하십시오. 단일 이미지로 관리되는 클러스터로 전환하는 경우 해당 클러스터에서 vSphere Lifecycle Manager를 사용하지 않도록 설정할 수 없습니다.
해결 방법: 없음.
- 하드웨어 지원 관리자를 사용할 수 없는 경우 vSphere HA(High Availability) 기능이 영향을 받음
펌웨어 및 드라이버 추가 기능이 선택되고 vSphere HA가 사용되도록 설정된, 단일 이미지로 관리하는 클러스터에 대해 하드웨어 지원 관리자를 사용할 수 없는 경우 vSphere HA 기능이 영향을 받습니다. 다음 오류가 발생할 수 있습니다.
- 클러스터에서 vSphere HA를 구성하지 못했습니다.
- 호스트에서 vSphere HA 에이전트의 구성을 완료할 수 없습니다.
클러스터에 HA VIB를 적용하는 중 오류 발생.
- vSphere HA에 업데이트 적용 실패:
일반 시스템 오류가 발생했습니다. 유효 구성 요소 맵을 가져오지 못했습니다.
- vSphere HA를 사용하지 않도록 설정하는 작업 실패: [솔루션 삭제] 작업에 실패했습니다.
일반 시스템 오류가 발생했습니다. 디포 또는 하드웨어 지원 관리자에서 하드웨어 지원 패키지를 찾을 수 없습니다.
해결 방법:
- 하드웨어 지원 관리자를 일시적으로 사용할 수 없는 경우 다음 단계를 수행합니다.
- 하드웨어 지원 관리자를 vCenter Server에 다시 연결 합니다.
- [호스트 및 클러스터] 메뉴에서 클러스터를 선택합니다.
- [구성] 탭을 선택합니다.
- [서비스]에서 [vSphere 가용성]을 클릭합니다.
- vSphere HA를 다시 사용하도록 설정합니다.
- 하드웨어 지원 관리자를 영구적으로 사용할 수 없는 경우 다음 단계를 수행합니다.
- 이미지 규격에서 하드웨어 지원 관리자 및 하드웨어 지원 패키지를 제거합니다.
- vSphere HA를 다시 사용하도록 설정합니다.
- [호스트 및 클러스터] 메뉴에서 클러스터를 선택합니다.
- [업데이트] 탭을 선택합니다.
- [편집]을 클릭합니다.
- 펌웨어 및 드라이버 추가 기능을 제거하고 [저장]을 클릭합니다.
- [구성] 탭을 선택합니다.
- [서비스]에서 [vSphere 가용성]을 클릭합니다.
- vSphere HA를 다시 사용하도록 설정합니다.
- vSphere Lifecycle Manager에서의 업데이트 적용 프로세스 후 클러스터에서 I/OFilter가 제거되지 않음
vSphere Lifecycle Manager에서 클러스터에 업데이트를 적용하여 클러스터에서 I/OFilter를 제거하면 다음 오류 메시지와 함께 작업이 실패합니다. iofilter XXX이(가) 이미 있습니다. iofilter는 계속 설치된 것으로 나열됩니다.
해결 방법:
- vCenter Server 관리 개체(IoFilterManager)에서 IOFilter API
UninstallIoFilter_Task를 호출합니다.
- vSphere Lifecycle Manager에서 클러스터에 업데이트를 적용합니다.
- vCenter Server 관리 개체(IoFilterManager)에서 IOFilter API
ResolveInstallationErrorsOnCluster_Task를 호출하여 데이터베이스를 업데이트합니다.
- vSphere Lifecycle Manager에서 vSphere HA가 사용되도록 설정된 클러스터에 업데이트를 적용하는 동안 호스트를 추가하면 vSphere HA가 오류 상태가 됨
vSphere HA가 사용되도록 설정된 클러스터에 대한 업데이트 적용 프로세스 중에 ESXi 호스트를 하나 또는 여러 개 추가하면 다음과 같은 오류 메시지가 표시됩니다. 클러스터에 HA VIB를 적용하는 중 오류 발생.
해결 방법: 클러스터 업데이트 적용 작업을 완료한 후 다음 작업 중 하나를 수행합니다.
- 실패한 ESXi 호스트를 마우스 오른쪽 버튼으로 클릭하고 vSphere HA 재구성을 선택합니다.
- 클러스터에 대해 vSphere HA를 사용하지 않도록 설정했다가 다시 사용하도록 설정합니다.
- vSphere Lifecycle Manager에서 vSphere HA가 사용되도록 설정된 클러스터에 업데이트를 적용하는 동안 vSphere HA를 사용하지 않도록 설정했다가 다시 사용하도록 설정하면 vSphere HA가 오류 상태가 됨
클러스터에 대한 업데이트 적용 프로세스 중 vSphere HA를 사용하지 않도록 설정했다가 다시 사용하도록 설정하면 호스트에 vSphere HA VIB가 설치되어 있지 않음을 보고하는 vSphere HA 상태 점검으로 인해 업데이트 적용 프로세스가 실패할 수 있습니다. 다음과 같은 오류 메시지가 표시될 수 있습니다. 클러스터에 필요한 이미지 규격 설정 실패.
해결 방법: 클러스터 업데이트 적용 작업을 완료한 후 클러스터에 대해 vSphere HA를 사용하지 않도록 설정했다가 다시 사용하도록 설정합니다.
- vSphere Lifecycle Manager에서 권장 이미지를 확인하면 대규모 클러스터에서 성능이 저하됨
호스트가 16개를 초과하는 대규모 클러스터의 경우 권장 사항 생성 작업을 완료하는 데 1시간 이상 걸릴 수 있으며 그렇지 않으면 작업이 중단된 것처럼 보일 수 있습니다. 권장 사항 작업의 완료 시간은 각 호스트에 구성된 디바이스 수와 권장하는 유효한 이미지를 얻기 전에 vSphere Lifecycle Manager가 처리해야 하는 디포의 이미지 후보 수에 따라 다릅니다.
해결 방법: 없음.
- vSphere Lifecycle Manager에서 하드웨어 호환성을 확인하면 대규모 클러스터에서 성능이 저하됨
호스트가 16개를 초과하는 대규모 클러스터의 경우 검증 보고서 생성 작업을 완료하는 데 최대 30분의 시간이 걸릴 수 있으며 그렇지 않으면 작업이 중단된 것처럼 보일 수 있습니다. 완료 시간은 각 호스트에 구성된 디바이스 수와 클러스터에 구성된 호스트의 수에 따라 다릅니다.
해결 방법: 없음
- vSphere Lifecycle Manager에서 클러스터에 업데이트를 적용할 때 영어 이외의 언어로 된 불완전한 오류 메시지가 표시됨
vCenter Server 사용자 인터페이스에서 지역화된 언어로 된 불완전한 오류 메시지가 표시될 수 있습니다. 이러한 메시지는 vSphere Lifecycle Manager에서 클러스터 업데이트 적용 프로세스가 실패한 후 표시됩니다. 예를 들어 다음과 같은 오류 메시지를 볼 수 있습니다.
영어 오류 메시지: 클러스터 'Cluster-1'에서 실행되는 가상 시스템 'VMC on DELL EMC -FileServer'가 유지 보수 모드 전환을 방해하는 문제점을 보고했습니다. 가상 시스템 구성을 액세스할 수 없음: 파일[local-0] VMC on Dell EMC - FileServer/VMC on Dell EMC - FileServer.vmx에 액세스할 수 없습니다.
프랑스어 오류 메시지: La VM « VMC on DELL EMC -FileServer », située sur le cluster « {Cluster-1} », a signalé un problème empêchant le passage en mode de maintenance : 가상 시스템 구성을 액세스할 수 없음: 파일[local-0] VMC on Dell EMC - FileServer/VMC on Dell EMC - FileServer.vmx에 액세스할 수 없습니다.
해결 방법: 없음.
- 벤더 추가 기능, 구성 요소 또는 펌웨어 및 드라이버 추가 기능이 없는 이미지를 해당 이미지에 그러한 요소가 포함되어 있는 클러스터로 가져오더라도 기존 이미지의 이미지 요소는 제거되지 않음
ESXi 기본 이미지만 가져온 이미지로 바뀝니다.
해결 방법: 가져오기 프로세스가 완료되면 이미지를 편집하고 필요한 경우 벤더 추가 기능, 구성 요소 그리고 펌웨어 및 드라이버 추가 기능을 제거합니다.
- 기준선을 사용하는 클러스터를 단일 이미지를 사용하는 클러스터로 변환하면 vSphere HA VIB가 제거된다는 주의가 표시됨
vSphere HA가 사용되도록 설정된 기준선을 사용하는 클러스터를 단일 이미지를 사용하는 클러스터로 변환하면 vmware-fdm 구성 요소가 제거된다는 주의 메시지가 표시될 수 있습니다.
해결 방법: 이 메시지는 무시해도 됩니다. 변환 프로세스는 vmware-fdm 구성 요소를 설치합니다.
- 프록시 서버를 통해 인터넷에서 패치 업데이트를 다운로드하도록 vSphere Update Manager를 구성한 경우 Update Manager를 vSphere Lifecycle Manager로 변환하는 vSphere 7.0 업그레이드 후 VMware 패치 저장소에서 패치를 다운로드하지 못할 수 있음
vCenter Server의 이전 릴리스에서는 vCenter Server 및 vSphere Update Manager에 대해 독립 프록시 설정을 구성할 수 있었습니다. vSphere 7.0으로의 업그레이드 후에는 vSphere Update Manager 서비스가 vSphere Lifecycle Manager 서비스의 일부가 됩니다. vSphere Lifecycle Manager 서비스의 경우 프록시 설정은 vCenter Server Appliance 설정에서 구성됩니다. 프록시 서버를 통해 인터넷에서 패치 업데이트를 다운로드하도록 Update Manager를 구성했지만 vCenter Server Appliance에 프록시 설정 구성이 없는 경우 vCenter Server를 버전 7.0으로 업그레이드한 후에는 vSphere Lifecycle Manager에서 VMware 디포에 연결하지 못하고 패치 또는 업데이트를 다운로드할 수 없습니다.
해결 방법: vCenter Server Appliance 관리 인터페이스(https://vcenter-server-appliance-FQDN-or-IP-address:5480)에 로그인하여 vCenter Server Appliance에 대한 프록시 설정을 구성하고 vSphere Lifecycle Manager에서 프록시를 사용하도록 설정합니다.
- 버전 6.5의 호스트 프로파일을 버전 7.0의 ESXi 호스트에 적용하는 경우 규정 준수 검사에 실패함
버전 6.5의 호스트 프로파일을 버전 7.0의 ESXi 호스트에 적용하면 코어 덤프 파일 프로파일이 호스트 규정을 준수하지 않는 것으로 보고됩니다.
해결 방법: 가능한 해결 방법에는 두 가지가 있습니다.
- 버전 6.5의 호스트 프로파일을 생성하는 경우 ESXi 호스트에서 고급 구성 옵션 VMkernel.Boot.autoCreateDumpFile을 false로 설정합니다.
- 버전 6.5의 기존 호스트 프로파일을 적용하는 경우 호스트 프로파일에 고급 구성 옵션 VMkernel.Boot.autoCreateDumpFile을 추가하고 고정 정책에 대한 옵션을 구성한 후 값을 false로 설정합니다.
- DYN_RSS(Dynamic Receive Side Scaling) 또는 GEN_RSS(Generic RSS) 기능이 켜져 있을 때 Mellanox ConnectX-4 또는 ConnectX-5 네이티브 ESXi 드라이버의 처리량이 다소 저하될 수 있음
DYN_RSS 및 GEN_RSS 기능이 켜져 있을 때 Mellanox ConnectX-4 또는 ConnectX-5 네이티브 ESXi 드라이버는 5% 미만의 처리량 저하를 보일 수 있습니다. 이것은 정상적인 워크로드에 영향을 미치지 않습니다.
해결 방법: 다음 명령을 사용하여 DYN_RSS 및 GEN_RSS 기능을 사용하지 않도록 설정할 수 있습니다.
# esxcli system module parameters set -m nmlx5_core -p "DYN_RSS=0 GEN_RSS=0"
# reboot
- 동일한 호스트에 있는 두 VM 간의 RDMA 트래픽이 PVRDMA 환경에서 실패할 수 있음
PVRDMA 환경의 vSphere 7.0 구현에서 VM은 HCA가 있는 경우 로컬 통신을 위해 HCA를 통해 트래픽을 전달합니다. 그러나 qedrntv 드라이버에서는 RDMA 트래픽의 루프백이 작동하지 않습니다. 예를 들어 동일한 업링크 포트 아래에 구성된 VM에서 실행되는 RDMA 대기열 쌍은 서로 통신할 수 없습니다.
vSphere 6.7 및 이전 버전에서는 SRQ가 사용되도록 설정된 경우 HCA가 로컬 RDMA 트래픽에 사용되었습니다. vSphere 7.0은 RoCE v2를 사용하여 SRQ가 최소 HW v14로 설정된 PVRDMA 버전을 사용하여 VM에서 HCA 루프백을 사용합니다.
현재 버전의 Marvell FastLinQ 어댑터 펌웨어는 동일한 PF 또는 포트의 QP 간 루프백 트래픽을 지원하지 않습니다.
해결 방법: vSphere 7.0에 인증된 기본 제공 드라이버에 필요한 지원이 추가되고 있습니다. 인박스 qedrntv 드라이버를 사용 중인 경우 3호스트 구성을 사용하고 VM을 세 번째 호스트로 마이그레이션해야 합니다.
- qedrntv 드라이버의 불안정한 데이터그램 트래픽 QP 제한 사항
Marvell FastLinQ qedrntv RoCE 드라이버 및 UD(불안정한 데이터그램) 트래픽에는 제한 사항이 있습니다. 대량 트래픽을 포함하는 UD 애플리케이션이 qedrntv 드라이버와 함께 실패할 수 있습니다. 또한 UD QP는 DMA MR(메모리 영역)에서만 작동할 수 있습니다. 물리적 MR 또는 FRMR은 지원되지 않습니다. 물리적 MR 또는 FRMR을 UD QP와 함께 사용하려고 시도하는 애플리케이션은 qedrntv 드라이버와 함께 사용될 때 트래픽을 전달하지 못합니다. 이러한 테스트 애플리케이션의 알려진 예는 ibv_ud_pingpong 및 ib_send_bw입니다.
iSER, NVMe-oF(RoCE) 및 PVRDMA 같은 VMware ESXi 환경의 표준 RoCE 및 RoCEv2 사용 사례는 이 문제의 영향을 받지 않습니다. UD 트래픽에 대한 사용 사례가 제한되며 이 문제는 대량 UD 트래픽이 필요한 소규모 애플리케이션 집합에 영향을 미칩니다.
Marvell FastLinQ 하드웨어는 RDMA UD 트래픽 오프로드를 지원하지 않습니다. GSI QP를 지원하는 VMware PVRDMA 요구 사항을 충족하기 위해 UD QP 지원의 제한된 소프트웨어 전용 구현이 qedrntv 드라이버에 추가되었습니다. 구현의 목표는 제어 경로 GSI 통신을 지원하는 것으로, 대량 트래픽 및 고급 기능을 지원하는 UD QP의 완전한 구현이 아닙니다.
UD 지원은 소프트웨어에서 구현되므로 구현 시 과도한 트래픽을 수용하지 못할 수 있고 패킷이 삭제될 수 있습니다. 이로 인해 대량 UD 트래픽이 실패할 수 있습니다.
해결 방법: 대량 UD QP 트래픽은 qedrntv 드라이버에서 지원되지 않으며 현재는 해결 방법이 없습니다. iSER, NVMe, RDMA 및 PVRDMA와 같은 VMware ESXi RDMA(RoCE) 사용 사례는 이 문제의 영향을 받지 않습니다.
- iSCSI LUN을 자주 연결하거나 연결을 끊으면 QLogic 578xx NIC가 장착된 서버가 실패할 수 있음
짧은 시간에 QLogic 578xx NIC iSCSI 연결 또는 연결 끊기를 자주 트리거하면 qfle3 드라이버 문제로 서버가 실패할 수 있습니다. 이 문제는 디바이스 펌웨어의 알려진 결함으로 인해 발생합니다.
해결 방법: 없음.
- Broadcom NVMe over FC 환경에서 드라이버 언로드 또는 컨트롤러 연결 끊기 작업 중에 ESXi가 실패할 수 있음
Broadcom NVMe over FC 환경에서 드라이버 언로드 또는 컨트롤러 연결 끊기 작업 중에 ESXi가 실패하고 다음과 같은 오류 메시지가 표시될 수 있습니다. @BlueScreen: #PF Exception 14 in world 2098707:vmknvmeGener IP 0x4200225021cc addr 0x19
해결 방법: 없음.
- ESXi가 일부 Dell 서버에서 i350/X550 NIC의 OEM 펌웨어 버전 번호를 표시하지 않음
인박스 ixgben 드라이버는 i350/X550 NIC의 펌웨어 데이터 버전 또는 서명만 인식합니다. 일부 Dell 서버에서 OEM 펌웨어 버전 번호는 OEM 패키지 버전 영역에 프로그래밍되어 있으며, 인박스 ixgben 드라이버는 이 정보를 읽지 않습니다. 8자리 펌웨어 서명만 표시됩니다.
해결 방법: OEM 펌웨어 버전 번호를 표시하려면 비동기 ixgben 드라이버 버전 1.7.15 이상을 설치합니다.
- X710 또는 XL710 NIC가 ESXi에서 실패할 수 있음
NIC를 재설정하거나 VMKernel의 내부 디바이스 트리를 조작하는 등의 특정 소거식 작업을 X710 또는 XL710 NIC에 대해 시작하면 NIC 하드웨어가 비패킷 메모리에서 데이터를 읽을 수 있습니다.
해결 방법: NIC를 재설정하거나 vmkernel 내부 디바이스 상태를 조작하지 않습니다.
- NVMe-oF가 시스템 재부팅 후 영구 VMHBA 이름을 보장하지 않음
NVMe-oF는 vSphere 7.0의 새로운 기능입니다. 서버에 vmhba30+를 사용하는 USB 스토리지가 설치되어 있고 NVMe over RDMA 구성이 있는 경우 시스템 재부팅 후 VMHBA 이름이 변경될 수 있습니다. 이는 NVMe over RDMA의 VMHBA 이름 할당이 PCIe 디바이스와 다르기 때문입니다. ESXi는 지속성을 보장하지 않습니다.
해결 방법: 없음.
- 크기가 300 GB 이상인 vCenter 데이터베이스에 대한 백업이 실패함
vCenter 데이터베이스 크기가 300 GB 이상인 경우 시간 초과로 인해 파일 기반 백업이 실패합니다. 다음 오류 메시지가 표시됩니다. 시간 초과! 72000초 내에 완료하지 못했습니다.
해결 방법: 없음.
- 외부 Platform Services Controller가 있는 vCenter Server 6.x에서 vCenter Server 7.0으로 업그레이드된 vCenter Server 7.0의 복원이 실패할 수 있음
외부 Platform Services Controller가 있는 vCenter Server 6.x에서 7.0으로 업그레이드된 vCenter Server 7.0을 복원하면 복원이 실패하고 다음 오류가 표시될 수 있습니다. 장치 스토리지 목록을 검색하지 못했습니다.
해결 방법: 복원 프로세스의 첫 단계에서 vCenter Server 7.0의 스토리지 수준을 높이십시오. 예를 들어 vCenter Server 6.7 외부 Platform Services Controller 설정 스토리지 유형이 소형인 경우 복원 프로세스를 위해 스토리지 유형을 대형으로 선택합니다.
- 호스트 프로파일 업데이트 적용 프로세스 중에 사용하도록 설정된 SSL 프로토콜 구성 매개 변수가 구성되지 않음
사용하도록 설정된 SSL 프로토콜 구성 매개 변수는 호스트 프로파일 업데이트 적용 중에 구성되지 않으며, 시스템 기본 프로토콜 tlsv1.2만 사용하도록 설정됩니다. 이 동작은 vCenter Server 7.0 환경에서 7.0 이하 버전의 호스트 프로파일에 대해 확인됩니다.
해결 방법: SFCB에 대해 TLSV 1.0 또는 TLSV 1.1 SSL 프로토콜을 사용하도록 설정하려면 SSH를 사용하여 ESXi 호스트에 로그인하고 다음 ESXCLI 명령을 실행합니다. esxcli system wbem -P <protocol_name>
- 호스트 프로파일을 사용하여 잠금 모드 설정을 구성할 수 없음
보안 호스트 프로파일을 사용하여 잠금 모드를 구성할 수 없으며 한 번에 여러 ESXi 호스트에 적용할 수 없습니다. 각 호스트를 수동으로 구성해야 합니다.
해결 방법: vCenter Server 7.0에서는 보안 호스트 프로파일을 사용하여 잠금 모드를 구성하고 잠금 모드 예외 사용자 목록을 관리할 수 있습니다.
- 호스트 프로파일이 클러스터에 적용될 때 ESXi 호스트에서 EVC(향상된 vMotion 호환성) 설정이 누락됨
VMware 구성 파일 /etc/vmware/config의 일부 설정은 구성 파일이 수정될 때 호스트 프로파일에 의해 관리되지 않고 차단됩니다. 따라서 호스트 프로파일이 클러스터에 적용되면 EVC 설정이 손실되어 EVC 기능 손실이 발생합니다. 예를 들어 마스킹 해제된 CPU는 워크로드에 노출될 수 있습니다.
해결 방법: 클러스터에서 관련 EVC 기준선을 재구성하여 EVC 설정을 복구합니다.
- vCenter Server 7.0에서 코어 덤프 파티션을 정의하는 호스트 프로파일을 사용하면 오류가 발생함
vCenter Server 7.0에서는 호스트 프로파일에서 코어 덤프 파티션을 구성하고 관리할 수 없습니다. 코어 덤프 파티션을 정의하는 호스트 프로파일을 적용하려고 하면 다음과 같은 오류가 발생합니다. 유효한 코어 덤프 파티션이 없습니다.
해결 방법: 없음. vCenter Server 7.0에서 호스트 프로파일은 파일 기반 코어 덤프만 지원합니다.
- ESXCLI 명령을 실행하여 방화벽 모듈을 언로드하면 hostd 서비스가 실패하고 ESXi 호스트의 연결이 끊어짐
여러 ESXi 호스트가 포함된 환경에서 방화벽 구성을 자동화하고, 필터를 제거하고 방화벽 모듈을 언로드하는 ESXCLI 명령 esxcli network firewall unload를 실행하면 hostd 서비스가 실패하고 ESXi 호스트의 연결이 끊어집니다.
해결 방법: 방화벽 모듈을 언제든지 언로드하지 않는 것이 좋습니다. 방화벽 모듈을 언로드해야 하는 경우에는 다음 단계를 사용하십시오.
- 다음 명령을 사용하여 hostd 서비스를 중지합니다.
/etc/init.d/hostd stop.
- 다음 명령을 사용하여 방화벽 모듈을 언로드합니다.
esxcli network firewall unload.
- 필요한 작업을 수행합니다.
- 다음 명령을 사용하여 방화벽 모듈을 로드합니다.
esxcli network firewall load.
- 다음 명령을 사용하여 hostd 서비스를 시작합니다.
/etc/init.d/hostd start.
- NFC(Network File Copy) 관리자의 인증되지 않은 세션으로 인해 vSAN 환경에서 vSphere Storage vMotion 작업이 실패할 수 있음
하나 이상의 스냅샷이 있고 스토리지 정책이 서로 다른 둘 이상의 가상 디스크가 있는 가상 시스템의 vSphere Storage vMotion을 사용하여 vSAN 데이터스토어로 마이그레이션하는 작업이 실패할 수 있습니다. 이 문제는 SOAP(Simple Object Access Protocol) 본문이 허용된 크기를 초과하기 때문에 NFC 관리자의 세션이 인증되지 않아서 발생합니다.
해결 방법: 먼저 VM 홈 네임스페이스 및 여러 가상 디스크 중 하나만 마이그레이션합니다. 작업이 완료된 후 나머지 2개 디스크에 대한 디스크 전용 마이그레이션을 수행합니다.
- ESXi 호스트에서 디바이스 및 스토리지의 속성 및 특성에 대한 변경 사항이 재부팅 후 지속되지 않을 수 있음
ESXi 호스트를 재부팅하는 동안 디바이스 검색 루틴 시간이 초과되면 jumpstart 플러그인이 호스트에 등록된 모든 디바이스에서 디바이스 및 스토리지의 모든 구성 변경 사항을 수신하지 못할 수 있습니다. 그 결과, 프로세스가 재부팅 후 일부 디바이스 또는 스토리지의 속성을 기본값으로 복원할 수 있습니다.
해결 방법: 영향을 받는 디바이스 또는 스토리지의 속성에 대한 변경 사항을 수동으로 복원합니다.
- ESXi 7.0의 베타 빌드를 사용하는 경우 일부 수명 주기 작업 중에 ESXi 호스트가 실패하고 퍼플 진단 스크린이 표시될 수 있음
ESXi 7.0의 베타 빌드를 사용하는 경우 일부 수명 주기 작업(예: 드라이버 언로드 또는 ENS 모드와 기본 드라이버 모드 간 전환) 중에 ESXi 호스트가 실패하고 퍼플 진단 스크린이 표시될 수 있습니다. 예를 들어 ENS 모드를 변경하려고 하면 역추적에 다음과 유사한 오류 메시지가 표시됩니다. case ENS::INTERRUPT::NoVM_DeviceStateWithGracefulRemove hit BlueScreen: ASSERT bora/vmkernel/main/dlmalloc.c:2733 이 문제는 베타 빌드에만 해당되며 ESXi 7.0과 같은 릴리스 빌드에는 영향을 주지 않습니다.
해결 방법: ESXi 7.0 GA로 업데이트합니다.
- 다이제스트 작업이 실패했다는 오류로 인해 가상 시스템의 스냅샷을 생성할 수 없음
CBRC(컨텐츠 기반 읽기 캐시) 다이제스트 파일을 업데이트하는 동안 APD(모든 경로 다운) 상태가 발생하는 경우가 드문 경합 조건으로 인해 다이제스트 파일에 불일치가 발생할 수 있습니다. 그 결과, 가상 시스템 스냅샷을 생성할 수 없으며, 스냅샷을 저장하는 중에 오류가 발생했습니다. 다이제스트 작업이 실패했습니다.라는 오류 메시지가 역추적에 표시됩니다.
해결 방법: 가상 시스템의 전원을 껐다 켜서 CBRC 해시 다시 계산을 트리거하고 다이제스트 파일의 불일치를 제거합니다.
- vSphere에 대한 특정 라이브러리의 HTTP 요청이 거부될 수 있음
vSphere 7.0의 HTTP 역방향 프록시는 이전 릴리스보다 더 엄격한 표준 규정 준수를 적용합니다. 이로 인해 애플리케이션이 vSphere에 대한 SOAP 호출을 위해 사용하는 일부 타사 라이브러리에 기존 문제가 노출될 수 있습니다.
이러한 라이브러리를 사용하는 vSphere 애플리케이션을 개발하거나 vSphere 스택에 이러한 라이브러리에 의존하는 애플리케이션을 포함하는 경우 이러한 라이브러리가 VMOMI로 HTTP 요청을 보낼 때 연결 문제가 발생할 수 있습니다. 예를 들어 vijava 라이브러리에서 생성된 HTTP 요청은 다음과 같은 형식을 사용할 수 있습니다.
POST /sdk HTTP/1.1
SOAPAction
Content-Type: text/xml; charset=utf-8
User-Agent: Java/1.8.0_221
이 예의 구문은 SOAPAction 다음에 콜론이 오도록 규정한 HTTP 프로토콜 헤더 필드 요구 사항을 위반합니다. 따라서 이 요청은 실행 중에 거부됩니다.
해결 방법: 애플리케이션에 비준수 라이브러리를 활용하는 개발자는 그 대신 HTTP 표준을 따르는 라이브러리의 사용을 고려할 수 있습니다. 예를 들어 vijava 라이브러리를 사용하는 개발자는 최신 버전의 yavijava 라이브러리를 대신 사용할 수 있습니다.
- Broadcom 드라이버 lsi_msgpt3, lsi_msgpt35 및 lsi_mr3을 사용하는 경우 덤프 파일이 보일 수 있음
lsi_msgpt3, lsi_msgpt35 및 lsi_mr3 컨트롤러를 사용하는 경우, 덤프 파일 lsuv2-lsi-drivers-plugin-util-zdump를 볼 위험이 있습니다. 이 플러그인 유틸리티에 사용된 storelib를 종료할 때 문제가 있습니다. ESXi 작업에는 영향을 주지 않으므로 덤프 파일을 무시해도 됩니다.
해결 방법: 이러한 메시지는 무시해도 됩니다. 다음 명령을 사용하여 lsuv2-lsi-drivers-plugin을 제거할 수 있습니다.
esxcli software vib remove -n lsuv2-lsiv2-drivers-plugin
- vCenter에서 PCI 디바이스의 SR-IOV를 구성한 후에는 재부팅이 필요하지 않지만, 타사 확장 프로그램에 의해 생성된 디바이스 구성이 손실되어 다시 적용하려면 재부팅이 필요하다는 메시지가 보일 수 있음
ESXi 7.0에서 SR-IOV 구성은 재부팅 없이 적용되고 디바이스 드라이버가 다시 로드됩니다. ESXi 호스트에서 부팅 중에 타사 확장 프로그램이 디바이스 드라이버가 로드된 후 실행해야 하는 디바이스 구성을 수행할 수 있습니다. 이러한 타사 확장 프로그램이 디바이스 구성을 다시 적용하려면 재부팅이 필요합니다.
해결 방법: SR-IOV를 구성한 후 재부팅하여 타사 디바이스 구성을 적용해야 합니다.
