이전의 알려진 문제는 다음과 같이 그룹화되어 있습니다.
- vSphere 7.0 업데이트 3c로 업그레이드하려면 전체 호스트 동기화를 강제로 적용하기 위한 추가 단계가 필요할 수 있음
vSphere 시스템에 대해 지원되는 업그레이드 순서는 vCenter Server를 업그레이드한 다음 ESXi를 업그레이드하는 것입니다. 하지만 ESXi 호스트 버전 7.0 업데이트 2d 이상이 있는 특정 환경에서는 ESXi를 먼저 7.0 업데이트 3c로 업데이트한 후 vCenter Server를 업데이트해야 합니다. 이러한 업그레이드 순서에는 전체 호스트 동기화를 강제로 적용하기 위한 추가 단계가 필요합니다.
해결 방법: 수퍼 관리자 권한이 있는 사용자(예: root)로 장치 셸에 로그인하고 다음 단계를 수행합니다.
- vpxd 서비스를 중지합니다.
/opt/vmware/vpostgres/current/bin/psql -U postgres -d VCDB -c "update VPX_HOST_SYNC_GEN set master_gen=0 where host_id in (select id from VPX_HOST where product_version like '7.0.3%')" 명령을 실행합니다.- vpxd 서비스를 시작합니다.
- i40en 및 i40enu Intel 네트워크 드라이버가 모두 설치되어 있는 핫 패치된 ESXi 호스트가 vCenter Server 7.0 업데이트 3c로 업그레이드된 후 vSphere High Availability를 구성하지 못할 수 있음
Intel i40en 드라이버의 이름이 i40enu로 변경되었다가 다시 i40en으로 변경되었기 때문에 변경의 영향을 받는 ESXi 호스트가 제대로 업그레이드되는지 확인하기 위해 vCenter Server 7.0 업데이트 3c에 업그레이드 사전 검사가 추가됩니다. 하지만 vCenter Server 7.0 업데이트 3c 이후에 릴리스된 ESXi 핫 패치를 적용한 후 시스템을 vCenter Server 7.0 업데이트 3c로 업그레이드하면 사전 검사 목록에 핫 패치가 없을 수 있습니다. 그래서 업그레이드를 위한 적절한 단계를 따르지 못할 수 있으며 vSphere HA가 이러한 호스트에서 구성되지 못할 수 있습니다.
해결 방법: 핫 패치된 ESXi 호스트를 버전 7.0 업데이트 3c로 업그레이드합니다.
- 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 제공자를 다운로드하는 것입니다.
- vCenter Server High Availability를 사용하도록 설정된 경우 이전 버전의 vCenter Server 7.x에서 vCenter Server 7.0 업데이트 1로 패치 적용이 차단됨
vCenter Server High Availability가 활성이면 이전 버전의 vCenter Server 7.x에서 vCenter Server 7.0 업데이트 1로 패치 적용이 차단됩니다.
해결 방법: 이전 버전의 vCenter Server 7.x에서 vCenter Server 7.0 업데이트 1로 패치를 적용하려면 vCenter Server High Availability를 제거하고 수동 및 감시 노드를 삭제해야 합니다. 업그레이드 후에 vCenter Server High Availability 클러스터를 다시 생성해야 합니다.
- 6.7.x vCenter Server 시스템을 vCenter Server 7.x로 마이그레이션하면 UnicodeEncodeError로 인해 실패함
구성, 인벤토리, 작업, 이벤트 및 성능 메트릭에 대한 모든 데이터를 가져오는 옵션을 선택하면, 영어가 아닌 로케일을 사용하는 모든 vCenter Server 시스템에서 6.7.x vCenter Server 시스템을 vCenter Server 7.x로 마이그레이션하는 작업이 실패할 수 있습니다. 마이그레이션 2단계의 1단계에서 vSphere Client에 다음과 같은 오류가 표시됩니다.
이벤트 및 작업 데이터를 내보내는 중 오류가 발생했습니다. …오류 UnicodeEncodeError: Traceback (most recent call last):
해결 방법: 다음 중 하나를 수행하여 마이그레이션 작업을 완료할 수 있습니다.
- 마이그레이션의 1단계 끝에서 기본 옵션인 구성 및 인벤토리를 선택합니다.
이 옵션에는 작업 및 이벤트 데이터가 포함되지 않습니다.
- 이벤트 테이블에서 데이터를 정리하고 마이그레이션을 다시 실행합니다.
- Windows vCenter Server 시스템에 ASCII가 아닌 문자가 포함된 데이터베이스 암호가 있으면 VMware Migration Assistant의 사전 검사가 실패함
VMware Migration Assistant를 사용하여 6.x vCenter Server 시스템을 vCenter Server 7.x로 마이그레이션하려는 경우 시스템에 Windows OS가 있고 ASCII가 아닌 문자가 포함된 암호가 있는 외부 데이터베이스를 사용하면 작업이 실패합니다. 예: Admin!23迁移. Migration Assistant 콘솔에 다음과 같은 오류가 표시됩니다.
오류: 구성 요소 com.vmware.vcdb가 내부 오류와 함께 실패했습니다.
해결 방법: VPX/VPX/vcdb-upgrade에 Bugzilla PR을 제출하십시오.
해결 방법: 없음
- vCenter Server 7.x에서 vCenter Server 7.0 업데이트 1로 업데이트하는 동안 vCenter Single Sign-On 암호를 제공하라는 메시지가 표시됨
vCenter Server 7.x에서 vCenter Server 7.0 업데이트 1로 업데이트하는 동안 vCenter Single Sign-On 관리자 암호를 제공하라는 메시지가 표시됩니다.
해결 방법: vCenter Server 관리 인터페이스를 사용하여 업데이트를 실행하는 경우 vCenter Single Sign-On 관리자 암호를 제공해야 합니다.
software-packages 또는 CLI를 사용하여 대화형 방식으로 업데이트를 실행하는 경우 vCenter Single Sign-On 관리자 암호를 대화형으로 제공해야 합니다.
software-packages 또는 CLI를 사용하여 비대화형 방식으로 업데이트를 실행하는 경우 다음 형식의 응답 파일로 vCenter Single Sign-On 관리자 암호를 제공해야 합니다.
{ "vmdir.password": "SSO Password of Administrator@<SSO-DOMAIN>
user" }
- 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 기술 자료 문서를 참조하십시오.
- VMware vSphere High Availability를 사용하도록 설정된 클러스터에 vSphere Lifecycle Manager 이미지를 사용하여 ESXi 호스트를 추가하는 동안 NSX를 적용하거나 제거하지 못할 수 있음
vSphere HA가 설정된 클러스터에 vSphere Lifecycle Manager 이미지를 사용하여 여러 ESXi 호스트를 추가하는 동안 NSX를 적용하거나 제거하는 작업을 시작하면 NSX 관련 작업이 실패하고 vSphere Client 에 다음과 같은 오류가 발생할 수 있습니다.
클러스터 <cluster_name>의 일부 호스트에서 vSphere HA 에이전트가 vSphere HA 마스터 에이전트가 아니며 vSphere HA 마스터 에이전트에 연결되어 있지 않습니다. HA 구성이 올바른지 확인하십시오.
이 문제는 vSphere Lifecycle Manager가 클러스터에 추가되는 ESXi 호스트에 대해 vSphere HA를 한 번에 하나씩 구성하기 때문에 발생합니다. vSphere HA 구성 작업이 진행되는 동안 NSX를 적용하거나 제거하는 작업을 실행하면, NSX 작업은 서로 다른 두 ESXi 호스트에 대한 vSphere HA 구성 작업 사이에 대기할 수 있습니다. 이런 경우, NSX 작업은 클러스터 상태 점검 오류로 인해 실패합니다. 해당 시점의 클러스터 상태가 모든 ESXi 호스트에 vSphere HA가 구성되어 실행 중인 예상 상태와 일치하지 않기 때문입니다. 동시에 클러스터에 추가하는 ESXi 호스트 수가 많을수록 문제가 발생할 가능성이 높습니다.
해결 방법: 클러스터에서 vSphere HA를 사용하지 않도록 설정했다가 사용하도록 설정합니다. NSX를 적용하거나 제거하는 작업을 진행합니다.
- vCenter Server 7.0 시스템을 업그레이드한 후 vSphere Client의 vSphere 포드 요약 탭에서 포드의 IP 주소를 볼 수 없음
vCenter Server 7.0 시스템을 최신 버전으로 업그레이드하면 vSphere Client의 vSphere 포드 요약 탭에서 포드의 IP 주소를 더 이상 볼 수 없습니다.
해결 방법: vSphere용 Kubernetes CLI 도구를 사용하여 포드의 세부 정보를 검토합니다.
- 사전 요구 사항으로 포드와 네임스페이스 이름을 복사합니다.
- vSphere Client에서 워크로드 관리 > 클러스터로 이동합니다.
- 제어부 노드 IP 주소 탭에 표시된 IP를 복사합니다.
https://<control_plane_node_IP_address>로 이동하여 Kubernetes CLI 도구, kubectl 및 kubectl-vsphere를 다운로드할 수 있습니다.
또는 vSphere용 Kubernetes CLI 도구 다운로드 및 설치의 단계를 따르십시오.
- vSphere용 CLI 플러그인을 사용하여 포드 세부 정보를 검토합니다.
- 다음 명령을 사용하여 감독자 클러스터에 로그인합니다.
kubectl vsphere login --server=https://<server_adress> --vsphere-username <your user account name> --insecure-skip-tls-verify
- 1단계에서 복사한 이름을 사용하여 포드 세부 정보를 검색하는 명령을 실행합니다.
kubectl config use-context <namespace_name>
및
kubectl describe pod <pod_name> -n <namespace_name>
그러면, 다음과 유사한 출력에서 IP 주소를 볼 수 있습니다.
$ kubectl describe pod helloworld -n my-podvm-ns ...
실행 상태: 실행 중
IP: 10.0.0.10
IPs:
IP: 10.0.0.10 ...
- 외부 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 시스템 업그레이드가 사전 확인 단계에서 실패함
vCenter Server 시스템 업그레이드가 권한 부여(Authz) 연결의 제한으로 인해 사전 확인 단계에서 실패할 수 있습니다. /var/log/vmware/vpxd-svcs/vpxd-svcs*.log 파일에 다음과 같은 항목이 표시됩니다.
Session count for user [after add]: <DOMAIN-NAME>\machine-xxxx is 200
Session limit reached for user: <DOMAIN-NAME>\machine-xxxx with 200 sessions.
또한 인벤토리를 로드하는 vSphere Client에서 응답이 지연될 수 있습니다.
해결 방법: service-control --restart vmware-vpxd-svcs 명령을 사용하여 vCenter Server 시스템에서 vmware-vpxd-svcs를 다시 시작합니다. 워크플로 중단을 방지하려면 vCenter Server 시스템에서 다른 작업이 실행되지 않는 경우에만 명령을 사용을 사용하십시오. 자세한 내용은 VMware 기술 자료 문서 81953을 참조하십시오.
- CLI를 사용하여 vCenter Server를 업그레이드할 때 vSphere Authentication Proxy 서비스에 대한 TLS(전송 보안 계층) 구성이 잘못 유지됨
vSphere Authentication Proxy 서비스(vmcam)가 기본 TLS 1.2 프로토콜 이외의 특정 TLS 프로토콜을 사용하도록 구성된 경우 이 구성은 CLI 업그레이드 프로세스 동안 유지됩니다. 기본적으로 vSphere는 TLS 1.2 암호화 프로토콜을 지원합니다. TLS 1.2를 지원하지 않는 제품 또는 서비스를 지원하기 위해 TLS 1.0 및 TLS 1.1 프로토콜을 사용해야 하는 경우, TLS 구성 유틸리티를 사용하여 다른 TLS 프로토콜 버전을 사용하거나 사용하지 않도록 설정합니다.
해결 방법: TLS 구성 유틸리티를 사용하여 vmcam 포트를 구성합니다. TLS 프로토콜 구성을 관리하고 TLS 구성 유틸리티를 사용하는 방법은 VMware 보안 설명서를 참조하십시오.
- CLI를 사용하여 vCenter Server 7.0 업데이트 3c에 패치를 적용할 때 사전 검사 오류가 표시되지 않음
Intel i40en 드라이버의 이름이 i40enu로 변경되었다가 다시 i40en으로 변경되었기 때문에 변경의 영향을 받는 ESXi 호스트가 제대로 업그레이드되는지 확인하기 위해 vCenter Server 7.0 업데이트 3c에 업그레이드 사전 검사가 추가됩니다. 경우에 따라 이러한 호스트가 시스템에 있는 경우 CLI를 사용하여 vCenter Server를 7.0 업데이트 3 이전 버전에서 7.0 업데이트 3 이후 버전으로 패치를 적용하면 실패하고 다음 오류가 표시될 수 있습니다. 설치에 실패했습니다. 현재 상태에서 재개를 다시 시도하십시오. 또는 VC 지원 번들을 수집하십시오.
하지만 이런 오류 대신 사전 검사 오류 메시지가 표시되어야 합니다.
해결 방법: 사전 검사 오류가 표시되지 않고 시스템에 vCenter Server 7.0 업데이트 3c 패치를 적용하는 데 실패하는 경우에는 vCenter Server를 업그레이드하기 전에 ISO 또는 단일 이미지에서 생성된 기준선을 사용하여 모든 ESXi 호스트가 ESXi 7.0 업데이트 3c 이상으로 업그레이드되었는지 확인해야 합니다. 롤업 게시판에 기반한 패치 기준선을 사용하지 마십시오. /var/log/vmware/applmgmt에서 추가 디버그 로그 정보를 찾을 수 있습니다. 자세한 내용은 VMware 기술 자료 문서 87319 및 86447을 참조하십시오.
- vCenter Server 업그레이드 중에 스마트 카드 및 RSA SecurID 설정이 유지되지 않을 수 있음
vCenter Server 7.0으로 업그레이드한 후 RSA SecurID를 사용한 인증이 작동하지 않습니다. RSA SecurID 로그인을 사용하여 로그인하려고 하면 오류 메시지가 표시됩니다.
해결 방법: 스마트 카드 또는 RSA SecureID를 재구성합니다.
- vSphere 7.0 업데이트 3c로 업그레이드하려면 전체 호스트 동기화를 강제로 적용하기 위한 추가 단계가 필요할 수 있음
vSphere 시스템에 대해 지원되는 업그레이드 순서는 vCenter Server를 업그레이드한 다음 ESXi를 업그레이드하는 것입니다. 하지만 ESXi 호스트 버전 7.0 업데이트 2c 이상을 있는 특정 환경에서는 ESXi를 먼저 7.0 업데이트 3c로 업데이트한 후 vCenter Server를 업데이트해야 합니다. 이러한 업그레이드 순서에는 전체 호스트 동기화를 강제로 적용하기 위한 추가 단계가 필요합니다.
해결 방법: 수퍼 관리자 권한이 있는 사용자(예: root)로 장치 셸에 로그인하고 다음 단계를 수행합니다.
- vpxd 서비스를 중지합니다.
/opt/vmware/vpostgres/current/bin/psql -U postgres -d VCDB -c "update VPX_HOST_SYNC_GEN set master_gen=0 where host_id in (select id from VPX_HOST where product_version like '7.0.3%')" 명령을 실행합니다.- vpxd 서비스를 시작합니다.
- 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으로 마이그레이션하는 작업을 다시 시도합니다.
- i40en 및 i40enu Intel 네트워크 드라이버가 모두 설치되어 있는 핫 패치된 ESXi 호스트가 vCenter Server 7.0 업데이트 3c로 업그레이드된 후 vSphere High Availability를 구성하지 못할 수 있음
Intel i40en 드라이버의 이름이 i40enu로 변경되었다가 다시 i40en으로 변경되었기 때문에 변경의 영향을 받는 ESXi 호스트가 제대로 업그레이드되는지 확인하기 위해 vCenter Server 7.0 업데이트 3c에 업그레이드 사전 검사가 추가됩니다. 하지만 vCenter Server 7.0 업데이트 3c 이후에 릴리스된 ESXi 핫 패치를 적용한 후 시스템을 vCenter Server 7.0 업데이트 3c로 업그레이드하면 사전 검사 목록에 핫 패치가 없을 수 있습니다. 그래서 업그레이드를 위한 적절한 단계를 따르지 못할 수 있으며 vSphere HA가 이러한 호스트에서 구성되지 못할 수 있습니다.
해결 방법: 핫 패치된 ESXi 호스트를 버전 7.0 업데이트 3c로 업그레이드합니다.
- 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 이외의 보조 네트워크를 유지하지 않습니다. 소스 인스턴스가 VDS 포트 그룹의 일부인 여러 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 확인 후 다시 시도"라는 오류 메시지가 표시됩니다. 오류 메시지는 [업데이트] 패널 내에서 기능을 사용하는 것을 방지하지 않으며 사용 가능한 업데이트를 보고, 스테이징하고, 설치할 수 있습니다.
해결 방법: 없음.
- VMware vCenter Server High Availability를 사용하도록 설정된 환경의 감시 또는 수동 노드에 패치를 적용하면 실패할 수 있음
vCenter Server High Availability를 사용하도록 설정된 환경에서 감시 또는 수동 노드에 패치를 적용하면 실패하고 다음과 유사한 메시지가 표시될 수 있습니다.
RuntimeError: unidentifiable C++ exception.
해결 방법: vCenter Server High Availability를 사용하지 않도록 설정합니다. vCenter Server 시스템에 패치를 적용합니다. vCenter Server High Availability를 다시 사용하도록 설정합니다.
- vCenter Server 시스템을 vCenter Server 7.0.0a로 패치한 후 VC 스토리지 클라이언트의 TLS 버전이 기본값으로 돌아갈 수 있음
VC 스토리지 클라이언트 서비스에 대한 TLS 구성이 기본 TLS 1.2 단독과 다른 경우 vCenter Server 시스템을 vCenter Server 7.0.0a로 패치하면 TLS 버전이 기본값으로 되돌아갈 수 있습니다.
해결 방법: 업데이트 후에 TLS 구성 유틸리티를 사용하여 vCenter Server 시스템에서 TLS 버전을 사용하거나 사용하지 않도록 설정합니다.
- 시스템을 vCenter Server 7.0.0b로 업데이트한 후 /var/core 폴더에 systemd 코어 덤프가 표시됨
시스템을 vCenter Server 7.0.0a 또는 vCenter Server 7.0에서 vCenter Server 7.0.0b로 업데이트한 후 /var/core 폴더에 core.systemd-journal.393 및 core.systemd-udevd.405와 같은 systemd 코어 덤프가 표시됩니다. 코어 덤프는 무해하며 제거할 수 있습니다.
해결 방법: 없음
- vCenter Server 시스템을 7.0.0b로 업데이트했는데도 DCUI(Direct Console User Interface)의 vCenter Server 버전이 업데이트되지 않음
시스템을 vCenter Server 7.0.0a 또는 vCenter Server 7.0에서 vCenter Server 7.0.0b로 업데이트했는데도 DCUI에는 여전히 이전 vCenter Server 버전이 표시됩니다.
해결 방법: 업데이트를 완료한 후 vCenter Server 버전을 새로 고치려면 장치 셸에서 /usr/lib/applmgmt/dcui/notify 명령을 실행합니다.
- [네트워크 연결 또는 잘못된 URL로 인해 구성된 저장소에 액세스할 수 없습니다.] 오류와 함께 업데이트 플래너가 실패함
vSphere Lifecycle Manager의 일부로, 용이한 vCenter Server 업데이트를 위해 사용하는 업데이트 플래너를 사용하는 경우 vSphere Client에서 다음과 같은 오류가 표시될 수 있습니다.
네트워크 연결 또는 잘못된 URL로 인해 구성된 저장소에 액세스할 수 없습니다. 저장소 설정을 확인합니다.
이 문제는 https:///uploads/dpe/ 또는 DBC 경로와 같은 사용자 지정 로컬 저장소를 사용하여 추출된 항목을 저장하는 경우에 발생합니다. URL 기반 패치에 대한 사용자 지정 저장소에 인증 정책이 있는 경우 업데이트 플래너가 사용 가능한 업데이트 목록을 가져오지 못할 수 있습니다.
해결 방법: 사용자 지정 저장소 URL에 액세스하는 데 인증이 필요하지 않도록 사용자 지정 저장소를 구성합니다.
- vCenter Server 7.0.0b로 업그레이드한 후 vSphere Lifecycle Manager 이미지 기반 클러스터에 vSphere HA 오류가 표시됨
vCenter Server 7.0.0b로 업그레이드한 후 환경에 처음으로 로그인했을 때 vSphere HA로 구성된 vSphere Lifecycle Manager 이미지 기반 클러스터에 vSphere HA 구성에 관한 오류 메시지가 표시될 수 있습니다. vSphere Client에 다음과 같은 메시지가 표시됩니다.
호스트에서 vSphere HA 에이전트의 구성을 완료할 수 없습니다. 또는
클러스터에 HA VIB를 적용하는 중 오류 발생.
이 문제는 이미지 디포 내보내기에 많은 시간이 걸려 작업 시간 초과가 발생할 수 있기 때문에 발생합니다. /storage/log/vmware/vmware-updatemgr/vum-server/vmware-vum-server.log에 다음 메시지가 표시됩니다. Export taking too long (Failure case)
해결 방법: 이것은 vCenter Server가 가동되어 실행된 후 10분 내에 해결되는 일시적인 문제입니다. 이 문제는 기능에 어떤 영향도 미치지 않습니다. 영향을 받는 클러스터의 vSphere HA는 예상대로 작동합니다. 전원 켜기, 마이그레이션 등 가상 시스템과 관련된 모든 작업은 이 오류 복구가 계속 진행되는 동안 vSphere HA 지원 클러스터에서 작동합니다.
- CLI를 사용하여 vCenter Server 7.0 업데이트 3d에 패치를 적용할 때 사전 검사 오류가 표시되지 않음
Intel i40en 드라이버의 이름이 i40enu로 변경되었다가 다시 i40en으로 변경되었기 때문에 변경의 영향을 받는 ESXi 호스트가 제대로 업그레이드되는지 확인하기 위해 vCenter Server 7.0 업데이트 3d 이상에 업그레이드 사전 검사가 추가됩니다. 경우에 따라 이러한 호스트가 시스템에 있는 경우 CLI를 사용하여 vCenter Server를 7.0 업데이트 3 이전 버전에서 7.0 업데이트 3 이후 버전으로 패치를 적용하면 실패하고 다음 오류가 표시될 수 있습니다. 설치에 실패했습니다. 현재 상태에서 재개를 다시 시도하십시오. 또는 VC 지원 번들을 수집하십시오. 하지만 이런 오류 대신 사전 검사 오류 메시지가 표시되어야 합니다.
해결 방법: 사전 검사 오류가 표시되지 않고 시스템에 vCenter Server 7.0 업데이트 3d 패치를 적용하는 데 실패하는 경우에는 vCenter Server를 업그레이드하기 전에 ISO 또는 단일 이미지에서 생성된 기준선을 사용하여 모든 ESXi 호스트가 ESXi 7.0 업데이트 3d로 업그레이드되었는지 확인해야 합니다. 롤업 게시판에 기반한 패치 기준선을 사용하지 마십시오. /var/log/vmware/applmgmt에서 추가 디버그 로그 정보를 찾을 수 있습니다. 자세한 내용은 VMware 기술 자료 문서 87319 및 86447을 참조하십시오.
- VMware 원격 콘솔을 사용하는 경우 엔보이 서비스가 간헐적으로 실패할 수 있음
VMware Remote Console과 관련된 엔보이 서비스 문제로 인해 서비스가 간헐적으로 실패할 수 있습니다. 그 결과 vCenter Server 관리 인터페이스 또는 vCenter Server API도 사용할 수 없게 될 수 있습니다.
해결 방법: VMware Remote Console 대신 vSphere Client를 사용합니다.
- 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
명령을 실행한 후 재부팅합니다.
- vSphere 클러스터에서 vSphere with Tanzu를 사용하지 않도록 설정하려고 하면 작업이 중지되고 오류가 발생함
관리자 클러스터 외부에 있는 일부 가상 시스템이 클러스터의 NSX 세그먼트 포트 그룹에 상주하는 경우, 해당 포트를 정리 스크립트가 삭제할 수 없고 클러스터에서 vSphere with Tanzu를 사용하지 않도록 설정할 수 없습니다. vSphere Client에 NSX Manager에 대한 정리 요청이 실패했습니다 오류가 표시되고 작업이 제거 중 상태에서 중지됩니다. /var/log/vmware/wcp/wcpsvc.log 파일에 다음 오류 메시지가 표시됩니다.
Segment path=[...] has x VMs or VIFs attached. Disconnect all VMs and VIFs before deleting a segment.
해결 방법: /var/log/vmware/wcp/wcpsvc.log 파일에 표시된 가상 시스템을 세그먼트에서 삭제합니다. 작업이 복원될 때까지 기다립니다.
- NSX 6.4.7로 업그레이드한 후, IPv6 네트워크의 워크로드 VM에 정적 IPv6 주소가 할당되면 VM이 Edge의 IPv6 게이트웨이 인터페이스를 ping할 수 없음
이 문제는 vSphere 분산 스위치를 6.x에서 7.0으로 업그레이드한 후에 발생합니다.
해결 방법 1:
모든 호스트가 연결된 VDS를 선택하고 편집 설정으로 이동한 다음 멀티캐스트 옵션을 기본으로 전환합니다.
해결 방법 2:
Edge 방화벽에 다음 규칙을 추가합니다.
Ping 허용 규칙.
MLD(멀티캐스트 수신기 검색) 허용 규칙(icmp6, 유형 130 (v1) 및 유형 143 (v2)).
- 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 어댑터를 연결하는 작업은 지원되지 않습니다. 대신 분산 포트 그룹을 사용하십시오."라는 오류를 보고합니다.
- VDS(vSphere Distributed Switch)의 상태 비저장 ESXi에 대해서는 NSX 포트 그룹의 vmknic가 차단됩니다. 분산 포트 그룹을 대신 사용해야 합니다.
- VDS의 상태 저장 ESXi에 대해서는 NSX 포트 그룹의 vmknic가 지원되지만, vSAN에 NSX 포트 그룹의 vmknic를 사용하는 경우 문제가 발생할 수 있습니다.
해결 방법: 동일한 VDS의 분산 포트 그룹을 사용합니다.
- QLogic 4x10GE QL41164HFCU CNA에 대해 vCenter에서 SRIOV를 사용하도록 설정하지 못할 수 있음
QLogic 4x10GE QL41164HFCU CNA를 사용하는 경우, 물리적 네트워크 어댑터에 대한 설정 편집 대화 상자로 이동하여 SR-IOV를 사용하도록 설정하려고 하면 작업이 실패할 수 있습니다. SR-IOV를 사용하도록 설정하려고 하면 ESXi 호스트의 네트워크가 중단될 수 있습니다.
해결 방법: ESXi 호스트에서 다음 명령을 사용하여 SRIOV를 사용하도록 설정합니다.
esxcfg-module
- 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 상태를 수정합니다.
- APD 또는 PDL 상태에서 복구된 후 클러스터된 가상 디스크를 지원하는 VMFS 데이터스토어가 액세스할 수 없는 상태로 유지될 수 있음
이 문제는 클러스터된 가상 디스크 지원이 사용되도록 설정된 데이터스토어에서만 발생할 수 있습니다. 데이터스토어가 APD(모든 경로 다운) 또는 PDL(영구적 디바이스 손실) 상태에서 복구되면 액세스할 수 없는 상태로 유지됩니다. VMkernel 로그에 다음과 유사한 여러 SCSI3 예약 충돌 메시지가 표시될 수 있습니다.
2020-02-18T07:41:10.273Z cpu22:1001391219)ScsiDeviceIO: vm 1001391219: SCSIDeviceCmdCompleteCB:2972: Reservation conflict retries 544 for command 0x45ba814b8340 (op: 0x89) to device "naa.624a9370b97601e346f64ba900024d53"
이 문제는 클러스터에 참여하는 ESXi 호스트가 데이터스토어에 대한 SCSI 예약을 잃고 데이터스토어가 복구된 후 항상 자동으로 예약을 다시 획득할 수 없기 때문에 발생할 수 있습니다.
해결 방법: 다음 명령을 사용하여 수동으로 예약을 등록합니다.
vmkfstools -L registerkey /vmfs/devices/disks/<device name>
여기서 <device name>은 데이터스토어가 생성된 디바이스의 이름입니다.
- 가상 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 작업을 실행하지 않습니다.
- 새로운 항목 삭제된 CNS 볼륨이 일시적으로 CNS UI에 있는 것처럼 나타날 수 있음
CNS 볼륨을 지원하는 FCD 디스크를 삭제한 후에도 볼륨이 여전히 CNS UI에 있는 것처럼 나타날 수 있습니다. 하지만 볼륨 삭제 시도는 실패합니다. 다음과 유사한 오류 메시지가 표시될 수 있습니다.
참조된 개체 또는 항목을 찾을 수 없습니다.
해결 방법: 다음에 전체 동기화를 수행하면 불일치 문제가 해결되고 CNS UI가 올바로 업데이트됩니다.
- 새로운 항목 특정 상황에서, CNS 작업이 실패했는데도 vSphere Client에서 작업 상태가 성공으로 나타남
이러한 문제는 예를 들어 호환되지 않는 스토리지 정책을 사용하여 CNS 볼륨을 생성하는 경우에 발생할 수 있습니다. 작업이 실패했지만 vSphere Client는 작업 상태를 성공으로 표시합니다.
해결 방법: vSphere Client에서 작업 상태가 성공으로 나타난다고 해서 CNS 작업이 성공했다고 단정할 수 없습니다. 작업의 성공 여부를 확인하려면 그 결과를 검토해야 합니다.
- 새로운 항목 CNS 영구 볼륨에 대한 삭제 작업에 실패하면 vSphere 데이터스토어에서 볼륨이 삭제되지 않은 상태로 남을 수 있음
이 문제는 CNS Delete API가 포드에 아직 연결되어 있는 영구 볼륨을 삭제하려고 할 때 발생할 수 있습니다. 예를 들어, 포드가 실행되는 Kubernetes 네임스페이스를 삭제하면, 결과적으로, CNS에서 볼륨이 지워지고 CNS 쿼리 작업이 볼륨을 반환하지 않습니다. 하지만 볼륨은 데이터스토어에 계속 상주하며, CNS Delete API 작업을 반복해도 삭제할 수 없습니다.
해결 방법: 없음.
- 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가 오류 상태가 됨
클러스터에 대한 업데이트 적용 프로세스 중 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에 액세스할 수 없습니다.
해결 방법: 없음.
- 기준선을 사용하는 클러스터를 단일 이미지를 사용하는 클러스터로 변환하면 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에서 프록시를 사용하도록 설정합니다.
- Java 클라이언트를 사용하여 업데이트 적용 작업을 검토하는 경우 업데이트 적용 작업에서 결과를 추출할 수 없음
Java 클라이언트를 사용하여 업데이트 적용 작업을 검토하는 경우 ConstraintValidationException 오류로 인해 결과를 추출하지 못할 수 있습니다. 이 문제는 업데이트를 적용하는 동안 ESXi 호스트가 유지 보수 모드로 전환되지 못하고 [건너뜀] 상태가 되지만 연속 업데이트 적용 작업에 대해 [진행 중] 플래그가 동시에 잘못 적용되는 경우에 발생합니다. 이로 인해 Java 클라이언트에서 ConstraintValidationException 오류가 발생하고 업데이트 적용 작업의 결과를 추출할 수 없습니다.
해결 방법: ESXi 호스트가 유지 보수 모드로 전환되지 못하게 하는 근본적인 문제를 해결하고 업데이트 적용 작업을 다시 시도합니다.
- 일반 vSphere Lifecycle Manager 디포와 ROBO(Remote Office and Branch Office) 배포의 로컬 디포가 동기화되지 않을 수 있음
인터넷 액세스가 제한되거나 불가능한 ROBO 클러스터 또는 vCenter Server에 대한 연결이 제한된 ROBO 클러스터는 vCenter Server의 vSphere Lifecycle Manager 디포에 액세스하는 대신 자체 로컬 디포에서 이미지를 다운로드할 수 있습니다. 하지만 vSphere Lifecycle Manager는 중앙 수준에서만 사전 검증된 이미지의 형태로 소프트웨어 권장 사항을 생성하기 때문에, 권장 이미지 컨텐츠를 디포 재정의에 사용하지 못할 수 있습니다.
해결 방법: 권장 이미지를 사용하기로 결정한 경우에는 디포 재정의와 중앙 디포 간의 컨텐츠가 동기화되어 있는지 확인합니다.
- 잠금 모드가 설정된 ESXi 호스트에서 vSphere Lifecycle Manager를 사용한 클러스터 업데이트 적용이 실패할 수 있음
클러스터에 잠금 모드가 설정된 ESXi 호스트가 있는 경우 vSphere Lifecycle Manager를 사용하여 업데이트 적용 작업을 수행하면 이러한 호스트를 건너뛸 수 있습니다. 로그 파일에 Host scan task failed 및 com.vmware.vcIntegrity.lifecycle.EsxImage.UnknownError An unknown error occurred while performing the operation과 같은 메시지가 표시됩니다.
해결 방법: 잠금 모드에 대한 예외 목록에 루트 사용자를 추가하고 클러스터 업데이트 적용을 다시 시도합니다.
- 업데이트 후 vSphere Lifecycle Manager 워크플로를 사용하여 OEM 컨텐츠가 있는 ESXi 이미지로 클러스터를 생성할 수 없음
OEM 컨텐츠로 ESXi 이미지를 업데이트하는 경우(예: Dell ESXi 7.0 업데이트 2a에서 Dell ESXi 7.0 업데이트 3d로) 일부 예약된 VIB(예: VMware 기본 이미지에 있지만 OEM에서 패키징한 비동기 VIB로 재정의됨)가 삭제될 수 있습니다. 중요하지 않은 기준선을 사용하여 시스템을 업데이트한 다음 OEM 컨텐츠가 있는 ESXi 이미지를 사용하여 더 높은 버전으로 업데이트한 후에도 동일한 문제가 발생할 수 있습니다. 예를 들어 중요하지 않은 기준선을 사용하여 7.0 업데이트 2로 업데이트한 다음 Dell ESXi 7.0 업데이트 3 이미지를 사용하여 7.0 업데이트 3으로 업데이트하면 예약된 VIB도 삭제될 수 있습니다. 따라서 업데이트된 버전의 ESXi 호스트를 사용하여 단일 이미지로 관리되는 vSphere Lifecycle Manager 클러스터를 생성할 수 없습니다. 작업이 실패하고 역추적에 다음과 같은 오류가 표시됩니다.
2021-11-24T09:42:49Z lifecycle: 2101166: HostSeeding:956 ERROR Extract depot failed: ('VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.0.18644231', 'Failed to add reserved VIB VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.0.18644231: not found in the reserved VIB cache storage')
2021-11-24T09:42:50Z lifecycle: 2101166: imagemanagerctl:373 ERROR Extract depot failed.
021-11-24T09:42:50Z lifecycle: 2101166: imagemanagerctl:152 ERROR [ReservedVibExtractError] ('VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.0.18644231', 'Failed to add reserved VIB VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.0.18644231: not found in the reserved VIB cache storage')
해결 방법: vSphere Lifecycle Manager 워크플로 대신 대화형 또는 스크립트로 작성된 업그레이드를 사용합니다.
- vCenter Server 7.0.0b로 업그레이드한 후 vSphere Client의 vSphere Lifecycle Manager 홈 보기에 [롤업 업데이트만 표시] 전환 버튼이 표시되지 않음
vCenter Server 7.0.0b에서는 롤업 업데이트만 표시 전환 버튼을 사용하여 vSphere Lifecycle Manager를 사용할 때 기준선에 포함하려는 패치를 필터링하고 선택할 수 있습니다.
이 버튼은 vSphere Client의 vSphere Lifecycle Manager 홈 보기인 Lifecycle Manager 창(메뉴 > Lifecycle Manager)의 업데이트 탭에서 사용할 수 있습니다. 이 버튼은 기준선 생성 마법사의 기준선 탭에 있는 수동으로 패치 선택 페이지에서도 사용할 수 있습니다. 이 마법사는 새로 만들기 > 기준선을 선택하면 열립니다.
하지만 vCenter Server 7.0.0b로 업그레이드한 후 롤업 업데이트만 표시 전환 버튼이 표시되지 않을 수 있습니다.
해결 방법: vCenter Server 7.0.0b로 업그레이드한 후 vSphere Client를 다시 시작합니다. 자세한 내용은 서비스 시작, 중지 및 다시 시작을 참조하십시오.
- vSphere Client의 vSphere Lifecycle Manager 홈 보기에서 탭을 열면 [롤업 업데이트만 표시] 전환 버튼이 항상 켜져 있음
vCenter Server 7.0.0b에서는 롤업 업데이트만 표시 전환 버튼을 사용하여 vSphere Lifecycle Manager를 사용할 때 기준선에 포함하려는 패치를 필터링하고 선택할 수 있습니다.
이 버튼은 vSphere Client의 vSphere Lifecycle Manager 홈 보기인 Lifecycle Manager 창(메뉴 > Lifecycle Manager)의 업데이트 탭에서 사용할 수 있습니다. 이 버튼은 기준선 생성 마법사의 기준선 탭에 있는 수동으로 패치 선택 페이지에서도 사용할 수 있습니다. 이 마법사는 새로 만들기 > 기준선을 선택하면 열립니다.
하지만 업데이트 탭 또는 수동으로 패치 선택 페이지로 이동할 때 전환 버튼이 항상 켜져 있습니다. 탭 또는 페이지 밖으로 이동할 때 버튼을 꺼도 다음에 해당 탭 또는 페이지를 열면 계속 켜져 있습니다.
해결 방법: 없음
- 업데이트 플래너를 사용하는 경우 vSphere Client에서 업데이트를 가져올 때 [업데이트를 가져오는 동안 예기치 않은 오류 발생] 메시지가 표시될 수 있음
vSphere Lifecycle Manager의 일부로, 용이한 vCenter Server 업데이트를 위해 사용하는 업데이트 플래너를 사용하는 경우 vSphere Client에서 다음과 같은 오류가 표시될 수 있습니다.
업데이트를 가져오는 동안 예기치 않은 오류 발생
이 문제는 vSphere Client를 사용하여 상호 운용성 보고서를 실행할 수 없도록 방지하는 사용자 지정 HTTPS 포트를 사용하는 경우에 발생합니다.
해결 방법: API를 수동으로 호출합니다. 자세한 내용은 vSphere Automation API를 참조하십시오.
- 버전 6.5의 호스트 프로파일을 버전 7.0의 ESXi 호스트에 적용하는 경우 규정 준수 검사에 실패함
버전 6.5의 호스트 프로파일을 버전 7.0의 ESXi 호스트에 적용하면 코어 덤프 파일 프로파일이 호스트 규정을 준수하지 않는 것으로 보고됩니다.
해결 방법: 가능한 해결 방법에는 두 가지가 있습니다.
- 버전 6.5의 호스트 프로파일을 생성하는 경우 ESXi 호스트에서 고급 구성 옵션 VMkernel.Boot.autoCreateDumpFile을 false로 설정합니다.
- 버전 6.5의 기존 호스트 프로파일을 적용하는 경우 호스트 프로파일에 고급 구성 옵션 VMkernel.Boot.autoCreateDumpFile을 추가하고 고정 정책에 대한 옵션을 구성한 후 값을 false로 설정합니다.
- 브라우저가 영어가 아닌 다른 언어로 설정된 경우 [작업] 드롭다운 메뉴에 항목이 포함되지 않음
브라우저가 영어가 아닌 다른 언어로 설정되어 있을 때 vSphere Client 인벤토리의 가상 시스템 요약 탭에서 새 보기로 전환 버튼을 클릭하면 게스트 운영 체제 패널의 작업 드롭다운 메뉴에 어떤 항목도 포함되지 않습니다.
해결 방법: 가상 시스템 페이지 상단에서 작업 드롭다운 메뉴를 선택합니다.
- 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에서 호스트 프로파일은 파일 기반 코어 덤프만 지원합니다.
- vi 편집기에서 마우스 오른쪽 버튼을 클릭하여 붙여넣을 수 없음
vCenter Server Appliance 인스턴스에서 vi 텍스트 편집기를 사용하는 경우 이전에 복사한 컨텐츠를 마우스 오른쪽 버튼으로 클릭하여 붙여넣을 수 없습니다. 대신 vi 편집기가 모드를 Visual로 변경합니다.
해결 방법: vCenter Server Appliance 셸에서 /usr/bin/sed -i.bak -E '2alet skip_defaults_vim=1' /etc/vimrc 명령을 실행합니다.
- 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 라이브러리를 대신 사용할 수 있습니다.
- 업데이트 적용 프로세스 중에 SNMP 동적 방화벽 규칙 집합이 호스트 프로파일에 의해 수정됨
SNMP 방화벽 규칙 집합은 런타임 중에 처리되는 동적 상태입니다. 호스트 프로파일이 적용되면 규칙 집합의 구성이 호스트 프로파일 및 SNMP에서 동시에 관리되므로 방화벽 설정이 예기치 않게 수정될 수 있습니다.
해결 방법: 가능한 해결 방법에는 두 가지가 있습니다.
- 규칙 집합이 동적으로 자체 관리되도록 하려면 호스트 프로파일 구성에서 SNMP 방화벽 규칙 집합 옵션을 제외합니다.
- 필요한 경우 규칙 집합의 이중 관리를 진행하려면 방화벽 규칙 집합 상태를 수정하십시오.
- 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를 구성한 후 재부팅하여 타사 디바이스 구성을 적용해야 합니다.
- 하위 창을 닫은 후 DCUI(Direct Console User Interface)의 상위 창 배경에 검은색 또는 회색 영역이 표시됨
DCUI에서 ESC 또는 Enter 키를 누르거나 취소 또는 확인 버튼을 눌러 하위 창을 닫은 경우 상위 창의 모양이 바뀔 수 있습니다. 상위 창 일부에 대해 배경색이 회색 또는 검은색으로 바뀝니다. 하지만 DCUI의 모든 필수 정보는 제대로 표시되고 DCUI에서 수행되는 모든 작업은 성공적으로 완료됩니다.
해결 방법: DCUI에서 현재 창을 새로 고치거나 어떤 키도 누르지 말고 1분 동안 기다립니다.
