VMware ESXi 5.5 업데이트 2 릴리스 정보

|

VMware ESXi™ 5.5 업데이트 2 | 2014년 9월 9일 | 빌드 2068190

마지막 업데이트 날짜: 2015년 7월 2일

이 릴리스 정보의 추가 사항 및 업데이트 사항을 확인하십시오.

릴리스 정보에 포함된 내용

릴리스 정보에는 다음과 같은 항목이 포함됩니다.

새로운 기능

이번 VMware ESXi 릴리스에는 다음과 같이 향상된 기능이 포함되어 있습니다.

  • 6TB RAM이 장착된 호스트 지원 - vSphere 5.5 업데이트 2는 이제 6TB RAM이 장착된 호스트를 지원합니다.
  • VMware vShield Endpoint Thin Agent가 VMware Tools Guest Introspection 플러그인으로 이름이 변경되었음 - VMware Tools와 함께 번들된 vShield Endpoint 드라이버를 이제 Guest Introspection으로 부릅니다.
  • 해결된 문제이 릴리스에서는 해결된 문제 섹션에서 설명된 여러 가지 버그 수정 사항을 제공합니다.

ESXi 5.5의 이전 릴리스

ESXi 5.5의 기능과 알려진 문제는 각 릴리스의 릴리스 정보에 설명되어 있습니다. 이전 릴리스의 ESXi 5.5에 대한 릴리스 정보는 다음과 같습니다.

국제화

VMware vSphere 5.5 업데이트 2는 다음과 같은 언어로 제공됩니다.

  • 영어
  • 프랑스어
  • 독일어
  • 일본어
  • 한국어
  • 중국어 간체
  • 중국어 번체

호환성 및 설치

ESXi, vCenter Server 및 vSphere Web Client 버전 호환성

VMware 제품 상호 운용성 매트릭스에는 ESXi, VMware vCenter Server, vSphere Web Client 및 선택적 VMware 제품을 포함한 VMware vSphere 구성 요소의 현재 버전과 이전 버전 사이의 호환성에 대한 자세한 내용이 나와 있습니다. ESXi 또는 vCenter Server를 설치하기 전에 VMware 제품 상호 운용성 매트릭스에서 지원되는 관리 및 백업 에이전트 관련 정보도 확인하십시오.

vSphere Client 및 vSphere Web Client는 vCenter Server ISO 패키지에 포함되어 있습니다. VMware vCenter™ 설치 관리자 마법사를 사용하여 클라이언트를 하나 또는 둘 다 설치할 수 있습니다.

ESXi, vCenter Server 및 VDDK 호환성

VDDK(Virtual Disk Development Kit) 5.5.3에는 ESXi 5.5 업데이트 2 및 vCenter Server 5.5 업데이트 2 릴리스에 대한 지원이 추가되었습니다.
VDDK에 대한 자세한 내용은 http://www.vmware.com/support/developer/vddk/를 참조하십시오.

ESXi 및 Virtual SAN 호환성

Virtual SAN에서는 5.5 업데이트 1 이전 버전의 ESXi 호스트로 구성된 클러스터를 지원하지 않습니다. Virtual SAN을 사용하도록 설정하려면 먼저 Virtual SAN 클러스터의 모든 호스트를 ESXi 5.5 업데이트 1 이상으로 업그레이드해야 합니다. vCenter Server도 5.5 업데이트 1 이상으로 업그레이드해야 합니다.

ESXi의 하드웨어 호환성

vSphere 5.5 업데이트 2과 호환되는 프로세서, 스토리지 디바이스, SAN 어레이 및 I/O 디바이스 목록을 보려면 VMware 호환성 가이드에 나와 있는 ESXi 5.5 업데이트 2 정보를 참조하십시오.

ESXi의 디바이스 호환성

ESXi 5.5 업데이트 2과 호환되는 디바이스를 확인하려면 VMware 호환성 가이드에서 ESXi 5.5 업데이트 2 정보를 참조하십시오.

일부 디바이스는 ESXi 5.5 이상에서 사용되지 않으며 더 이상 지원되지 않습니다. 업그레이드 프로세스를 수행하는 동안 디바이스 드라이버가 ESXi 5.5.x 호스트에 설치되고 ESXi 5.5.x에서 계속 작동 가능하지만 디바이스가 ESXi 5.5.x에서 지원되지는 않습니다. 사용되지 않고 ESXi 5.5.x에서 더 이상 지원되지 않는 디바이스 목록은 VMware 기술 자료 문서 더 이상 사용되지 않는 디바이스 및 ESXi 5.5 업그레이드 프로세스 중 경고를 참조하십시오.

ESXi의 타사 스위치 호환성

VMware는 vSphere 5.5에서 Cisco Nexus 1000V를 지원합니다. Cisco Nexus 1000V에 대한 자세한 내용은 Cisco 릴리스 정보를 참조하십시오. 이전 vSphere 릴리스와 마찬가지로 Cisco AVS(Application Virtual Switch)는 지원되지 않습니다.

ESXi의 게스트 운영 체제 호환성

vSphere 5.5 업데이트 2과 호환되는 게스트 운영 체제를 확인하려면 VMware 호환성 가이드에서 ESXi 5.5 업데이트 2 정보를 참조하십시오.

ESXi의 가상 시스템 호환성

ESX 3.x 이상(하드웨어 버전 4)과 호환되는 가상 시스템은 ESXi 5.5 업데이트 2에서 지원됩니다. ESX 2.x 이상(하드웨어 버전 3)과 호환되는 가상 시스템은 지원되지 않습니다. ESXi 5.5 업데이트 2에서 이와 같은 가상 시스템을 사용하려면 가상 시스템 호환성을 업그레이드하십시오. 자세한 내용은 vSphere 업그레이드 설명서를 참조하십시오.

vCenter Server 5.x를 사용하는 연결 모드 환경과 vSphere Client 간의 연결

vCenter Server 5.5은 연결 모드에서 vCenter Server 5.5의 다른 인스턴스와만 함께 있을 수 있습니다.

이 릴리스에 대한 설치 정보

ESXi 및 vCenter Server를 설치하고 구성하는 방법에 대한 지침은 vSphere 설치 및 설정 설명서를 참조하십시오.

설치는 간단하지만 여러 후속 구성 단계를 수행해야 합니다. 다음 설명서를 읽어 보십시오.

타사 솔루션 마이그레이션

호스트 업그레이드의 일부로 ESX 또는 ESXi 호스트에 설치된 타사 솔루션은 직접 마이그레이션할 수 없습니다. ESXi 5.1과 ESXi 5.5 간의 아키텍처 변경으로 타사 구성 요소가 손실되거나 시스템이 불안정해질 수 있습니다. 이러한 마이그레이션을 성공적으로 수행하려면 Image Builder를 사용하여 사용자 지정 ISO 파일을 생성합니다. 타사 사용자 지정 항목을 사용한 호스트 업그레이드에 대한 자세한 내용은 vSphere 업그레이드 설명서를 참조하십시오. Image Builder를 사용하여 사용자 지정 ISO를 만드는 방법에 대한 자세한 내용은 vSphere 설치 및 설정 설명서를 참조하십시오.

지원되지 않는 CPU에 대해 허용되지 않는 업그레이드 및 설치

vSphere 5.5.x에서는 LAHF 및 SAHF CPU 명령 집합이 포함된 CPU만 지원합니다. 설치 또는 업그레이드를 진행하는 동안 설치 관리자는 호스트 CPU가 vSphere 5.5.x와 호환되는지 여부를 확인합니다. 호스트 하드웨어가 호환되지 않는 경우 보라색 화면에 비호환성 관련 메시지가 표시됩니다. vSphere 5.5.x를 설치하거나 업그레이드할 수 없습니다.

이 릴리스의 업그레이드

vCenter Server 및 ESX/ESXi 호스트 업그레이드 방법에 대한 지침은 vSphere 업그레이드 설명서를 참조하십시오.

ESXi 5.5 업데이트 2로의 업그레이드에 대해 지원되는 업그레이드 경로:

업그레이드 자료

지원되는 업그레이드 도구

ESXi 5.5 업데이트 2로의 업그레이드를 위해 지원되는 경로

ESX/ESXi 4.0:
포함 버전:
ESX/ESXi 4.0 업데이트 1
ESX/ESXi 4.0 업데이트 2

ESX/ESXi 4.0 업데이트 3
ESX/ESXi 4.0 업데이트 4

ESX/ESXi 4.1:
포함 버전:
ESX/ESXi 4.1 업데이트 1
ESX/ESXi 4.1 업데이트 2

ESX/ESXi 4.1 업데이트 3

ESXi 5.0:
포함 버전:
ESXi 5.0 업데이트 1

ESXi 5.0 업데이트 2
ESXi 5.0 업데이트 3

ESXi 5.1
포함 버전:
ESXi 5.1 업데이트 1
ESXi 5.1 업데이트 2

ESXi 5.5
포함 버전:
ESXi 5.5 업데이트 1

VMware-VMvisor-Installer-5.5.0.update02-2068190.x86_64.iso

 

  • VMware vCenter Update Manager
  • CD 업그레이드
  • 스크립트로 작성된 업그레이드


update-from-esxi5.5-5.5_update02.zip
  • VMware vCenter Update Manager
  • ESXCLI
  • VMware vSphere CLI

아니요

아니요

예*

예*

VMware 포털(온라인)에서 다운로드한 패치 정의 사용 VMware vCenter Update Manager(패치 기준선 포함)

아니요

아니요

아니요

아니요


*참고: ESXCLI의 경우에만 update-from-esxi5.5-5.5_update02.zip을 사용하여 ESXi 5.0.x 또는 ESXi 5.1.x에서 ESXi 5.5 업데이트 2로 업그레이드할 수 있습니다. esxcli 소프트웨어 프로파일 업데이트 --depot=<depot_location> --profile=<profile_name> 명령을 실행하여 업그레이드를 수행해야 합니다. 자세한 내용은 vSphere 업그레이드 가이드에서 ESXi 5.5.x 업그레이드 옵션 항목을 참조하십시오.

VMware vSphere 5.5 업데이트 2의 오픈 소스 구성 요소

vSphere 5.5 업데이트 2에 배포되는 오픈 소스 소프트웨어 구성 요소에 적용되는 저작권 정보 및 라이센스는 http://www.vmware.com/download/vsphere/open_source.html 페이지의 Open Source(오픈 소스) 탭에서 확인할 수 있습니다. 이 페이지에서는 최신 vSphere 릴리스에 소스 코드 또는 소스 코드 수정 사항을 사용하는 데 필요한 모든 GPL, LGPL 또는 기타 유사한 라이센스의 소스 파일도 다운로드할 수 있습니다.

제품 지원 고지 사항

  • vSphere Web Client. Linux 플랫폼은 Adobe Flash에서 더 이상 지원되지 않으므로 vSphere Web Client는 Linux OS에서 지원되지 않습니다. Linux 데스크톱 OS에서 Adobe Flash를 추가 지원하는 타사 브라우저는 계속 작동할 수 있습니다.

    VMware vCenter Server Appliance. vSphere 5.5에서 VMware vCenter Server Appliance는 DISA STIG(Security Technical Information Guideline)를 적용함으로써 수준 높은 관리 규정 준수 표준을 충족합니다. VMware vCenter Server Appliance를 배포하기 전에 작업을 성공적으로 수행하려면 VMware 강화 가상 장치 작업 안내서에서 새 보안 배포 표준에 대한 정보를 참조하십시오.

  • vCenter Server 데이터베이스. vSphere 5.5에서는 vCenter Server 데이터베이스로 IBM DB2를 지원하지 않습니다.

  • VMware Tools. vSphere 5.5부터 vSphere에서 VMware Tools를 설치 및 구성하는 방법에 대한 모든 정보가 다른 vSphere 설명서와 병합됩니다. vSphere에서 VMware Tools를 사용하는 방법에 대한 자세한 내용을 보려면 vSphere 설명서를 참조하십시오. VMware Tools 설치 및 구성은 vSphere 5.5 이상과는 관련이 없습니다.

  • VMware Tools. vSphere 5.5부터 VMware Tools는 ThinPrint 기능을 제공하지 않습니다.

  • vSphere Data Protection. vSphere Web Client의 작동 방식이 변경되어 vSphere Data Protection 5.1이 vSphere 5.5와 호환되지 않습니다. vSphere Data Protection 5.1 사용자가 vSphere 5.5로 업그레이드하는 경우 vSphere Data Protection을 계속 사용하려면 vSphere Data Protection도 업데이트해야 합니다.

이 릴리스에 포함된 패치

이 릴리스에는 이 제품 출시 이전에 출시된 모든 ESXi 관련 공지가 포함됩니다. 개별 공지에 대한 자세한 내용은 VMware 패치 다운로드 페이지를 참조하십시오.

패치 릴리스 ESXi550-Update02에는 다음과 같은 개별 공지가 포함되어 있습니다.

ESXi550-201409201-UG: ESXi 5.5 esx-base vib 업데이트
ESXi550-201409202-UG: ESXi 5.5 tools-light vib 업데이트
ESXi550-201409203-UG: ESXi 5.5 net-tg3 vib 업데이트
ESXi550-201409204-UG: ESXi 5.5 sata-ahci vib 업데이트
ESXi550-201409205-UG: ESXi 5.5 scsi-megaraid-sas vib 업데이트
ESXi550-201409206-UG: ESXi 5.5 mi sc-drivers vib 업데이트
ESXi550-201409207-UG: ESXi 5.5 stomata vib 업데이트

a

패치 릴리스 ESXi550-Update02 Security-only에는 다음과 같은 개별 공지가 포함되어 있습니다.

ESXi550-201409101-SG: ESXi 5.5 esx-base vib 업데이트

패치 릴리스 ESXi550-Update02에는 다음과 같은 이미지 프로파일이 포함되어 있습니다.

ESXi-5.5.0-20140902001-standard
ESXi-5.5.0-20140902001-no-tools

패치 릴리스 ESXi550-Update02 Security-only에는 다음과 같은 이미지 프로파일이 포함되어 있습니다.

ESXi-5.5.0-20140901001s-standard
ESXi-5.5.0-20140901001s-no-tools

패치 및 업데이트 분류에 대한 자세한 내용은 KB 2014447을 참조하십시오.

해결된 문제

이 섹션에서는 이 릴리스에서 해결된 문제에 대해 설명합니다.

CIM 및 API 문제

  • ESXi 호스트가 높은 I/O 지연 시간을 경험할 수 있음
    CIM 요청을 대량으로 ESXi 호스트의 LSI SMI-S 제공자로 보낼 때 저장 공간 부족으로 인해 ESXi 호스트에서 높은 I/O 지연 시간이 발생할 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • vCenter Server에서 전원 공급 장치 정보의 상태가 알 수 없음으로 표시될 수 있음
    ESXi 호스트를 설치하고 vCenter Server에 연결한 후, vCenter Server 하드웨어 상태 탭에서 전원 공급 장치 정보가 알 수 없음으로 나타날 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • sfcbd 서비스를 중지하거나 다시 시작할 수 없음
    vCenter Server에서 하드웨어 모니터링 서비스(sfcbd)를 중지 및 시작하여 호스트의 하드웨어 상태를 모니터링할 때 sfcbd 프로세스가 중지되면서 다음과 유사한 오류가 syslog 파일에 기록될 수 있습니다.

    sfcbd: Sending TERM signal to sfcbd
    sfcbd-watchdog: Sleeping for 20 seconds
    sfcbd: Sending TERM signal to sfcbd
    sfcbd-watchdog: Sleeping for 20 seconds
    sfcbd-watchdog: Waited for 3 20 second intervals, SIGKILL next
    sfcbd: Stopping sfcbd
    sfcbd-watchdog: Sleeping for 20 seconds
    sfcbd-watchdog: Providers have terminated, lets kill the sfcbd.
    sfcbd-watchdog: Reached max kill attempts. watchdog is exiting


    이 문제는 이 릴리스에서 해결되었습니다.
  • sfcb가 잘못된 메서드 제공자로 응답할 수 있음
    ESXi 호스트에서 서로 다른 두 개의 메서드 제공자를 네임스페이스가 다른 동일한 CIM 클래스에 등록할 경우 요청 시 sfcb는 항상 providerRegister의 상위에 가장 가까운 제공자로 응답합니다. 이것은 잘못된 메서드 제공자일 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • ESXi 호스트의 상태를 확인할 때 hostd가 응답하지 않을 수 있음
    vSphere Client를 ESXi 호스트에 연결하여 상태를 확인하고 새로 고침 작업을 수행하면 hostd 서비스가 응답하지 않을 수 있습니다. 다음과 유사한 로그가 hostd.log에 기록됩니다.

    YYYY-MM-DDThh:mm:ss.344Z [5A344B90 verbose \\\'ThreadPool\\\'] usage : total=22 max=74 workrun=22 iorun=0 workQ=0 ioQ=0 maxrun=30 maxQ=125 cur=W

    이 문제는 이 릴리스에서 해결되었습니다.
  • 하드웨어 상태 모니터링이 응답하지 못할 수 있음
    하드웨어 상태 모니터링이 응답하지 않을 수 있고 CIM 제공자가 다음과 유사한 오류 메시지를 표시할 수 있습니다.

    2014-02-25T02:15:34Z sfcb-CIMXML-Processor[233738]: PAM unable to dlopen(/lib/security/$ISA/pam_passwdqc.so): /lib/security/../../lib/security/pam_passwdqc.so: cannot open shared object file: Too many open files2014-02-25T02:15:34Z sfcb-CIMXML-Processor[233738]: PAM adding faulty module: /lib/security/$ISA/pam_passwdqc.so2014-02-25T02:15:34Z sfcb-CIMXML-Processor[233738]: PAM unable to dlopen(/lib/security/
    The SFCB service might also stop responding.


    이 문제는 이 릴리스에서 해결되었습니다.
  • ESXi 호스트의 하드웨어 상태를 모니터링하려고 시도할 때 WBEM(Web Based Enterprise Management) 쿼리가 실패할 수 있음
    ESXi 호스트의 하드웨어 상태를 모니터링하려고 시도할 때 WBEM 쿼리가 실패할 수 있습니다. 다음과 유사한 오류 메시지가 syslog 파일에 기록됩니다.

    Timeout error accepting SSL connection exiting.

    이 문제를 해결하기 위해 시간 초과 값을 설정할 수 있는 새 httpSelectTimeout 구성이 추가되었습니다.

  • XML 구문 분석 오류가 WSMAN Client에서 발생할 수 있음
    Web Server Manager(WSMAN) Client에서, ESXi WSMAN 에이전트(openwsman)에서 호출된 CIM 메서드의 반환 값에 왼쪽 꺾쇠 괄호(<) 또는 앰퍼샌드(&)와 같은 XML 예약 문자가 포함되어 있는 경우 XML 구문 분석 오류가 발생할 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.

게스트 운영 체제 문제

  • VideoReDo 애플리케이션으로 편집하면 비디오가 여러 번 나타날 수 있으며 왜곡된 이미지가 나타날 수 있음
    VideoReDo를 사용하여 비디오를 편집하면 비디오가 여러 번 표시될 수 있습니다. 또한 비디오를 편집하는 중 왜곡된 이미지가 눈에 띌 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • ESXi 호스트에서 디스크 유틸리티를 사용하여 MAC OS X 게스트 운영 체제의 디스크 파티션 크기를 늘릴 수 없음
    ESXi 호스트에서 디스크 유틸리티를 사용하여 MAC OS X 게스트 운영 체제의 디스크 파티션 크기를 늘릴 수 없습니다. VMware Fusion을 사용하여 크기를 늘리려고 할 때는 이 문제가 발생하지 않습니다.

    이 문제는 디스크 크기를 늘린 후 GPT(GUID 파티션 테이블)에서 헤더를 변경하는 방법으로 이 릴리스에서 해결되었습니다.
  • Bios 강제 설치 옵션이 실패할 수 있음
    vSphere Client에서 가상 시스템 구성 옵션인 BIOS 강제 설치가 실패하고 다음과 같은 오류 메시지가 나타날 수 있습니다.

    현재 상태(전원이 켜짐)에서는 시도된 작업을 수행할 수 없습니다.

    이 문제는 이 릴리스에서 해결되었습니다.

기타 문제

  • PCI Passthrough Device Emulex Quad Port LPE12004가 있는 가상 시스템의 전원을 켜면 보라색 진단 화면이 표시되면서 ESXi 호스트가 실패할 수 있음
    PCI Passthrough Device Emulex Quad Port LPE12004가 있는 가상 시스템의 전원을 켜면 보라색 진단 화면이 표시되면서 ESXi 호스트가 실패할 수 있습니다.
    다음 오류 메시지가 표시됩니다.

    cpu20:32852)@BlueScreen: #PF Exception 14 in world 32852:helper1-1 IP 0x41803baf7319 addr 0x410800fd3fa0
    PTEs:0x13f1f1023;0x208569d063;0x0;
    cpu20:32852)Code start: 0x41803ba00000 VMK uptime: 0:02:15:58.810
    cpu20:32852)0x4123c151de50:[0x41803baf7319]BackMap_Lookup@vmkernel#nover+0x35 stack: 0xffffffff00000000
    cpu20:32852)0x4123c151df00:[0x41803ba69483]IOMMUDoReportFault@vmkernel#nover+0x133 stack: 0x500000701
    cpu20:32852)0x4123c151df30:[0x41803ba69667]IOMMUProcessFaults@vmkernel#nover+0x1f stack: 0x0
    cpu20:32852)0x4123c151dfd0:[0x41803ba60f8a]helpFunc@vmkernel#nover+0x6b6 stack: 0x0
    cpu20:32852)0x4123c151dff0:[0x41803bc53242]CpuSched_StartWorld@vmkernel#nover+0xfa stack: 0x0
    cpu20:32852)base fs=0x0 gs=0x418045000000 Kgs=0x0

    vmkernel.log에 다음과 유사한 항목이 나타납니다.

    cpu0:1097177)WARNING: IOMMUIntel: 2436: DMAR Fault IOMMU Unit #1: R/W=W, Device 0000:07:00.1 Faulting addr = 0xfd3fa000 Fault Reason = 0x05 -> PTE not set to allow Write.^[[0m
    cpu0:1097177)WARNING: IOMMUIntel: 2493: IOMMU context entry dump for 0000:07:00.1 Ctx-Hi = 0x302 Ctx-Lo = 0x14ac52001^[[0m


    이 문제는 이 릴리스에서 해결되었습니다.

  • ESXi 5.5에 대한 USB 디바이스 정보가 잘못되었을 수 있음
    /etc/vmware/usb.ids에 제공되는 USB 디바이스 정보에 잘못된 벤더 정보가 표시될 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • BAR 크기가 4KB 미만인 PCI 디바이스를 패스스루 디바이스로 추가하는 경우 가상 시스템 전원이 켜지지 않을 수 있음
    BAR(기준 주소 레지스터) 크기가 4KB 미만인 PCI 디바이스를 패스스루 디바이스로 추가하는 경우 가상 시스템 전원이 켜지지 않을 수 있습니다.
    다음과 같은 메시지가 vmware.log 파일에 기록됩니다.

    PCIPassthru: Device 029:04.0 barIndex 0 type 2 realaddr 0x97a03000 size 128 flags 0
    PCIPassthru: Device 029:04.0 barIndex 1 type 2 realaddr 0x97a01000 size 1024 flags 0
    PCIPassthru: Device 029:04.0 barIndex 2 type 2 realaddr 0x97a02000 size 128 flags 0
    PCIPassthru: Device 029:04.0 barIndex 3 type 2 realaddr 0x97a00000 size 1024 flags 0
    PCIPassthru: 029:04.0 : barSize: 128 is not pgsize multiple
    PCIPassthru: 029:04.0 : barSize: 1024 is not pgsize multiple
    PCIPassthru: 029:04.0 : barSize: 128 is not pgsize multiple
    PCIPassthru: 029:04.0 : barSize: 1024 is not pgsize multiple>

    이 문제는 이 릴리스에서 해결되었습니다.
  • Windows 2008 R2 및 Solaris 10 64비트 가상 시스템이 ESXi 5.x에서 실행되는 경우 블루 스크린 또는 커널 패닉이 발생하면서 실패함
    Windows 2008 R2 또는 Solaris 10 64비트를 사용하여 가상 시스템을 실행하는 경우 다음과 같은 증상이 나타날 수 있습니다.

    • Windows 2008 R2 VM이 블루 스크린 및 다음과 같은 이벤트와 함께 실패합니다.
      0x0000000a - IRQL_NOT_LESS_OR_EQUAL
      0x0000001a - MEMORY_MANAGEMENT
      0x000000fc - ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY
      0x0000004e - PFN_LIST_CORRUPT
      0x00000050 - PAGE_FAULT_IN_NONPAGED_AREA
      0x0000003B- SYSTEM_SERVICE_EXCEPTION


    • Solaris 10 64비트 VM이 커널 패닉과 함께 실패합니다.
      자세한 내용은 KB 2073791을 참조하십시오.

    이 문제는 이 릴리스에서 해결되었습니다.

네트워킹 문제

  • 업링크가 불안정할 때 보라색 화면이 표시되며 ESXi 호스트가 실패할 수 있음
    업링크가 불안정할 때 ESXi 호스트에 장애가 발생할 수 있으며 보라색 화면에 다음과 유사한 오류 메시지가 표시됩니다.

    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UplinkRxQueuesLoadBalance@vmkernel#nover+0xnnn stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UplinkLB_LoadBalanceCB@vmkernel#nover+0x8e stack: 0xnnnnnnnnnnnn, 0x
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UplinkAsyncProcessCallsHelperCB@vmkernel#nover+0x223 stack: 0x0, 0x4
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]helpFunc@vmkernel#nover+0x6b6 stack: 0x0, 0x0, 0x0, 0x0, 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CpuSched_StartWorld@vmkernel#nover+0xfa stack: 0x0, 0x0, 0x0, 0x0, 0


    NIC에 Qlogic UCNA 드라이버를 사용하는 경우, ESXi 5.5 호스트의 업링크 포트의 상태가 불안정해지고 다음과 유사한 오류가 vmkernel.log에 기록됩니다.

    vmnic3:qlcnic_issue_cmd:372:Failed card response err_code: 0xn
    vmnic3:qlcnic_fw_cmd_destroy_tx_ctx:827:Failed to destroy tx ctx in firmware, err_code : 8
    vmnic3:qlcnic_dev_request_reset:6879:Changed the adapter dev_state to NEED_RESET.
    vmnic3:qlcnic_check_health:7485:Adapter not in operational state(Heartbit Failure), resetting adapter.
    <6>qlcnic 0000:04:00.1:
    vmnic3:qlcnic_check_peg_halt_status:6722:PEG_HALT_STATUS1: 0xnnnnnnnn, PEG_HALT_STATUS2: 0xnnnnnn.
    vmnic3:qlcnic_detach:2337:Deleted Tx and Rx loopback filters.
    vmnic3:qlcnic_disable_bus_master:1042:Disabled bus mastering.
    vmnic3:qlcnic_free_rx_irq:2008:Freed vmnic3_rx[0] irq.
    vmnic3:qlcnic_ctx_free_tx_irq:1859:Freed vmnic3_txq[0] irq #85.


    이 문제는 이 릴리스에서 해결되었습니다.
  • 많은 수의 dvPort 그룹이 vCenter Server에 연결되었을 때 vApp 시작 시간이 늘어날 수 있음
    많은 수의 dvPort 그룹이 vCenter Server에 연결되면 vApp 시작 시간이 증가할 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 다중 VMkernel 인터페이스가 구성되었을 때 SLP가 UDP 쿼리 네트워크 패킷을 보내지 못할 수 있음
    다중 vmkernel 패킷을 구성할 때 SLP(Service Location Protocol)가 UDP 쿼리 네트워크 패킷을 보내지 못할 수 있습니다. 그 결과, 방화벽이 응답 패키지를 삭제합니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 제한된 대기열 크기로 인해 애플리케이션에서 보낸 데이터 패킷 버스트가 vDS 또는 표준 vSwitch에서 삭제될 수 있음
    vDS(vNetwork Distributed Switch) 또는 트래픽 조절이 가능한 표준 vSwitch에서는 애플리케이션에서 보낸 데이터 패킷 버스트가 제한된 대기열 크기로 인해 삭제될 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 잘못된 페이로드 파일 이름으로 인해 상태 비저장 캐시 이미지를 사용하여 ESXi 호스트를 부팅하려는 시도가 실패할 수 있음
    Auto Deploy가 호스트를 부팅하지 못할 때 상태 비저장 캐시 이미지를 사용하여 ESXi 호스트를 부팅할 수 없습니다.
    호스트가 캐시된 이미지를 사용하여 부팅을 시도할 때 다음과 유사한 오류가 표시됩니다.

    파일을 찾을 수 없습니다. 치명적 오류: 15 (찾을 수 없음)

    Auto Deploy를 ESXi 5.0에서 ESXi 5.x로 업그레이드하고 새 Auto Deploy 환경에서 동일한 이미지를 사용할 때 이 문제가 발생합니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • VDS(vSphere Distributed Switch) 상태 점검을 수행하는 동안 잘못된 상태 점검 결과가 보고될 수 있음
    VLAN, MTU 및 팀 구성 정책의 상태를 모니터링하기 위해 VDS Web Client 상태 점검을 수행할 때 잘못된 결과가 보고될 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 로드가 높은 필터가 동일한 Rx-Netqueue를 점유할 수 있음
    사용 가능한 대기열이 있는 상태에서도 Rx 처리가 사용 가능한 Rx-Netqueues로 고르게 분산되지 않을 수 있습니다. 로드가 높은 필터가 단일 대기열 내에 가득 차는 일부 로드 패턴으로 인해 물리적 NIC 대역폭의 활용률이 낮을 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.

보안 문제

  • glibc 패키지 업데이트
    보안 문제를 해결하기 위해 ESXi glibc-2.5 패키지가 업데이트되었습니다.
    일반 취약성 및 노출 프로젝트(cve.mitre.org)에서는 이러한 문제에 CVE-2013-0242CVE-2013-1914라는 이름을 할당했습니다.
     

서버 구성 문제

  • Ethtool 유틸리티가 Emulex 10Gb 이더넷(10GbE) 554FLR-SFP 어댑터에 대해 잘못된 케이블 유형을 보고할 수 있음
    Ethtool 유틸리티가 Emulex 10Gb 이더넷(10GbE) 554FLR-SFP 어댑터에 대해 잘못된 케이블 연결 유형을 보고할 수 있습니다. 이것은 ethtool이 DAC(Direct Attached Copper) 포트 유형을 지원할 수 없기 때문입니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • iSCSI 원격 LUN에서 ESXi 설치가 실패할 수 있음
    iSCSI 원격 LUN에서 ESXi를 설치하려는 시도가 실패하고 다음 오류가 표시될 수 있습니다.

    부팅 뱅크 2개가 필요함, 0개 발견.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 가상 시스템의 I/O 응답이 느릴 수 있음
    기본 I/O 스케줄러로 활성화된 ESXi 호스트에서 하나 이상의 가상 시스템이 장시간 디바이스의 최대 I/O 대역폭을 이용하기 때문에 IOPS 불균형이 일어납니다. 이 문제는 ESXi 기본 I/O 스케줄러에서 식별된 경합 조건으로 인해 발생합니다.

    이 릴리스에서는 ESXi 호스트의 VM 간에 IOPS 균일성을 보장하여 문제가 해결되었습니다. 
  • 스토리지 디바이스에서 16TB 이상의 VMFS5 데이터스토어를 생성하려는 시도가 실패함
    스토리지 디바이스에서 16TB 이상의 VMFS5 데이터스토어를 생성하려고 하면 ESXi 호스트가 실패할 수 있습니다. 다음과 유사한 오류가 vmkernel.log에 기록됩니다.

    WARNING: LVM: 10032: Invalid firstPE 3758096383
    WARNING: LVM: 10039: Invalid lastPE 3758096383
    WARNING: LVM: 5242: Error detected for vol 526f639f-93de6438-940e-d48cb5bc414c, dev naa.60000970000195700908533037393545:1
    2013-11-05T09:50:56.997Z cpu10:34259)LVM: 7133: Device scan failed for <1> : Invalid metadata
    FSS: 5051: No FS driver claimed device 'naa.60000970000195700908533037393545:1': Not supported
    VC: 1958: Device rescan time 24 msec (total number of devices 9)
    VC: 1961: Filesystem probe time 56 msec (devices probed 7 of 9)
    VC: 1963: Refresh open volume time 0 msec
    LVM: 7525: Initialized naa.60000970000195700908533037393545:1, devID 5278bf81-af41c8bd-3c21-d48cb5bc414c
    LVM: 7613: Zero volumeSize specified: using available space (30786340240896).
    LVM: 13082: One or more LVM devices have been discovered.
    LVM: 7689: Error "No space left on device" creating volume 5278bf81-82937d98-3734-d48cb5bc414c on device naa.60000970000195700908533037393545:1.</1>


    이 문제는 이 릴리스에서 해결되었습니다.
  • VMware vSphere WebService SDK에서 VI 편집기를 사용하여 endpoints.conf 파일을 편집하려는 시도가 실패함
    VI 편집기에서 /etc/vmware/rhttpproxy/endpoints.conf 파일을 편집하려고 할 때 다음과 유사한 오류 메시지가 나타날 수 있습니다.

    작업이 허용되지 않습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 가상 시스템을 트래픽 필터링 규칙이 적용된 vSphere Distributed Switch 5.5 포트 그룹에 추가할 수 없음
    VDS(vSphere 5.5 Distributed Switch)에서 트래픽 필터링 규칙을 구성하고 나면 다음 두 가지 문제가 발생합니다.
    • 트래픽 필터링 규칙이 적용된 분산 스위치 포트 그룹에 가상 시스템을 연결할 때 vSphere Client 또는 vSphere Web Client에 다음 오류가 표시됩니다.

      호스트 hostname에서 VDS switchname의 DVPort portnumber을(를) 생성할 수 없음
      일반 시스템 오류가 발생했습니다.

    • 포트 그룹의 기존 트래픽 필터링 규칙을 수정하려고 시도할 때 다음 오류가 표시됩니다.

      하나 이상의 호스트 멤버에 대한 vSphere Distributed Switch 작업을 완료할 수 없습니다.
      vDS 작업이 호스트 hostname에서 실패. [ TCP:hostname:443>]: invokeHostTransactionCall 에서 잘못된 SOAP 응답 수신
      [ ]: invokeHostTransactionCall 에서 잘못된 SOAP 응답 수신
      일반 시스템 오류가 발생했습니다. (vmodl.fault.SystemError) 예외가 발생했습니다.

    hostd.log 파일(대상 ESXi 호스트의 /var/log/에 있음)에 다음과 유사한 항목이 있습니다.

    YYYY-02-07T17:57:21.859Z [FF90D5B0 error 'Default' opID=577f035c-5f user=vpxuser] AdapterServer caught unexpected exception: Not a valid netmask

    이 문제는 이 릴리스에서 해결되었습니다.

  • 호스트를 로컬 캐시에서 부팅할 때 호스트가 도메인에 가입할 수 없음
    시스템을 다시 시작하는 도중 ESXi 호스트가 Auto Deploy에 연결할 수 없고 로컬 캐시에서 부팅해야 할 경우 재부팅 시 설정이 유지되지 않을 수 있고 ESXi 호스트가 AD(Active Directory)에서 제거될 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.

  • ESXi를 설치하거나 업그레이드할 때 지원되는 4GB 및 6GB USB 플래시 드라이버에 2.5GB 코어 덤프 파티션이 생성되지 않을 수 있음
    ESXi 호스트를 설치하거나 업그레이드할 때 지원되는 4GB 및 6GB USB 드라이버에서 2.5GB 코어 덤프 파티션이 생성되지 않을 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 스토리지 과부하로 인해 Cisco UCS 블레이드 서버에서 ESXCLI 명령이 실패할 수 있음
    스토리지 과부하로 인해 Cisco UCS 블레이드 서버에서 ESXCLI 명령이 실패할 수 있습니다. 다음과 유사한 오류 메시지가 hostd.log 파일에 기록될 수 있습니다.

    2013-12-13T16:24:57.402Z [3C5C9B90 verbose 'ThreadPool'] usage : total=20 max=62 workrun=18 iorun=2 workQ=78 ioQ=0 maxrun=31 maxQ=79 cur=I
    2013-12-13T16:24:57.403Z [3C5C9B90 verbose 'ThreadPool'] usage : total=20 max=62 workrun=18 iorun=2 workQ=78 ioQ=0 maxrun=31 maxQ=79 cur=I
    2013-12-13T16:24:57.404Z [3BEBEB90 verbose 'ThreadPool'] usage : total=21 max=62 workrun=18 iorun=3 workQ=78 ioQ=0 maxrun=31 maxQ=79 cur=I
    2013-12-13T16:24:58.003Z [3BEBEB90 verbose 'ThreadPool'] usage : total=21 max=62 workrun=18 iorun=3 workQ=78 ioQ=0 maxrun=31 maxQ=79 cur=I
    2013-12-13T16:24:58.282Z [3C9D4B90 verbose 'ThreadPool'] usage : total=22 max=62 workrun=18 iorun=4 workQ=78 ioQ=0 maxrun=31 maxQ=79 cur=I

    이 문제는 이 릴리스에서 해결되었습니다.
  • X-vMotion을 수행할 때 ESXi 호스트가 실패하고 보라색 화면이 표시될 수 있음
    X-vMotion을 수행할 때 ESXi 호스트가 다음과 유사한 오류 메시지와 함께 보라색 화면을 표시하면서 실패할 수 있습니다.

    #PF Exception 14 in world 301646:vpxa-worker IP 0x41801c281c03 addr 0x0
    PTEs:0x1aabaa027;0x1c7a86027;0x0;
    2014-01-16T09:36:52.171Z cpu0:301646)Code start: 0x41801b600000 VMK uptime: 1:03:55:02.989
    2014-01-16T09:36:52.180Z cpu0:301646)0x41242939d430:[0x41801c281c03]XVMotion_FreeBlocks@esx#nover+0x1f stack: 0x41801ba34b3d
    2014-01-16T09:36:52.192Z cpu0:301646)0x41242939d4a0:[0x41801c23abc2]SVMAsyncIOReadDone@svmVMware#0+0x1d2 stack: 0x412ed091a740
    2014-01-16T09:36:52.204Z cpu0:301646)0x41242939d4d0:[0x41801b62d29f]AsyncPopCallbackFrameInt@vmkernel#nover+0xe7 stack: 0x412eca9d6ac0

    이 문제는 이 릴리스에서 해결되었습니다.
  • SNMP의 관리 시스템이 큰 파일 시스템에 대해 잘못된 ESXi 볼륨 크기를 보고할 수 있음
    SNMP 또는 SNMP에 의존하는 관리 소프트웨어를 사용하여 ESXi를 모니터링할 때 SNMP의 관리 시스템이 큰 파일 시스템의 볼륨 크기를 검색할 때 잘못된 ESXi 볼륨 크기를 보고할 수 있습니다. 이 릴리스에는 대용량 파일 시스템을 지원하는 새 스위치가 도입되었습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 둘 이상의 대상이 서로 다른 포트에서 표시를 수신하는 경우 sfcb 서비스가 CIM 표시 전달을 위해 ESXi 방화벽을 열지 못할 수 있음
    sfcb 서버는 각 포트가 CIM 표시를 보내기 위한 방화벽 규칙을 하나 생성합니다. 대상은 이 포트에서 표시를 수신합니다. 두 개 이상의 대상이 서로 다른 포트에서 표시를 수신할 경우 sfcb 서비스가 CIM 표시 전달을 위해 ESXi 방화벽을 열지 못합니다.
    이 문제는 sfcb 서비스가 방화벽 규칙에 고정된 이름을 사용하고 단일 규칙 집합에서 중복 규칙 이름은 허용되지 않으므로 다중 포트에 대한 두 개 이상의 규칙을 생성하지 못할 때 발생합니다.

    이 릴리스에서는 여러 방화벽 규칙에 대한 규칙 이름이 서로 충돌하지 않도록 포트 번호를 규칙 이름의 접미사로 사용하여 이 문제를 해결했습니다.
  • ESXi 호스트에서 규정 준수 검사를 수행할 때 오류 메시지가 발생할 수 있음
    ESXi 호스트에서 규정 준수 검사를 수행할 때 vSphere Client에 다음과 유사한 오류 메시지가 표시될 수 있습니다.

    Found extra CIM-XML Indication Subscription on local system for query u'select * from CIM_AlertIndication' sent to destination u'https://IP:port'

    이 문제는 이 릴리스에서 해결되었습니다.
  • ESXi 호스트를 재부팅한 후 AD 사용자 또는 그룹에 대한 권한이 유지되지 않을 수 있음
    호스트 프로파일을 사용하여 ESXi 호스트에 AD(Active Directory) 사용자 또는 그룹에 대한 권한을 설정할 때 Auto Deploy가 설치된 ESXi 호스트를 재부팅한 후 권한이 유지되지 않을 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • vCenter Server의 하드웨어 상태 탭에 메모리 주의 및 메모리 경고 메시지가 보고될 수 있음
    IPMI SEL(System Event Log)의 Memory Presence Detected 행에 Assert 또는 Deassert 항목이 기록된 경우 vCenter Server의 하드웨어 상태 탭에 메모리 주의 및 메모리 경고 메시지가 보고될 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • ESXi 호스트의 WSMAN Client에서 CIM 인스턴스 쿼리를 수행하면 XML 구문 분석 오류가 발생할 수 있음
    ESXi 호스트의 Web Server Manager(WSMAN) Client에서 속성 중 하나에 특수 문자를 포함하여 CIM 인스턴스를 쿼리할 때 XML 구문 분석 오류가 발생할 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • Trend Micro Deep Security Manager가 ESXi 5.5 호스트를 준비하지 못함
    Trend Micro Deep Security Manager 인터페이스에서 Prepare ESX Server 마법사를 실행할 때 ESXi 5.5 호스트에서 필터 드라이버를 설치하는 중 실패합니다. 다음 오류 메시지가 표시됩니다.

    설치 트랜잭션 실패

    esxupdate.log 파일(ESXi 호스트의 /var/log/에 있음)에 다음과 유사한 항목이 있습니다.

    YYYY-01-09T06:21:32Z esxupdate: BootBankInstaller.pyc: INFO: /altbootbank/boot.cfg: bootstate changed from 3 to 3
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: An esxupdate error exception was caught:
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: Traceback (most recent call last):
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/usr/sbin/esxupdate", line 216, in main
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: cmd.Run()
    fckLR YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/build/mts/release/bora-1331820/bora/build/esx/release/vmvisor/sys-boot/lib/python2.6/site-packages/vmware/esx5update/Cmdline.py", line 144, in Run
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/build/mts/release/bora-1331820/bora/build/esx/release/vmvisor/sys-boot/lib/python2.6/site-packages/vmware/esximage/Transaction.py", line 245, in InstallVibsFromSources
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/build/mts/release/bora-1331820/bora/build/esx/release/vmvisor/sys-boot/lib/python2.6/site-packages/vmware/esximage/Transaction.py", line 347, in _installVibs
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/build/mts/release/bora-1331820/bora/build/esx/release/vmvisor/sys-boot/lib/python2.6/site-packages/vmware/esximage/Transaction.py", line 390, in _validateAndInstallProfile
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/build/mts/release/bora-1331820/bora/build/esx/release/vmvisor/sys-boot/lib/python2.6/site-packages/vmware/esximage/HostImage.py", line 692, in Stage
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: File "/build/mts/release/bora-1331820/bora/build/esx/release/vmvisor/sys-boot/lib/python2.6/site-packages/vmware/esximage/HostImage.py", line 478, in _download_and_stage
    YYYY-01-09T06:21:32Z esxupdate: esxupdate: ERROR: InstallationError: ('Trend_bootbank_dvfilter-dsa_9.0.0-2636', '[Errno 4] Socket Error: [Errno 1] _ssl.c:1332: error:0906D06C:PEM routines:PEM_read_bio:no start line')


    이 문제는 이 릴리스에서 해결되었습니다.
  • Veeam 백업을 수행한 후 ESXi 호스트가 vCenter Server에서 연결이 끊길 수 있음
    Veeam 백업을 수행한 후 ESXi 호스트가 vCenter Server에서 연결이 끊길 수 있습니다.
    Veaam이 가상 시스템의 스냅샷을 생성하려고 할 때 이 문제가 발생합니다.
    다음과 유사한 오류 메시지가 hostd.log 파일에 기록됩니다.

    --> Crash Report build=1312873
    --> Signal 11 received, si_code -128, si_errno 0
    --> Bad access at 735F6572

    이 문제는 이 릴리스에서 해결되었습니다.
  • 호스트에 다중 스토리지 디바이스가 구성되어 있는 경우 vCenter Server에서 관리되는 ESXi 호스트에서 호스트 프로파일을 생성하고 배포하는 데 시간이 오래 걸리거나 실패할 수 있음
    호스트에 다중 스토리지 디바이스가 구성되어 있고 호스트 캐시에 SSD를 사용하도록 설정되었을 때 vCenter Server에서 관리되는 ESXi 호스트에서 호스트 프로파일을 생성하고 배포하는 데 시간이 오래 걸리거나 실패할 수 있습니다.
    다음과 유사한 오류 메시지가 vSphere Client에 표시됩니다.

    오류: vcenter가 응답하는 데 시간이 너무 많이 걸렸습니다. 오류 스택: vCenter Server "your.vcenter.server.fqdn"에서 개체 "HostProfileManager"에 대한 호출 "HostProfileManager.CreateProfile"이 실패했습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • ESXi 호스트가 페이지 장애 예외를 나타내면서 실패함
    ESXi 호스트가 응답하지 않고 보라색 진단 화면에 페이지 장애 예외가 발생했음을 나타냅니다.
    다음과 유사한 역추적이 나타납니다.

    @BlueScreen: #PF Exception 14 in world 33020:reset-handle IP 0x418007961885 addr 0x14
    PTEs:0xnnnnnnnnn;0xnnnnnnnnn;0xnnnnnnnnn;0x0;
    Code start: 0xnnnnnnnnnnnn VMK uptime: 3:23:09:37.928

    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VFlashAbortMatchingObjectAsyncIO@com.vmware.vmkapi#v2_2_0_0+0xc1 sta
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]vmk_VFlashIoctl@com.vmware.vmkapi#v2_2_0_0+0x83 stack: 0x417fc6e6014
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VFlashAbortMatchingDeviceAsyncIO@com.vmware.vmkapi#v2_2_0_0+0x248 st
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VFlash_Ioctl@com.vmware.vmkapi#v2_2_0_0+0x247 stack: 0x412383f1ded0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DevFSFileResetCommand@vmkernel#nover+0x1b5 stack: 0x412383f1df20
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSCSI_FSResetTarget@vmkernel#nover+0x3a stack: 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSCSIResetWorldFunc@vmkernel#nover+0x459 stack: 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CpuSched_StartWorld@vmkernel#nover+0xfa stack: 0x0


    이 문제는 이 릴리스에서 해결되었습니다.
  • 호스트 프로파일을 적용하면 상태 비저장 캐시로 프로비저닝된 호스트에 대한 규정 준수 검사가 실패할 수 있음
    시스템 이미지 캐시 프로파일 설정 드롭다운 메뉴에서 호스트에서 USB 디스크에 대해 상태 비저장 캐시 사용 옵션을 선택하여 호스트 프로파일이 상태 비저장 캐시를 사용하도록 구성하고 호스트 프로파일을 적용하면 호스트에서 규정 준수 검사가 실패할 수 있습니다.
    로컬 SAS 디바이스가 무시되어 로컬 디바이스에 대한 규정 준수가 실패할 때 이 문제가 발생합니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 하이퍼바이저 스와핑 도중 ESXi 호스트에 보라색 화면이 나타날 수 있음
    NUMA 서버에서 ESXi 호스트를 ESXi 5.5 업데이트 1로 업그레이드한 후(이 서버에서는 첫 번째 NUMA 노드에 메모리를 할당하지 않았음) 호스트에 다음과 같은 역추적을 포함한 보라색 진단 화면이 나타날 수 있습니다.

    Backtrace for current CPU #X, worldID=X, ebp=0xnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]MemNode_MPN2ID@vmkernel#nover+0x1a stack: 0xnnnnnnnnn, 0xnnnnnn


    이 문제는 이 릴리스에서 해결되었습니다.
  • LSI MegaRaid 디스크의 상태 변경이 표시되지 않거나 지연될 수 있음
    ESXi 5.x 호스트에서 MegaRaid SAS 디바이스 드라이버와 함께 LSI SMI-S 제공자를 사용할 경우, enum_instances LSIESG_PhysicalDrive lsi/lsimr13 명령을 실행할 때 LSI MegaRaid 디스크의 상태 변경이 표시되지 않거나 지연될 수 있습니다.

    다음 예는 LSI MegaRaid 디스크의 전원 절약 모드를 수정할 때 PowerState의 값이 변경되지 않거나 지연 후 변경됨을 나타냅니다.

    LSILSIESG_PhysicalDrive.Tag="500605B004F93CF0_252_36",CreationClassName="LSIESG_PhysicalDrive"
    CreationClassName = LSIESG_PhysicalDrive
    Tag = 500605B004F93CF0_252_36
    UserDataBlockSize = 512
    PiType = 0
    PiEligible = 0
    PiFomatted = 0
    PowerState = 0 ---> No change in status
    Vendor = (NULL)
    FRUNumber = (NULL)
    DiskDrive_DeviceID = 252_36


    이 문제는 이 릴리스에서 해결되었습니다.
  • 시스템에 올바른 스크래치 파티션이 구성되었을 때도 주의 메시지가 보고될 수 있음
    구성된 스크래치 위치가 데이터스토어의 루트(/vmfs/volumes/ / )에 있지 않은 경우 스크래치 구성을 잘못 식별하여 다음과 같은 잘못된 주의 메시지가 표시될 수 있습니다.

    스크래치 파티션이 구성되지 않았습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 스토리지 추가 마법사에서 LUN(Logical Unit Number) 스토리지의 목록 로드가 지연됨
    읽기 전용 LUN을 새 데이터스토어에 추가하여 200개의 VMFS 복제본을 생성할 때 스토리지 추가 마법사에서 볼륨 목록이 30분 후에 표시될 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 규정 준수 실패로 인해 호스트 프로파일 적용이 실패함
    호스트 프로파일 적용을 완료하려 할 때 또는 프로파일을 적용한 후에 다음과 같은 규정 준수 실패가 나타날 수 있습니다.
     
    호스트에 규격 상태가 없음: 디바이스 'datastore' 상태를 'on'(으)로 설정해야 함
    호스트 상태가 규격과 일치하지 않음: 디바이스 'datastore'을(를) 재설정해야 함
    호스트에 규격 상태가 없음: 디바이스 'datastore' 경로 선택 정책을 'VMW_PSP_FIXED'로 설정해야 함
    호스트 상태가 규격과 일치하지 않음: 디바이스 'datastore' 경로 선택 정책을 SATP 할당에 대한 기본값으로 설정해야 함


    참조 호스트에서 저장된 호스트 프로파일이 SCSI 디바이스를 잠재적으로 공유 디바이스로 기록할 때 이 문제가 발생합니다. 그러나, SCSI가 로컬 디바이스이면 호스트 프로파일을 호스트에 적용한 후 규정 준수 검사가 실패할 수 있습니다. 예를 들어, Host1에 GUID1의 SAS 디바이스가 있고 Host2에 GUID2의 다른 SAS 디바이스가 있을 경우 이 문제가 발생할 수 있습니다. 로컬 전용 SCSI 디바이스의 예로 특정 로컬 RAID 컨트롤러 및 SAS 디스크가 있습니다.

    시스템 하드웨어가 유사하더라도 서로 다른 디바이스 ID를 가진 유사한 디바이스가 일반 형식인 mpx.pathname이 아닌 naa.UID 형식으로 고유한 이름이 명명되었기 때문에 규정 준수 오류가 발생합니다. 이로 인한 프로파일 규정 준수 검사는 일부 디바이스가 제거된 반면 다른 디바이스가 저장된 프로파일에 나타나지 않고 추가되었음을 감지합니다.

    SAS 컨트롤러 뒤의 모든 SATA 기반 SSD 디바이스에 대해 ESXi 5.5 업데이트 2에서 이 문제가 해결되었습니다. 이와 같은 디바이스는 ESXi에 의해 로컬 디바이스로 표시됩니다. 또한 스토리지 호스트 프로파일은 로컬 SAS와 USB 디바이스(USB CD-ROM 제외)를 무시하기 때문에 로컬 SAS 및 USB 디바이스로 인한 규정 준수 검사 오류가 나타나지 않습니다.
  • USB로 상태 비저장 캐시 또는 상태 저장 설치에 Auto Deploy를 사용한 후 비준수 메시지가 나타남
    호스트 프로파일을 편집하여 호스트의 USB 디스크에 상태 비저장 캐시를 사용하도록 설정한 후 업데이트를 적용하려고 할 때 호스트 프로파일에 규정 준수 오류가 발생합니다. 호스트가 재부팅되고 캐시가 완료됩니다. 규정 준수 여부를 검사한 후 다음과 같은 규정 준수 오류 메시지가 나타날 수 있습니다.

    호스트 상태가 specification:device.mpx.vmhbaXX:C0:T0:L0과 일치하지 않습니다. 매개 변수를 재설정해야 합니다.
    호스트 상태가 specification:device.mpx.vmhbaXX:C0:T0:L0과 일치하지 않습니다. 경로 선택 정책을 SATP 할당에 대한 기본값으로 설정해야 합니다.


    위의 메시지에서 XX는 32보다 크거나 같은 정수(예: 34)일 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • LWD 전송 프로세스 중에 중지 상태 스냅샷 작업이 실패할 경우 Hostd 서비스가 실패할 수 있음
    LWD 전송 프로세스 중에 중지 스냅샷이 실패할 경우 hostd 서비스가 실패하고 다음과 같은 오류 메시지가 hostd.log 파일에 기록될 수 있습니다.

    Panic: Assert Failed: "false" @ bora/vim/hostd/hbrsvc/ReplicationGroup.cpp:5123

    이 문제는 이 릴리스에서 해결되었습니다.

스토리지 문제

  • 다중 가상 시스템이 동일한 ESXi 호스트에서 실행되고 동일한 NFS 데이터스토어를 사용할 때 높은 가상 디스크 지연 시간 및 낮은 가상 디스크 성능이 관찰될 수 있음
    다중 가상 시스템이 동일한 ESXi 호스트에서 실행 중이고 동일한 NFS 데이터스토어를 사용 중인 환경에서 가상 시스템 하나에 IOPS 제한을 설정한 경우 높은 가상 디스크 지연 시간 및 낮은 가상 디스크 성능 현상을 경험할 수 있습니다. 여러 가상 시스템에 서로 다른 IOPS 제한을 할당하더라도, 모든 가상 시스템의 IOPS 제한이 NFS 데이터스토어의 가상 시스템에 할당된 가장 낮은 값으로 설정됩니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 디스크 식별자 이름이 잘릴 수 있음
    호스트 리소스 MIB(RFC 2790)는 형식 지정된 문자열의 크기를 64로 제한합니다. 디스크 식별자 이름 또는 형식 지정된 문자열이 이 크기 제한을 초과할 경우 잘릴 수 있습니다.

    이 릴리스에서는 올바른 정보를 포함하도록 이중 공백을 제거하여 이 문제를 해결했습니다.
  • ESXi 호스트에서 Intel 40G CNA가 링크 상태를 중단으로 표시할 수 있음
    ESXi 호스트에서 Intel 40G CNA(Converged Network Adapter)가 네트워크 링크 상태를 중단으로 표시할 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • vCenter Server 또는 ESXCLI에서 실행 중인 모든 스토리지 어댑터를 다시 검색하는 작업에 시간이 오래 걸릴 수 있음
    ESXi 호스트에 많은 VMFS 데이터스토어가 있을 경우 vCenter Server 또는 ESXCLI에서 실행하는 모든 스토리지 어댑터 다시 검색 작업을 완료하는 데 시간이 오래 걸릴 수 있습니다.

    이 릴리스는 모든 스토리지 어댑터 및 VMFS 데이터스토어 다시 검색과 같은 다양한 스토리지 작업 및 데이터스토어 생성 마법사에서 VMFS 스냅샷 및 디바이스 나열과 같은 작업에 대한 성능을 향상시킵니다.
  • 변경된 블록 추적이 Storage vMotion에 의해 재설정됨
    vSphere 5.x에서 Storage vMotion 작업을 수행하면 변경된 블록 추적(CBT)이 재설정됩니다.
    자세한 내용은 KB 2048201을 참조하십시오.

    이 문제는 이 릴리스에서 해결되었습니다.
  • NFS 잠금 경합으로 인해 대량 vApp 배포가 간헐적으로 실패할 수 있음
    VCD에서 빠른 프로비저닝을 위해 VAAI 사용 옵션이 설정된 경우 연결된 복제 작업 중에 NFS에서 vApp 배포가 실패할 수 있습니다. 다음과 같은 오류 메시지가 hostd.log 파일에 기록됩니다.

    Create child failed to mark parent read-only (25): The system cannot find the file specified

    이 문제는 이 릴리스에서 해결되었습니다.
  • 클러스터 전체 스토리지 재검색으로 인해 ESXi 호스트 및 가상 시스템이 응답하지 않음
    VMFS 새로 고침을 수행하는 동안 가상 시스템이 ping 요청에 오랫동안 응답하지 않을 수 있습니다. 자세한 내용은 KB 1039088을 참조하십시오.

    이 문제는 이 릴리스에서 해결되었습니다.
  • IBM에 대해 새 클레임 규칙 옵션이 추가됨
    IBM 스토리지 어레이 모델 2145에 대해 새 클레임 규칙 옵션 reset_on_attempted_reserve가 ESXi 5.5에 추가되었습니다.
  • CBT를 Virtual SAN과 함께 사용하는 경우 VM 작업이 실패할 수 있음
    CBT를 Virtual SAN과 함께 사용하면 경우에 따라 vmdk의 일부 구성 요소가 손실되어 가상 시스템 작업이 실패할 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.

업그레이드 및 설치 문제

  • ESXi 5.5를 설치할 때 오류 메시지가 syslog.log 파일에 기록될 수 있음
    ESXi 호스트를 설치하고 SNMP 모니터링 서버가 해당 호스트를 모니터링한 후, 다음과 유사한 오류 메시지가 syslog.log 파일에 기록될 수 있습니다.

    snmpd: fetch_fixed_disk_status: fetch VSI_NODE_storage_scsifw_devices_smart_healthStatus(naa.6090a048e059642f5ac6d489e7faed03) failed Not supported, reporting unknown status

    이 문제는 SMART(Self Monitoring Analysis and Reporting Technology)를 지원하지 않는 디스크를 포함한 호스트에서만 발생합니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • kickstart 파일을 사용하여 RHEL 가상 시스템을 설치할 때 OSP가 오류 메시지를 표시할 수 있음
    kickstart 파일을 사용하여 RHEL 가상 시스템을 설치할 때 운영 체제 특정 패키지(OSP)가 다음과 유사한 오류 메시지를 표시할 수 있습니다.

    modules.dep을 로드할 수 없습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • ESX 4.1에서 ESXi 5.5로 업그레이드한 후 ESXi 호스트가 vCenter Server에 추가되지 않을 수 있음
    ESX 4.1에서 ESXi 5.5로 업그레이드한 후 호스트의 nsswitch.conf 파일이 적절하게 마이그레이션되지 않을 수 있습니다. 그로 인해 호스트가 vCenter Server에 추가되지 않을 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • ESX 4.1에서 ESXi 5.5 OEM으로의 업그레이드가 실패할 수 있음
    ESX 4.1 호스트에서 지원되지 않는 vsish 명령으로 인해 ESX 4.1.x에서 ESXi 5.5.x OEM으로 업그레이드하려는 시도가 실패할 수 있습니다. 다음과 유사한 오류 메시지가 표시될 수 있습니다.

    업그레이드가 호스트 하드웨어에 대해 지원되지 않습니다. 업그레이드 ISO 이미지에 호스트 하드웨어 벤더 호환성 검사를 통과하지 못한 HP 또는 다른 벤더 VIB가 포함되어 있습니다. 벤더가 작성한 호스트 하드웨어 모델 Hewlett-Packard Company에 대해서는 HP에 의한 VIB가 지원되지 않습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • ESXi 5.1에서 ESXi 5.5로 업그레이드하면 hostd 서비스가 실패하고 vCenter Server에서 ESXi 호스트의 연결이 끊어질 수 있음
    ESXi 5.1에서 ESXi 5.5로 업그레이드하는 경우 hostd 서비스가 실패할 수 있습니다. 그 결과 vCenter Server에서 ESXi 호스트의 연결이 끊어질 수 있습니다. 또한 이 문제는 Veaam 백업 작업의 실패 원인이 되기도 합니다. 다음과 유사한 오류 메시지가 hostd.log 파일에 기록될 수 있습니다.

    2014-01-17T11:15:29.069Z [704ADB90 error 'UW Memory checker'] Current value 644848 exceeds hard limit 643993. Shutting down process.2014-01-17T11:15:29.069Z [704ADB90 panic 'Default']
    -->
    --> Panic: Memory exceeds hard limit. Panic
    --> Backtrace:
    --> backtrace[00] rip 142c26a3 Vmacore::System::Stacktrace::CaptureFullWork(unsigned int)
    --> backtrace[01] rip 140e6a48 Vmacore::System::SystemFactoryImpl::CreateBacktrace(Vmacore::Ref <:system::backtrace> &)
    --> backtrace[02] rip 142b9803 /lib/libvmacore.so [0x142b9803]
    --> backtrace[03] rip 142b9bd1 Vmacore::PanicExit(char const*)
    --> backtrace[04] rip 140f3b6c Vmacore::System::ResourceChecker::DoCheck()
    --> backtrace[05] rip 140f423d boost::detail::function::void_function_obj_invoker <void,0
    </:system::backtrace>
    이 문제는 hostd 메모리 팽창으로 인해 발생합니다.

    이 문제는 이 릴리스에서 해결되었습니다.

vCenter Server 및 vSphere Web Client 문제

  • hostd 서비스가 실패한 후 ESXi 호스트가 vCenter Server에서 연결이 끊길 수 있음
    hostd 서비스가 실패한 후 vCenter Server에서 ESXi 호스트의 연결이 끊길 수 있습니다. 이 문제는 가상 시스템이 등록 취소되었을 때 발생합니다. vpxa 서비스를 다시 시작한 후에만 ESXi 호스트를 vCenter에 연결할 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • vCenter Server 인벤토리 개체에 대한 잘못된 처리량 사용 값이 성능 차트에 표시될 수 있음
    성능 차트에서 다음 vCenter Server 인벤토리 개체에 대한 잘못된 처리량 사용 값이 표시됩니다.
    • 가상 시스템 > 가상 디스크
    • 가상 시스템 > 디스크
    • 호스트 > 디스크
    • 호스트 > 스토리지 경로
    • 호스트 > 스토리지 어댑터
    자세한 내용은 KB 2064464를 참조하십시오.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 평균 CPU 사용량 값이 프로세서 수에 프로세서 주파수를 곱한 값보다 클 수 있음
    Power CLI가 표시한 평균 CPU 사용량 값이 프로세서 수에 프로세서 주파수를 곱한 값보다 클 수 있습니다.

    이 릴리스에서는 평균 CPU 사용량 값의 최대 제한을 올바르게 설정하여 이 문제를 해결했습니다.
  • Linux 가상 시스템의 스냅샷 중지 및 핫 복제가 실패할 수 있음
    Linux 가상 시스템의 스냅샷 중지 및 핫 복제가 실패할 수 있고 다음과 유사한 오류 메시지가 vmware.log 파일에 기록될 수 있습니다.

     2013-12-12T00:09:59.446Z| vcpu-1| I120: [msg.snapshot.quiesce.vmerr] The guest OS has reported an error during quiescing.
     2013-12-12T00:09:59.446Z| vcpu-1| I120+ The error code was: 3
     2013-12-12T00:09:59.446Z| vcpu-1| I120+ The error message was: Error when enabling the sync provider.
     2013-12-12T00:09:59.446Z| vcpu-1| I120: ----------------------------------------
     2013-12-12T00:09:59.449Z| vcpu-1| I120: ToolsBackup: changing quiesce state: STARTED -> ERROR_WAIT
     2013-12-12T00:10:00.450Z| vcpu-1| I120: ToolsBackup: changing quiesce state: ERROR_WAIT -> IDLE
     2013-12-12T00:10:00.450Z| vcpu-1| I120: ToolsBackup: changing quiesce state: IDLE -> DONE
     2013-12-12T00:10:00.450Z| vcpu-1| I120: SnapshotVMXTakeSnapshotComplete: Done with snapshot 'clone-temp-1386910714682919': 0
     2013-12-12T00:10:00.450Z| vcpu-1| I120: SnapshotVMXTakeSnapshotComplete: Snapshot 0 failed: Failed to quiesce the virtual machine (40).


    이 문제는 이 릴리스에서 해결되었습니다.

가상 시스템 관리 문제

  • 중지된 스냅샷을 생성할 때 가상 시스템이 실패할 수 있음
    vSphere Replication 또는 기타 서비스가 중지된 스냅샷을 시작할 때 가상 시스템이 실패할 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • AdvStats 매개 변수를 사용하는 사용자 지정 스크립트를 실행할 때 ESXi 호스트가 실패하고 보라색 화면이 표시될 수 있음
    AdvStats 매개 변수를 사용하는 사용자 지정 스크립트를 실행하여 디스크 사용량을 확인할 때 ESXi 호스트가 실패하고 보라색 화면이 표시될 수 있습니다.
    다음과 유사한 오류 메시지가 vmkernel.log 파일에 기록될 수 있습니다.

    VSCSI: 231: Creating advStats for handle 8192, vscsi0:0
    호스트가 다음과 유사한 역추적을 보고합니다.
    Histogram_XXX
    VSCSIPostIOCompletion
    AsyncPopCallbackFrameInt

    이 문제는 이 릴리스에서 해결되었습니다.
  • DRS 때문에 가상 시스템을 마이그레이션할 경우 게스트 운영 체제 사용자 지정이 실패할 수 있음
    게스트 운영 체제 사용자 지정 도중, DRS 때문에 가상 시스템을 마이그레이션하면 사용자 지정 프로세스가 실패하고 다음과 유사한 오류 메시지가 Guestcust.log 파일에 나타날 수 있습니다.

    Unable to set customization status in vmx.

    이 문제는 이 릴리스에서 해결되었습니다.
  • 자동화 코드를 실행하여 가상 시스템을 복사하면 vCenter Server에서 ESXi 호스트의 연결이 끊어질 수 있음
    자동화 코드를 실행하여 가상 시스템을 복사하는 경우 vCenter Server에서 ESXi 호스트의 연결이 끊어질 수 있습니다. 이 문제는 hostd 서비스가 실패할 때 발생합니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • HA 클러스터가 가상 시스템 전원이 꺼져 있다고 잘못 가정하는 경우 vSphere HA 보호 상태가 보호되지 않음으로 유지될 수 있음
    HA 클러스터가 가상 시스템 전원이 꺼져 있다고 잘못 가정하는 경우 vSphere HA 보호 상태가 보호되지 않음으로 유지될 수 있습니다.
    이 문제는 vm.runtime.cleanPowerOff 속성이 true로 잘못 설정되고 그 결과 HA 클러스터가 가상 시스템의 전원이 꺼져 있다고 가정할 때 발생합니다.
    다음과 같은 오류 메시지가 로그 파일에 기록됩니다.

    vpxd-8.log:2013-11-21T20:44:49.902Z [7F69C7CF9700 info 'vmdasVm' opID=FdmWaitForUpdates-domain-c26-45712e7f] [VmMo::UpdateActualDasProtectStateLocked] actual protection state for VM vm-93 'unprotected' -> 'protected'
    vpxd-10.log:2013-11-22T00:03:01.731Z [7F69D4832700 info 'vmdasVm' opID=FdmWaitForUpdates-domain-c26-6b160bef] [VmMo::UpdateActualDasProtectStateLocked] actual protection state for VM vm-93 'protected' -> 'unprotected'


    이 문제는 이 릴리스에서 해결되었습니다.

vMotion 및 Storage vMotion 문제

  • ESXi 5.1에서 ESXi 5.5로 vMotion을 수행할 때 ESXi 호스트가 응답하지 않을 수 있음
    ESXi 5.1에서 ESXi 5.5로 vMotion을 수행할 때 ESXi 호스트가 응답하지 않을 수 있습니다.
    또한 다음 작업 중 하나를 수행할 때 가상 시스템의 상태가 잘못됨으로 표시될 수 있습니다.
    • 가상 시스템의 등록 취소 또는 등록
    • 가상 시스템을 ESXi 5.1에서 ESXi 5.5로 콜드 마이그레이션

    ESXi 5.1에서 ESXi 5.5로 vMotion을 수행할 때 ESXi 호스트가 응답하지 않을 수 있습니다.
    다음과 유사한 오류 메시지가 대상 ESXi 호스트의 hostd.log 파일에 기록될 수 있습니다.

    2013-12-18T15:21:52.455Z [FFBEFB70 verbose 'Vmsvc.vm:/vmfs/volumes/50d2f92b-bc57ec6f-f5c0-001c23d7ba27/migtest3/migtest3.vmx'] Get shared vigor fields message: CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    --> CPUID register value () is invalid.
    -->
    2013-12-18T15:21:52.455Z [FFBEFB70 info 'Vmsvc.vm:/vmfs/volumes/50d2f92b-bc57ec6f-f5c0-001c23d7ba27/migtest3/migtest3.vmx'] Error encountered while retrieving configuration. Marking configuration as invalid: vim.fault.GenericVmConfigFault


    이 문제는 이 릴리스에서 해결되었습니다.
  • vMotion을 수행하면 VMware Tools가 자동 업그레이드되고 가상 시스템이 재부팅될 수 있음
    전원 주기마다 VMware Tools 업그레이드를 실행하도록 설정하고 no-tools 이미지 프로파일을 포함한 ESXi 호스트에서 VMware Tools ISO 이미지를 포함한 다른 ESXi 호스트로 vMotion을 수행할 때 VMware Tools가 자동으로 업그레이드되고 가상 시스템이 재부팅될 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.

VMware Tools 문제

  • 메모리 벌룬 드라이버(VMMEMCTL) 컴파일이 FreeBSD 버전 10 이상에서 실패함
    메모리 벌룬 드라이버(vmmemctl)가 FreeBSD 버전 10.0 이상에서 컴파일에 실패할 수 있습니다. 다음과 유사한 오류 메시지가 로그 파일에 기록됩니다.

    os.c:300:22: error: implicit declaration of function 'kmem_alloc_nofault' is
    invalid in C99[-Werror,-Wimplicit-function-declaration]
    vm_offset_t res = kmem_alloc_nofault(kernel_map, PAGE_SIZE);
    ^
    os.c:357:14: error: incompatible pointer types passing 'vm_map_t' (aka
    'struct vm_map ') to parameter of type 'struct vmem ' [-Werror,-Wincompatible-pointer-types]
    kmem_free(kernel_map, (vm_offset_t)mapping, PAGE_SIZE);
    ^~~~~~~~~~
    @/vm/vm_extern.h:59:29: note: passing argument to parameter here
    void kmem_free(struct vmem *, vm_offset_t, vm_size_t);

    이 문제는 이 릴리스에서 해결되었습니다.
  • MOVE Agentless 3.0이 가상 시스템에서 실행 중일 때 로그인 중에 ESXi 호스트의 응답이 지연될 수 있음
    ESXi 호스트에서 MOVE Agentless 3.0을 실행할 때 로그인 중 응답이 40초 이상 지연될 수 있습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • Windows 가상 시스템에 VMware Tools 5.1을 설치할 때 Windows 이벤트 로그에 Unity 주의가 보고됨
    Windows 가상 시스템에 VMware Tools 5.1을 설치한 후, 게스트 운영 체제의 Windows 애플리케이션 이벤트 로그에 다음과 유사한 주의가 보고됩니다.

    [ warning] [vmusr:vmusr] vmware::tools::UnityPBRPCServer::Start: Failed to register with the host!
    [ warning] [vmusr:vmtoolsd] Failed registration of app type 2 (Signals) from plugin unity.
    [ warning] [vmusr:vmusr] Error in the RPC receive loop: RpcIn: Unable to send.
    [ warning] [vmusr:vmusr] socket count not create new socket, error 10047: An address incompatible with the requested protocol was used
    [ warning] [vmusr:vmusr] Channel restart failed [1]


    이 문제는 이 릴리스에서 해결되었습니다.
  • 5개 이상의 NIC가 연결되었을 때 GuestInfo.ipAddress 데이터 개체에 대한 MOB가 올바르게 채워지지 않을 수 있음
    5개 이상의 NIC가 연결되었을 때 GuestInfo.ipAddress 데이터 개체에 대한 MOB(Managed Object Browser)가 올바르게 채워지지 않고 GuestInfo.ipAddress 데이터 개체의 값이 unset으로 표시될 수 있습니다.
    VMware Tools가 올바른 게스트 운영 체제 IP 주소를 판별하지 못할 때 이 문제가 발생합니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • VMware Tools를 업그레이드할 때 Windows 가상 시스템이 블루 스크린과 함께 실패할 수 있음
    VMware Tools를 업그레이드하고 나서 가상 시스템이 블루 스크린과 함께 실패하거나 응답을 중단할 수 있습니다. vShield Endpoint TDI Manager 드라이버 vnetflt.sys에서 TCP 연결을 올바르게 처리하지 못할 때 메모리 손상으로 인해 이 문제가 발생합니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • VMware Tools 업그레이드 후 파일이 사라짐
    VMware Tools를 5.5 업데이트 1 버전으로 업그레이드한 후 C:\Program Files\Vmware\Vmware Tools\ 위치에 있었던 deployPkg.dll 파일을 찾을 수 없습니다.

    이 문제는 이 릴리스에서 해결되었습니다.
  • VMware Tools를 설치하면 Windows 이벤트 뷰어에서 주의 메시지가 표시될 수 있음
    VMware Tools를 설치한 후 Windows 이벤트 뷰어에서 다음과 같은 주의 메시지가 표시됩니다.

    'C:\Program Files\VMware\VMware Tools\messages\es\hgfsUsability.vmsg'에서 줄을 읽을 수 없습니다. 변환 입력의 바이트 순서가 잘못되었습니다.

    이 문제는 특히 스페인어 로케일 운영 체제에서 VMware Tools를 설치할 때 발생합니다.

    이 문제는 이 릴리스에서 해결되었습니다.

알려진 문제

이전에 문서화되지 않은 알려진 문제는 * 기호로 표시되어 있습니다. 알려진 문제는 다음과 같이 그룹화되어 있습니다.

설치 및 업그레이드 문제

  • vSphere PowerCLI에서 Get-EsxImageProfile 명령을 실행하는 동안 모든 이미지 프로파일을 가져오려는 시도가 실패할 수 있음*
    모든 이미지 프로파일을 가져오기 위해 vSphere PowerCLI를 사용하여 Get-EsxImageProfile 명령을 실행할 때 다음과 유사한 오류가 표시됩니다.

    PowerCLI C:\Windows\system32> Get-EsxImageProfile
    Get-EsxImageProfile : 매개 변수 'name'은 빈 문자열일 수 없습니다.
    매개 변수 이름: name
    위치:1 char:20
    + Get-EsxImageProfile <<<<
    + CategoryInfo : NotSpecified: (:) [Get-EsxImageProfile], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException,VMware.ImageBuilder.Commands.GetProfiles


    해결 방법: -name 옵션이 포함된 Get-EsxImageProfile -name "ESXi-5.x*" 명령을 실행하여 PowerCLI 세션 중 생성된 모든 이미지 프로파일을 표시합니다.

    예를 들어, Get-EsxImageProfile -name "ESXi-5.5.*" 명령을 실행하면 다음과 유사한 모든 5.5 이미지 프로파일이 표시됩니다.

    PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Get-EsxmageProfile -name "ESXi-5.5.*"

    Name Vendor Last Modified Acceptance Level
    ---- ------ ------------- ----------------
    ESXi-5.5.0-20140701001s-no-... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20140302001-no-t... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20140604001-no-t... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20140401020s-sta... VMware, Inc. 8/23/2014 6:... PartnerSupported
    ESXi-5.5.0-20131201001s-sta... VMware, Inc. 8/23/2014 6:... PartnerSupported
  • Windows Server 2012에서 Simple Install 실패
    운영 체제가 DHCP IP 주소를 사용하도록 구성되어 있으면 Windows Server 2012에서 Simple Install에 실패합니다.

    해결 방법: 정적 IP 주소를 사용하도록 Windows 2012 Server를 구성합니다.

  • Auto Deploy 상태 비저장 캐시 또는 Auto Deploy 상태 저장 설치와 함께 VMFS 유지를 사용하는 경우 코어 덤프 파티션이 생성되지 않음
    빈 디스크에서 상태 비저장 캐시 또는 상태 저장 설치에 Auto Deploy를 사용하면 MSDOS 파티션 테이블이 생성됩니다. 그러나 코어 덤프 파티션은 생성되지 않습니다.

    해결 방법: 상태 비저장 캐시 또는 상태 저장 설치 호스트 프로파일 옵션을 사용하도록 설정한 경우 빈 디스크에 설치하더라도 VMFS 덮어쓰기를 선택합니다. 이렇게 하면 2.5GB 코어 덤프 파티션이 생성됩니다.

  • 스크립트로 작성된 설치 중 installorupgrade 명령에 --ignoressd 옵션을 사용해도 ESXi가 SSD에 설치됨
    ESXi 5.5에서는 installorupgrade 명령에 --ignoressd 옵션을 사용할 수 없습니다. installorupgrade 명령에 --ignoressd 옵션을 사용하면 설치 관리자가 잘못된 조합이라는 경고를 표시합니다. 설치 관리자가 설치를 중지하거나 오류 메시지를 표시하지 않고 SSD에서 ESXi 설치를 계속합니다.

    해결 방법: ESXi의 스크립트로 작성된 설치에서 --ignoressd 옵션을 사용하려면 installorupgrade 명령 대신 install 명령을 사용합니다.

  • Auto Deploy 캐시 제거가 지연되어 삭제된 호스트 프로파일이 적용될 수 있음
    호스트 프로파일을 삭제한 후 Auto Deploy에서 해당 호스트 프로파일이 바로 제거되지는 않습니다. 호스트 프로파일이 캐시에 유지되는 동안에는 Auto Deploy가 계속 해당 호스트 프로파일을 적용합니다. 이 프로파일을 적용하는 모든 규칙은 캐시에서 해당 프로파일이 제거된 후에만 실패합니다.

    해결 방법: Get-DeployRuleSet PowerCLI cmdlet을 사용하여 규칙에서 삭제된 호스트 프로파일을 사용하는지 여부를 확인할 수 있습니다. 이 cmdlet은 규칙의 itemlistdeleted라는 문자열을 표시합니다. 그런 다음 Remove-DeployRule cmdlet을 실행하여 규칙을 제거할 수 있습니다.

  • 선택한 디스크에 ESX를 설치한 경우 상태 비저장 캐시와 함께 Auto Deploy를 사용하도록 설정된 호스트 프로파일 적용이 실패함
    호스트 프로파일을 사용하여 상태 비저장 캐시를 사용하도록 설정되어 있는 Auto Deploy를 설정합니다. 호스트 프로파일에서 ESX(ESXi가 아님) 버전이 설치되어 있는 디스크를 선택합니다. 호스트 프로파일을 적용하면 다음 텍스트가 포함된 오류가 나타납니다.
    부팅 뱅크 2개가 필요함, 0개 발견.

    해결 방법: 상태 비저장 캐시에 사용할 다른 디스크를 선택하거나 디스크에서 ESX 소프트웨어를 제거합니다. 제거한 ESX 소프트웨어는 사용할 수 없게 됩니다.

  • Oracle America(Sun) 공급업체의 서버에서 ESXi 버전 5.5.0 설치 또는 부팅에 실패함
    Oracle America(Sun) 공급업체의 서버에서 ESXi 버전 5.5.0을 새로 설치하거나 기존 ESXi 버전 5.5.0 설치를 부팅하면 설치 프로세스 중이나 기존 ESXi 5.5.0 빌드 부팅 시 서버 콘솔에 빈 화면이 표시됩니다. 이 문제가 발생하는 이유는 Oracle America(Sun) 공급업체의 서버가 헤드리스 플랫폼이 아닌데도 ACPI FADT 테이블에 HEADLESS 플래그가 설정되어 있기 때문입니다.

    해결 방법: ESXi 5.5.0을 설치하거나 부팅할 때 부팅 옵션 ignoreHeadless="TRUE"를 전달합니다.

  • ESXCLI 명령을 사용하여 물리적 RAM이 4GB 미만인 ESXi 호스트를 업그레이드하면 업그레이드에 성공하지만 재부팅 시 일부 ESXi 작업에 실패함
    ESXi 5.5에는 물리적 RAM이 4GB 이상 필요합니다. ESXCLI 명령줄 인터페이스는 필요한 4GB 메모리가 있는지 업그레이드 전에 확인하지 않습니다. ESXCLI를 사용하여 메모리가 부족한 호스트를 성공적으로 업그레이드할 수는 있지만 RAM이 4GB 미만인 업그레이드된 ESXi 5.5 호스트를 부팅하면 일부 작업에 실패할 수 있습니다.

    해결 방법: 없음. 버전 5.5로 업그레이드하기 전에 ESXi 호스트에 물리적 RAM이 4GB 이상 있는지 확인합니다.

  • vCenter Server Appliance 5.0.x에서 5.5로 업그레이드한 후 외부 vCenter Single Sign-On을 사용하면 vCenter Server가 시작되지 않음
    vCenter Server Appliance를 5.0.x에서 5.5로 업그레이드할 때 사용자가 외부 vCenter Single Sign-On 인스턴스를 사용하면 업그레이드 후 vCenter Server가 시작되지 않습니다. 장치 관리 인터페이스에서 vCenter Single Sign-On은 구성되지 않음으로 표시됩니다.

    해결 방법: 다음 단계를 수행합니다.

    1. 웹 브라우저에서 vCenter Server Appliance 관리 인터페이스(https://appliance-address:5480)를 엽니다.
    2. vCenter Server/요약 페이지에서 서버 중지 버튼을 클릭합니다.
    3. vCenter Server/SSO 페이지에서 양식에 적절한 설정을 입력하고 설정 저장을 클릭합니다.
    4. 요약 페이지로 돌아가서 서버 시작을 클릭합니다.
  • ESXCLI를 사용하여 ESXi 4.x 또는 5.0.x 호스트를 버전 5.1 또는 5.5로 업그레이드하면 업그레이드 후 VMkernel 포트 그룹의 vMotion 및 FT 로깅(Fault Tolerance 로깅) 설정이 손실됨
    esxcli software profile update <options> 명령을 사용하여 ESXi 4.x 또는 5.0.x 호스트를 버전 5.1 또는 5.5로 업그레이드하면 업그레이드에 성공하지만 VMkernel 포트 그룹의 vMotion 및 FT 로깅 설정이 손실됩니다. 따라서 vMotion 및 FT 로깅이 기본 설정(사용 안 함)으로 복원됩니다.

    해결 방법: 스크립트로 작성된 업그레이드 또는 대화형 업그레이드를 수행하거나 vSphere Update Manager를 사용하여 호스트를 업그레이드합니다. esxcli 명령을 사용하는 경우에는 업그레이드 후 영향을 받는 VMkernel 포트 그룹에 vMotion 및 FT 로깅 설정을 수동으로 적용합니다.

  • vSphere 5.0.x 이전 버전에서 버전 5.5로 업그레이드할 때 수동으로 설정한 시스템 리소스 할당 값이 기본값으로 재설정됨
    vSphere 5.0.x 이전 버전에서는 임시 해결 방법으로 시스템 리소스 할당 사용자 인터페이스에서 설정을 수정합니다. ESXi를 완전히 재설치하지 않고는 이러한 설정의 값을 기본값으로 재설정할 수 없습니다. vSphere 5.1 이상에서는 시스템 동작이 변경되어, 사용자 지정 시스템 리소스 할당 설정을 유지하는 경우 안전하지 않은 값을 사용하게 될 수 있습니다. 업그레이드 시 이러한 값을 재설정합니다.

    해결 방법: 없음.

  • ESX 4.x에서 ESXi 5.5로 업그레이드한 후 가상 NIC vmk0의 IPv6 설정이 유지되지 않음
    IPv6을 사용하도록 설정된 ESX 4.x 호스트를 --forcemigrate 옵션을 사용하여 ESXi 5.5로 업그레이드하면 업그레이드 후 가상 NIC vmk0의 IPv6 주소가 유지되지 않습니다.

    해결 방법: 없음.

vCenter Single Sign-On 문제
  • vSphere Web Client를 5.1 업데이트 1a에서 5.5로 업그레이드할 때 오류 29107이 나타남
    vSphere Web Client를 버전 5.1 업데이트 U1a에서 버전 5.5로 업그레이드할 때 업그레이드 전에 사용 중이던 vCenter Single Sign-On 서비스가 고가용성 Single Sign-On으로 구성되어 있으면 오류 29107이 나타납니다.

    해결 방법: 업그레이드를 다시 수행합니다. 설치 관리자를 실행하고 사용자 지정 설치를 선택하여 vSphere Web Client만 업그레이드할 수 있습니다.

  • vSphere Web Client 풀다운 메뉴에서 administrator@vsphere.local의 암호를 변경할 수 없음
    vSphere Web Client에서 vCenter Single Sign-On 서버에 로그인할 때 풀다운 메뉴에서 암호를 변경할 수 있습니다. administrator@vsphere.local로 로그인하면 암호 변경 옵션이 회색으로 비활성화됩니다.

    해결 방법:

    1. 관리 탭을 선택하고 vCenter Single Sign-On > 사용자 및 그룹을 선택합니다.
    2. 관리자를 마우스 오른쪽 버튼으로 클릭하고 사용자 편집을 클릭합니다.
    3. 암호를 변경합니다.

네트워킹 문제

  • NSX 불투명 네트워크로 PCNet32 네트워크 어댑터를 사용할 수 없음*
    PCNet32 Flexible 네트워크 어댑터가 NSX 불투명 네트워크 백업으로 구성되어 있으면 VM 전원을 켤 때 어댑터의 연결이 끊어집니다.
  • 해결 방법: 없음

  • ESXi 5.5로 업그레이드하면 멀티캐스트 그룹 관리에 대한 TCP/IP 스택의 IGMP 구성이 변경될 수 있음*
    멀티캐스트 그룹 관리를 위해 ESXi 5.5 호스트에 대한 관리 인터페이스의 기본 IGMP 버전이 IGMP V2에서 IGMP V3으로 변경되었습니다. 그 결과 ESXi 5.5로 업그레이드할 때, 관리 인터페이스가 이전 버전의 IGMP 쿼리를 수신할 경우 IGMP V3에서 IGMP V2로 되돌아갈 수 있으며 IGMP 버전 불일치 오류 메시지가 나타날 수 있습니다.

    해결 방법: 고급 구성 옵션에서 TCP/IP IGMP 다시 가입 간격을 수정하여 기본 IGMP 버전을 편집합니다.
  • vmknic 인터페이스 및 동적 IP 주소와 연결된 정적 경로가 재부팅 후 표시되지 않을 수 있음
    호스트를 재부팅한 후 VMkernel 네트워크 인터페이스(vmknic) 및 동적 IP 주소와 연결된 정적 경로가 표시되지 않을 수 있습니다.
    이 문제는 DHCP 클라이언트와 경로 복원 명령 사이의 경합 조건으로 인해 발생합니다. 호스트가 재부팅 과정 중 사용자 지정 경로를 복원하려고 하는 경우 DHCP 클라이언트가 vmknic의 IP 주소 가져오기를 완료하지 못할 수 있습니다. 결과적으로 게이트웨이가 설정되지 않고 경로가 복원되지 않습니다.

    해결 방법: esxcfg-route –r 명령을 실행하여 경로를 수동으로 복원합니다.
  • ESXi 호스트가 해당 IPv6 주소로 vCenter Server에 추가된 후 응답을 중지함
    ESXi 호스트를 fe80::/64 형식의 IPv6 링크 로컬 주소를 사용하여 vCenter Server에 추가하면 짧은 시간 내에 호스트 이름이 흐리게 표시되고 호스트가 vCenter Server에 대한 응답을 중지합니다.

    해결 방법: 링크 로컬 주소가 아닌 올바른 IPv6 주소를 사용합니다.

  • vSphere Web Client에서 물리적 NIC가 지원하는 것보다 많은 가상 기능을 구성해도 오류 메시지를 표시하지 않음
    물리적 어댑터의 SR-IOV 설정에서 어댑터가 지원하는 것보다 많은 가상 기능을 구성할 수 있습니다. 예를 들어 가상 기능을 23개만 지원하는 NIC에서 가상 기능을 100개 구성할 수 있으며, 이때 오류 메시지가 표시되지 않습니다. SR-IOV 설정을 적용하려면 호스트를 재부팅해야 한다는 메시지가 표시됩니다. 호스트를 재부팅하면 NIC에 해당 어댑터가 지원하는 만큼의 가상 기능(이 예에서는 23개)이 구성됩니다. 호스트를 재부팅하라는 메시지가 표시되지 않아야 하는데도 계속 표시됩니다.

    해결 방법: 없음

  • SR-IOV를 사용하도록 설정된 ESXi 호스트에서 가상 기능과 연결된 가상 시스템이 시작되지 않을 수 있음
    Intel ixgbe NIC를 포함하는 ESXi 호스트 5.1 이상에서 SR-IOV를 사용하도록 설정하고 이 환경에서 몇 가지 가상 기능을 사용하도록 설정하면 일부 가상 시스템이 시작되지 않을 수 있습니다.
    vmware.log 파일에는 다음과 유사한 메시지가 포함됩니다.
    2013-02-28T07:06:31.863Z| vcpu-1| I120: Msg_Post: Error
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-1)
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ PCIPassthruChangeIntrSettings: 0a:17.3 failed to register interrupt (error code 195887110)
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.haveLog] A log file is available in "/vmfs/volumes/5122262e-ab950f8e-cd4f-b8ac6f917d68/VMLibRoot/VMLib-RHEL6.2-64-HW7-default-3-2-1361954882/vmwar
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.withoutLog] You can request support.
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.requestSupport.vmSupport.vmx86]
    2013-02-28T07:06:31.863Z| vcpu-1| I120+ To collect data to submit to VMware technical support, run "vm-support".
    2013-02-28T07:06:31.863Z| vcpu-1| I120: [msg.panic.response] 고객은 지원 사용 권한에 따라 응답을 받게 됩니다.

    해결 방법: 영향을 받는 가상 시스템과 연결된 가상 기능의 수를 줄인 후 가상 시스템을 시작합니다.

  • Emulex BladeEngine 3 물리적 네트워크 어댑터에서 가상 기능으로 지원되는 가상 시스템 네트워크 어댑터가 물리적 기능을 업링크로 사용하는 VMkernel 어댑터에 연결할 수 없음
    가상 기능과 물리적 기능 사이에는 트래픽이 흐르지 않습니다. 예를 들어 물리적 기능으로 지원되는 스위치에서 동일한 포트를 통해 가상 기능을 사용하는 가상 시스템은 동일한 스위치의 VMkernel 어댑터에 연결할 수 없습니다. 이는 Emulex BladeEngine 3 물리적 어댑터의 알려진 문제입니다. 자세한 내용은 Emulex에 문의하십시오.

    해결 방법: 호스트에서 Emulex BladeEngine 3 디바이스의 네이티브 드라이버를 사용하지 않도록 설정합니다. 자세한 내용은 VMware 기술 자료 문서 2044993을 참조하십시오.

  • ESXi Dump Collector가 ESXi 코어 파일을 원격 서버로 보내지 못함
    덤프 수집기의 트래픽을 처리하는 VMkernel 어댑터가 LAG(링크 집계 그룹)가 활성 업링크로 설정된 분산 포트 그룹으로 구성되어 있으면 ESXi Dump Collector가 ESXi 코어 파일을 보내지 못합니다. LACP 포트 채널이 물리적 스위치에 구성되어 있습니다.

    해결 방법: 다음 해결 방법 중 하나를 수행합니다.

    • vSphere 표준 스위치를 사용하여 원격 서버에서 ESXi Dump Collector의 트래픽을 처리하는 VMkernel 어댑터를 구성합니다.
    • 독립 실행형 업링크를 사용하여 VMkernel 어댑터가 구성된 분산 포트 그룹의 트래픽을 처리합니다.
  • 호스트에서 vSphere Standard Switch 또는 vSphere Distributed Switch가 사용하는 포트 수를 vSphere Client를 사용하여 변경하면 재부팅 후에도 변경 내용이 저장되지 않음
    ESXi 5.5 호스트에서 vSphere Standard Switch 또는 vSphere Distributed Switch가 사용하는 포트 수를 vSphere Client를 사용하여 변경하면 호스트를 재부팅한 후에도 포트 수가 변경되지 않습니다.

    ESXi 5.5를 실행하는 호스트는 재부팅될 때 가상 스위치의 포트를 동적으로 늘리거나 줄입니다. 포트 수는 호스트가 실행할 수 있는 가상 시스템 수에 따라 다릅니다. 이러한 호스트에서는 스위치 포트 수를 구성할 필요가 없습니다.

    해결 방법: vSphere Client에서는 해결 방법이 없습니다.

서버 구성 문제

  • 직렬 콘솔에서 Direct Control User Interface에 액세스할 때 메뉴 탐색 문제가 발생함
    직렬 콘솔에서 Direct Control User Interface에 액세스하는 경우 메뉴를 탐색할 때 위쪽 및 아래쪽 화살표 키가 작동하지 않고 사용자가 DCUI 구성 화면에서 강제로 로그아웃됩니다.

    해결 방법: DCUI 프로세스를 중지합니다. DCUI 프로세스가 자동으로 다시 시작됩니다.

  • ESXi 호스트를 5.5 업데이트 2로 업그레이드한 후 호스트 구성을 변경하면 호스트 프로파일이 규정 준수로 잘못 표시될 수 있음
    호스트 프로파일 규정을 준수하는 ESXi 호스트를 ESXi 5.5 업데이트 2로 업데이트한 다음 호스트 구성을 일부 변경하고 호스트가 호스트 프로파일 규정을 준수하는지 다시 확인하면 프로파일이 규정 준수로 잘못 보고됩니다.

    해결 방법:
    • vSphere Client에서 문제가 있는 호스트 프로파일을 탐색하고 참조 호스트에서 프로파일 업데이트를 실행합니다.
    • vSphere Web Client에서 문제가 있는 호스트 프로파일을 탐색하고 호스트에서 설정 복사를 클릭하고 구성 설정을 복사할 호스트를 선택한 다음 확인을 클릭합니다.
  • vSphere Distributed Switch를 사용한 호스트 프로파일 업데이트 적용에 실패함
    vSphere Distributed Switch를 사용하여 호스트 프로파일을 적용할 때 Fault Tolerance를 사용하는 가상 시스템이 해당 호스트 프로파일의 Distributed Switch를 사용하는 호스트에서 전원이 꺼진 상태이면 업데이트 적용 오류가 발생할 수 있습니다.

    해결 방법: 호스트 프로파일이 정상적으로 적용되도록 전원이 꺼진 가상 시스템을 다른 호스트로 이동합니다.

  • ESXi 5.5.x 호스트에 ESX 4.0 또는 ESX 4.1 프로파일을 적용할 때 호스트 프로파일에 방화벽 설정 규정 준수 오류가 발생함
    ESX 4.0 또는 ESX 4.1 호스트에서 호스트 프로파일을 추출하여 ESXi 5.5.x 호스트에 적용하려는 경우 프로파일 업데이트 적용이 성공합니다. 규정 준수 검사에서 다음을 포함하는 방화벽 설정 오류가 발생합니다.

    규칙 집합 LDAP를 찾을 수 없음
    규칙 집합 LDAPS를 찾을 수 없음
    규칙 집합 TSM을 찾을 수 없음
    규칙 집합 VCB를 찾을 수 없음
    규칙 집합 activeDrirectorKerberos를 찾을 수 없음

    해결 방법: 해결 방법이 필요하지 않습니다. ESX 4.0 또는 ESX 4.1 호스트의 방화벽 설정이 ESXi 5.5.x 호스트의 방화벽 설정과 다르기 때문에 나타나는 현상입니다.

  • ESXi 호스트에 대한 BIOS 디바이스 설정이 변경되면 디바이스 이름이 잘못될 수 있음
    ESXi 호스트에 대한 BIOS 디바이스 설정이 변경되면 해당 변경으로 인해 디바이스에 할당된 <segment:bus:device:function> 값이 전환될 경우 디바이스 이름이 잘못될 수 있습니다. 예를 들어 이전에 사용 안 함으로 설정되어 있던 통합 NIC를 사용하도록 설정하면 다른 PCI 디바이스에 할당된 <segment:bus:device:function> 값이 전환되어 ESXi에서 이러한 NIC에 할당된 이름이 변경됩니다. 이전 버전의 ESXi와 달리 ESXi 5.5에서는 호스트 BIOS가 특정 디바이스 위치 정보를 제공할 경우 <segment:bus:device:function> 값을 변경함으로써 디바이스 이름을 보존하려고 합니다. 이 기능에 버그가 발생하면 vmhba1 및 vmnic32처럼 잘못된 이름이 생성되는 경우도 있습니다.

    해결 방법: ESXi 호스트를 1~2회 재부팅하면 잘못된 디바이스 이름이 제거되고 기존의 이름이 복원될 수 있습니다. 운영 시 잘못된 디바이스 이름을 사용하여 ESXi 호스트를 실행하지 마십시오.

스토리지 문제

  • 데이터스토어에 대한 VMFS 하트비트의 시간이 초과될 때 HBA 드라이버가 설치된 ESXi 호스트가 응답을 중단할 수 있음*
    데이터스토어에 대한 VMFS 하트비트의 시간이 초과될 때 HBA 드라이브가 설치된 ESXi 호스트가 다음과 비슷한 메시지를 표시하며 응답을 중단할 수 있습니다.

    mem>2014-05-12T13:34:00.639Z cpu8:1416436)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:651: Path "vmhba2:C0:T1:L10" (UP) command 0xa3 failed with status Timeout. H:0x5 D:0x0 P:0x0 Possible sense data: 0x5 0x20 0x0.2014-05-12T13:34:05.637Z cpu0:33038)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:651: Path "vmhba2:C0:T1:L4" (UP) command 0xa3 failed with status Timeout. H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.

    데이터스토어의 높은 디스크 I/O가 ESXi 호스트에 연결되고 다중 경로가 HBA 수준이 아니라 대상 수준에서 사용함으로 설정되어 있을 때 HBA 드라이버에서 이 문제가 발생합니다.

    해결 방법: HBA 드라이버를 최신 비동기 HBA 드라이버로 교체합니다.
  • RDM 디스크가 포함된 가상 시스템의 라이브 Storage vMotion을 수행하려고 하면 작업이 실패할 수 있음
    RDM 디스크가 포함된 가상 시스템의 Storage vMotion이 실패할 수 있고 가상 시스템 전원이 꺼진 상태로 표시될 수 있습니다. 가상 시스템 전원을 켜려는 시도가 실패하고 다음 오류가 표시됩니다.

    파일을 잠그지 못했습니다.

    해결 방법: 없음.
  • 이름이 바뀐 태그가 VM 스토리지 정책 편집 마법사에서 누락된 것으로 표시됨
    가상 시스템 스토리지 정책에는 데이터스토어 태그를 기반으로 하는 규칙이 포함될 수 있습니다. 태그 이름을 바꾸면 이 태그를 참조하는 스토리지 정책에서 태그를 자동으로 업데이트하지 않고 누락된 것으로 표시합니다.

    해결 방법: 가상 시스템 스토리지 정책에서 누락된 것으로 표시된 태그를 제거하고 이름이 변경된 태그를 추가합니다. 스토리지 정책을 오래된 모든 엔티티에 다시 적용합니다.

  • Flash Read Cache 블록 크기가 16KB, 256KB, 512KB 또는 1024KB로 설정된 경우 가상 시스템의 전원을 켤 수 없음
    Flash Read Cache가 구성되어 있고 블록 크기가 16KB, 256KB, 512KB 또는 1024KB인 가상 시스템의 전원을 켤 수 없습니다. Flash Read Cache의 경우 캐시 크기는 최소 4MB에서 최대 200GB까지, 블록 크기는 최소 4KB에서 최대 1MB까지 지원합니다. 가상 시스템의 전원을 켤 때 작업이 실패하고 다음과 같은 메시지가 표시됩니다.

    VM의 전원을 켜는 동안 ESX 호스트에서 오류를 수신했습니다.

    가상 시스템을 시작하지 못했습니다.

    DiskEarly 모듈의 전원을 켜지 못했습니다.

    scsi0:0 디스크를 구성하지 못했습니다.

    구성되지 않은 디스크가 있는 가상 시스템의 전원을 켤 수 없습니다. vFlash 캐시를 연결할 수 없습니다(msg.vflashcache.error.VFC_FAILURE).

    해결 방법: 가상 시스템 Flash Read Cache 크기 및 블록 크기를 구성합니다.

    1. 가상 시스템을 마우스 오른쪽 버튼으로 클릭하고 설정 편집을 선택합니다.
    2. 가상 하드웨어 탭에서 하드 디스크를 확장하여 디스크 옵션을 표시합니다.
    3. 가상 Flash Read Cache 필드 옆의 고급을 클릭합니다.
    4. 캐시 예약 크기를 늘리거나 블록 크기를 줄입니다.
    5. 확인을 클릭하여 변경 내용을 저장합니다.
  • 저장된 리소스 풀 트리 파일의 사용자 지정 확장자를 vSphere Web Client에서 로드할 수 없음
    호스트 요약 페이지에 DRS 오류 메시지가 나타납니다.

    vSphere Web Client에서 DRS를 사용하지 않도록 설정할 때 리소스 풀 구조를 나중에 다시 로드할 수 있도록 저장하라는 메시지가 표시됩니다. 이 파일의 기본 확장자는 .snapshot이지만 다른 확장자를 선택할 수 있습니다. 이 파일이 사용자 지정 확장자를 사용하는 경우 해당 파일을 로드하려고 하면 사용할 수 없는 것으로 표시됩니다. 이 동작은 OS X에서만 발견됩니다.

    해결 방법: OS X의 vSphere Web Client에 이 파일을 로드하려면 확장자를 .snapshot으로 변경합니다.

  • 호스트 요약 페이지에 DRS 오류 메시지가 표시됨
    호스트 요약 페이지에 다음과 같은 DRS 오류 메시지가 나타납니다.

    호스트에서 DRS 리소스 설정을 적용할 수 없습니다. 현재 상태에서 허용되지 않는 작업입니다. DRS의 효율성이 대폭 감소할 수 있습니다.

    일부 구성에서 경합 조건으로 인해 의미 없거나 조치를 취할 수 없는 오류 메시지가 로그에 생성될 수 있습니다. 이 오류는 DRS 리소스 설정을 적용하는 것과 동시에 가상 시스템의 등록을 취소하는 경우 발생할 수 있습니다.

    해결 방법: 이 오류 메시지를 무시하십시오.

  • 16TB보다 큰 VMDK에 대해 가상 Flash Read Cache를 구성하면 오류가 발생함
    가상 Flash Read Cache는 16TB보다 큰 가상 시스템 디스크를 지원하지 않습니다. 이러한 디스크를 구성하려고 하면 작업이 실패합니다.

    해결 방법: 없음

  • 캐시 크기를 재구성할 때 가상 시스템의 전원이 꺼질 수 있음
    가상 시스템에서 가상 Flash Read Cache를 재구성할 때 잘못된 값을 할당하는 등 올바르지 않게 재구성하면 가상 시스템의 전원이 꺼질 수 있습니다.

    해결 방법: vSphere Storage 설명서의 권장 캐시 크기 지침을 따르십시오.

  • 가상 Flash Read Cache를 사용하도록 설정된 가상 시스템을 재구성하면 작업이 실패하고 작업 시간 초과 오류가 발생할 수 있음
    재구성 작업에는 상당한 양의 I/O 대역폭이 필요합니다. 로드를 많이 실행하는 경우 해당 작업이 완료되기 전에 시간이 초과될 수 있습니다. 호스트에 APD(모든 경로 다운) 상태인 LUN이 있는 경우에도 이 동작이 나타날 수 있습니다.

    해결 방법: 호스트 APD 상태를 모두 해결하고 LUN 및 호스트에서 보다 적은 I/O 로드로 작업을 다시 시도합니다.

  • DRS가 로드 밸런싱에 가상 Flash Read Cache를 사용하는 가상 시스템에 대해 vMotion을 수행하지 않음
    DRS가 로드 밸런싱에 가상 Flash Read Cache를 사용하는 가상 시스템에 대해 vMotion을 수행하지 않습니다.

    해결 방법: 다음과 같은 경우를 제외하고는 DRS에서 이러한 가상 시스템에 대해 vMotion을 수행하지 않는 것이 좋습니다.

    • 사용자가 유지 보수 또는 대기 모드로 전환하도록 요청한 호스트를 제거하려는 경우
    • DRS 규칙 위반을 해결하려는 경우
    • 호스트 리소스 사용량이 빨간색 상태인 경우
    • 하나 또는 대부분의 호스트가 초과 사용되고 가상 시스템 요구가 충족되지 않는 경우
      참고: 필요한 경우 DRS에서 이 이유를 무시하도록 설정할 수 있습니다.
  • 가상 시스템의 활성 메모리가 낮지만 사용되는 메모리가 높은 경우 호스트가 대기 모드로 전환됨
    ESXi 5.5에서는 기능의 강도를 줄이기 위해 DPM의 기본 동작을 변경합니다. 이와 같이 변경하면 활성 메모리는 낮지만 사용되는 메모리가 높을 때 발생하는 가상 시스템의 성능 저하 문제를 방지하는 데 도움이 될 수 있습니다. DPM 메트릭은 X%*IdleConsumedMemory + 활성 메모리입니다. X% 변수는 조정할 수 있으며 기본적으로 25%로 설정됩니다.

    해결 방법: 고급 옵션에서 PercentIdleMBInMemDemand=0을 설정하여 이전 ESXi 릴리스에 포함된 적극적 DPM 동작으로 복구할 수 있습니다.

  • DRS에서 시작된 vMotion이 실패할 수 있음
    DRS가 가상 Flash Read Cache 예약이 있는 가상 시스템에 vMotion을 권장할 때 대상 호스트에서 사용 가능한 메모리(RAM)가 부족하여 가상 시스템의 Flash Read Cache 예약을 관리할 수 없기 때문에 vMotion이 실패할 수 있습니다.

    해결 방법: vSphere Storage에 나와 있는 Flash Read Cache 구성 권장 사항을 따르십시오.
    vMotion이 실패할 경우 다음 단계를 수행합니다.

    1. 대상 호스트에 있는 가상 시스템 및 들어오는 가상 시스템의 블록 크기를 재구성하여 대상 호스트에서 VMkernel 메모리의 전체 목표 사용량을 줄입니다.
    2. vMotion을 사용하여 가상 시스템을 대상 호스트에 수동으로 마이그레이션하여 상태가 해결되도록 합니다.
  • 개별 SSD 디바이스의 가상 플래시를 구성하는 동안 발생하는 문제를 볼 수 없음
    가상 플래시 리소스 구성은 SSD 디바이스 목록에서 작동하는 작업입니다. 전체 개체에 대해 작업이 완료되면 vSphere Web Client는 작업을 성공한 것으로 보고하며 개별 SSD 디바이스의 구성 관련 문제에 대한 알림을 받을 수 없습니다.

    해결 방법: 다음 작업 중 하나를 수행합니다.

    • 최근 작업 패널에서 완료된 작업을 두 번 클릭합니다.
      작업 세부 정보 대화상자의 관련 이벤트 섹션에 모든 구성 오류가 표시됩니다.
    • 또는 다음 단계를 따릅니다.
      1. 인벤토리에서 호스트를 선택합니다.
      2. 모니터 탭을 클릭하고 이벤트를 클릭합니다.
  • ESXi 호스트에서 Micron PCIe SSD에 대한 SMART 정보를 가져올 수 없음
    esxcli storage core device smart get -d 명령을 사용하여 Micron PCIe SSD 디바이스에 대한 통계를 표시하려고 하면 작업이 실패합니다. 다음과 같은 오류 메시지가 표시됩니다.
    Smart 매개 변수를 가져오는 동안 오류가 발생했습니다. 디바이스를 열 수 없습니다.

    해결 방법: 없음. 이번 릴리스에서는 esxcli storage core device smart 명령이 Micron PCIe SSD를 지원하지 않습니다.

  • ESXi는 가상 시스템의 구성 파일에서 SCSI 가상 디스크에 대해 구성된 대역폭 제한을 적용하지 않음
    SCSI 가상 디스크의 대역폭 및 처리량 제한은 가상 시스템 구성 파일(.vmx)의 매개 변수 집합을 사용하여 구성합니다. 예를 들어 구성 파일에는 다음과 같은 scsi0:0 가상 디스크의 제한이 포함될 수 있습니다.
    sched.scsi0:0.throughputCap = "80IOPS"
    sched.scsi0:0.bandwidthCap = "10MBps"
    sched.scsi0:0.shares = "normal"

    ESXi는 sched.scsi0:0.bandwidthCap 제한을 scsi0:0 가상 디스크에 적용하지 않습니다.

    해결 방법: vSphere Web Client 또는 esxcli system settings advanced set 명령을 사용하여 이전 버전의 디스크 I/O 스케줄러로 복구합니다.

    • vSphere Web Client에서 호스트의 고급 시스템 설정 목록에서 Disk.SchedulerWithReservation 매개 변수를 편집합니다.
      1. 호스트로 이동합니다.
      2. 관리 탭에서 설정을 선택하고 고급 시스템 설정을 선택합니다.
      3. Disk.SchedulerWithReservation 매개 변수를 찾습니다. 이때 필터 또는 찾기 텍스트 상자를 사용합니다.
      4. 편집을 클릭하고 매개 변수를 0으로 설정합니다.
      5. 확인을 클릭합니다.
    • 호스트에 대한 ESXi Shell에서 다음 콘솔 명령을 실행합니다.
      esxcli system settings advanced set -o /Disk/SchedulerWithReservation -i=0
  • 캐시에 오류가 있으면 Flash Read Cache가 구성된 가상 시스템을 호스트 밖으로 마이그레이션할 수 없음
    캐시가 오류 상태이고 사용할 수 없다면 Flash Read Cache가 구성된 가상 시스템에서 마이그레이션 오류가 발생했을 수 있습니다. 이 오류가 발생하면 가상 시스템 마이그레이션이 실패합니다.

    해결 방법:

    1. 가상 시스템을 재구성하고 캐시를 비활성화합니다.
    2. 마이그레이션을 수행합니다.
    3. 가상 시스템이 마이그레이션된 후 캐시를 다시 사용합니다.

    또는 가상 시스템을 껐다 켜서 캐시 오류를 교정합니다.

  • 호스트를 ESXi 5.5 베타에서 업그레이드하고 나서 VFFS 볼륨을 삭제할 수 없음
    호스트를 ESXi 5.5 베타에서 업그레이드하고 나서 VFFS 볼륨을 삭제할 수 없습니다.

    해결 방법: 이 문제는 ESXi 5.5 베타에서 ESXi 5.5로 업그레이드할 때만 발생합니다. 이 문제를 방지하려면 업그레이드하는 대신 ESXi 5.5를 설치합니다. ESXi 5.5 베타에서 업그레이드하려면 VFFS 볼륨을 삭제한 후 업그레이드합니다.

  • 이전 Windows 및 Linux 게스트 운영 체제를 사용하는 가상 시스템에서 가상 Flash Read Cache를 사용하도록 설정할 때 개선된 예상 지연 시간 런타임이 나타나지 않음
    가상 Flash Read Cache는 캐시 크기를 대상 작업 집합과 일치하도록 지정할 때와 게스트 파일 시스템을 4KB 이상 경계로 정렬했을 때 최적의 성능을 제공합니다. Flash Read Cache는 캐시 내에서 부분 블록 캐시가 수행되지 않도록 잘못 정렬된 블록을 필터링합니다. 이 동작은 일반적으로 Windows XP 및 Linux 2.6 이전 배포를 사용하는 가상 시스템의 VMDK에 대해 가상 Flash Read Cache가 구성되었을 때 나타납니다. 이러한 경우 캐시 점유율이 적은 낮은 캐시 적중률이 관찰되며, 이는 해당 VMDK의 캐시 예약이 낭비된다는 것을 나타냅니다. Windows 7, Windows 2008 및 Linux 2.6 이상 배포를 실행하는 가상 시스템에서는 파일 시스템이 4KB 경계로 정렬되어 최적의 성능을 보장하므로 이러한 동작이 나타나지 않습니다.

    해결 방법: 각 VMDK에 대해 캐시 적중률을 개선하고 캐시 예약을 최적으로 사용하려면 VMDK에 설치된 게스트 운영 체제가 4KB 이상 경계로 정렬되어 있는지 확인합니다.

Virtual SAN

  • vsan.disks_stats 명령을 실행할 때 다중 VSAN 디스크 그룹이 있는 ESXi 호스트가 자기 디스크 통계를 표시하지 않을 수 있음*
    vsan.disks_stats RVC(Ruby vSphere Console) 명령을 실행할 때 다중 VSAN 디스크 그룹이 있는 ESXi 호스트가 자기 디스크(MD) 통계를 표시하지 않을 수 있습니다. 호스트는 SSD(Solid-State Drive) 정보만 표시합니다.

    해결 방법: 없음
  • VM 디렉토리에 중복된 스왑(.vswp) 파일이 포함됨
    이 문제는 Virtual SAN에서 실행 중인 가상 시스템을 정상적으로 종료하지 않은 경우, 그리고 Virtual SAN 디스크에서 데이터를 지우지 않고 ESXi 및 vCenter Server를 새로 설치하는 경우에 발생할 수 있습니다. 결과적으로 정상적으로 종료되지 않은 가상 시스템의 디렉토리에서 이전 스왑 파일(.vswp)이 발견됩니다.

    해결 방법: 없음

  • Virtual SAN 디스크 그룹에 자기 디스크를 7개 이상을 추가하려는 시도가 실패하고 잘못된 오류 메시지가 표시될 수 있음
    Virtual SAN 디스크 그룹에서는 최대 1개의 SSD와 7개의 자기 디스크(HDD)를 지원합니다. 자기 디스크를 더 추가하려고 하면 작업이 실패하고 다음과 유사한 잘못된 오류 메시지가 표시될 수 있습니다.

    디스크 수가 부족합니다.

    해결 방법: 없음
  • Virtual SAN 디스크를 추가할 때 다시 검색 실패가 발생함
    Virtual SAN 디스크를 추가할 때 non-Virtual SAN 볼륨에 대한 검색 오류로 인해 다시 검색이 실패하고, 이로 인해 작업이 실패합니다.

    해결 방법: 디스크가 모두 올바로 등록되었으면 오류를 무시합니다.
  • 연결된 SSD(Solid State Drive)를 제거한 후 분리한 HDD(하드 디스크 드라이브)가 계속 Virtual SAN에서 할당된 스토리지 디스크로 표시될 수 있음
    Virtual SAN 데이터스토어에서 SSD 및 이와 연결된 HDD를 차례로 제거하고 esxcli vsan storage list 명령을 실행하는 경우 제거된 HDD가 Virtual SAN에서 할당된 스토리지 디스크로 계속 표시됩니다. HDD를 다른 호스트에 다시 삽입하는 경우 디스크가 2개의 다른 호스트에 속한 것으로 표시될 수 있습니다.

    해결 방법: 예를 들어 ESXi x에서 SSD와 HDD를 제거한 후 ESXi y에 삽입하는 경우 다음 단계를 수행하여 HDD가 ESXi x 및 ESXi y 모두에 속한 것으로 표시되지 않게 합니다.
    1. ESXi x에서 제거한 SSD 및 HDD를 ESXi y에 삽입합니다.
    2. ESXi x에서 SSD를 분리합니다.
    3. esxcfg-rescan -A 명령을 실행합니다.
       HDD 및 SSD가 ESXi x에 더 이상 표시되지 않습니다.
  • vSphere Storage 설명서의 Virtual SAN 작업 섹션에는 디스크 그룹당 최대 HDD 디스크 수가 6개로 나와 있습니다. 그러나 허용되는 최대 HDD 수는 7개입니다.
  • Virtual SAN 클러스터에 장애가 발생한 후 가상 시스템을 다시 시작하기 전 vSphere HA가 여러 이벤트를 보고할 수 있고, 그중 일부는 잘못된 것일 수 있음
    Virtual SAN에 장애가 발생한 것으로 표시된 후 vSphere HA 마스터 에이전트가 Virtual SAN에서 실행 중인 가상 시스템을 다시 시작하려고 여러 번 시도합니다. 가상 시스템을 즉시 다시 시작할 수 없으면 마스터 에이전트가 클러스터 상태를 모니터링하여 다시 시작할 수 있는 조건이 되면 다시 시작을 또 한 번 시도합니다. Virtual SAN에서 실행 중인 가상 시스템의 경우 vSphere HA 마스터는 특수한 애플리케이션 로직을 통해 가상 시스템 개체의 접근성 변경 조건을 감지하고 접근성이 변경되었을 가능성이 높을 때마다 다시 시작을 시도합니다. 마스터 에이전트는 접근성이 변경되었을 가능성이 있을 때마다 다시 시작을 시도하고, 가상 시스템의 전원을 켜지 못한 경우에는 다시 시작을 포기하고 다음 접근성 변경 조건이 발생할 때까지 기다립니다.

    다시 시작 시도에 실패할 때마다 vSphere HA가 페일오버에 성공하지 못했다는 이벤트를 보고하고 다섯 번째 시도에 실패하면 최대 페일오버 시도 횟수에 도달해서 vSphere HA가 가상 시스템 다시 시작 시도를 중지했다고 보고합니다. 그러나 vSphere HA 마스터 에이전트가 다시 시작 시도를 중지했다고 보고한 후에도 다음에 접근성이 변경될 가능성이 생기면 다시 시도합니다.

    해결 방법: 없음.

  • Virtual SAN 호스트의 전원을 끄면 vSphere Web Client에서 스토리지 제공자 보기를 새로 고치는 데 걸리는 시간이 예상보다 길어짐
    Virtual SAN 호스트의 전원을 끄는 경우 스토리지 제공자 보기가 빈 상태로 나타납니다. 아무 정보도 표시되지 않지만 새로 고침 버튼은 계속 돌아갑니다.

    해결 방법: 스토리지 제공자 보기가 다시 채워질 때까지 15분 이상 기다립니다. 또한 호스트의 전원을 켜면 보기가 새로 고쳐집니다.

  • Virtual SAN이 실패한 작업을 완료된 것으로 보고함
    Virtual SAN이 특정 작업이 내부적으로 실패했는데도 완료된 것으로 보고할 수 있습니다.

    오류의 조건 및 해당하는 원인은 다음과 같습니다.

    • 조건: Virtual SAN 라이센스가 만료되었는데 사용자가 새 디스크 그룹을 생성하거나 기존 디스크 그룹에 새 디스크를 추가하려고 합니다.
      오류 스택: 일반 시스템 오류가 발생했습니다. 디스크를 추가할 수 없습니다. 이 호스트에는 VSAN에 대한 라이센스가 없습니다.
    • 조건: 사용자가 디스크 수가 지원되는 수보다 많은 디스크 그룹을 생성하려고 합니다. 또는 기존 디스크 그룹에 새 디스크를 추가하여 총 수가 디스크 그룹당 지원되는 디스크 수를 초과합니다.
      오류 스택: 일반 시스템 오류가 발생했습니다. 디스크가 너무 많습니다.
    • 조건: 사용자가 오류가 발생한 디스크 그룹에 디스크를 추가하려고 합니다.
      오류 스택: 일반 시스템 오류가 발생했습니다. 파티션 테이블을 생성할 수 없습니다.

    해결 방법: 오류 원인을 식별했으면 원인을 수정하고 작업을 다시 시도합니다.

  • Virtual SAN 데이터스토어에서 호스트 로컬 스왑 파일 및 시스템 스왑 파일을 저장할 수 없음
    일반적으로 시스템 스왑 파일이나 호스트 로컬 스왑 파일을 데이터스토어에 저장할 수 있습니다. 그러나 Virtual SAN 데이터스토어는 시스템 스왑 파일 및 호스트 로컬 스왑 파일을 지원하지 않습니다. 따라서 Virtual SAN 데이터스토어를 시스템 스왑 또는 호스트 로컬 스왑의 파일 위치로 선택할 수 있는 UI 옵션을 사용할 수 없습니다.

    해결 방법: Virtual SAN 환경에서는 지원되는 다른 옵션을 사용하여 시스템 스왑 파일 및 호스트 로컬 스왑 파일을 저장합니다.

  • vSphere HA 클러스터의 Virtual SAN 가상 시스템이 전원이 꺼졌는데도 vSphere HA의 보호를 받는다고 보고됨
    가상 시스템의 홈 개체가 Virtual SAN 데이터스토어에 있지만 해당 홈 개체에 액세스할 수 없을 때 가상 시스템의 전원을 끄면 이 문제가 발생할 수 있습니다. 이 문제는 개체가 액세스할 수 없게 된 후 HA 마스터 에이전트를 선택하는 경우에 발생합니다.

    해결 방법:

    1. 개체가 지정된 스토리지 정책을 준수하는지 확인하여 홈 개체에 다시 액세스할 수 있도록 합니다.
    2. 가상 시스템의 전원을 켰다가 다시 끕니다.

    상태가 보호되지 않음으로 변경됩니다.

  • 다시 적용 작업이 트리거되어 성공적으로 완료된 후에도 가상 시스템 개체가 최신 버전이 아님 상태로 유지됨
    새로운 스토리지 요구 사항으로 인해 기존 가상 시스템 프로파일을 편집하는 경우 관련 가상 시스템 개체(홈 또는 디스크)가 최신 버전이 아님 상태가 될 수 있습니다. 이 문제는 현재 환경에서 가상 시스템 개체의 재구성을 지원할 수 없는 경우에 발생합니다. 다시 적용 작업을 사용해도 상태가 변경되지 않습니다.

    해결 방법: Virtual SAN 클러스터에 리소스(호스트 또는 디스크)를 추가하고 다시 적용 작업을 다시 호출합니다.

  • Virtual SAN을 사용하도록 설정한 후에 라이센스를 할당하는 경우 Virtual SAN에 대한 자동 디스크 할당이 제대로 작동하지 않음
    Virtual SAN을 자동 모드로 사용하도록 설정한 다음 라이센스를 할당하는 경우 Virtual SAN이 디스크를 할당하지 못합니다.

    해결 방법: 모드를 수동으로 변경했다가 다시 자동으로 전환합니다. Virtual SAN에 디스크가 제대로 할당됩니다.

  • Virtual SAN 네트워크가 분할되어 있는 경우 vSphere High Availability(HA)가 가상 시스템을 다시 시작하지 못함
    이 문제는 Virtual SAN이 노드 간 통신에 VMkernel 어댑터를 사용하고, 이 어댑터가 클러스터의 다른 VMkernel 어댑터와 동일한 서브넷에 있는 경우에 발생합니다. 이러한 구성에서는 네트워크 오류가 발생하고 Virtual SAN 노드 간 통신이 중단될 수 있지만 vSphere HA 노드 간 통신은 영향을 받지 않습니다.

    이 경우 HA 마스터 에이전트는 가상 시스템에서 오류를 감지할 수 있지만 가상 시스템을 다시 시작하지는 못합니다. 예를 들어 마스터 에이전트가 실행 중인 호스트가 가상 시스템의 개체에 액세스할 수 없는 경우 이 문제가 발생할 수 있습니다.

    해결 방법: Virtual SAN에서 사용하는 VMkernel 어댑터가 다른 용도로 사용되는 VMkernel 어댑터와 서브넷을 공유하지 않아야 합니다.

  • VM 디렉토리에 중복된 스왑(.vswp) 파일이 포함됨   
    이 문제는 Virtual SAN에서 실행 중인 가상 시스템을 정상적으로 종료하지 않은 경우, 그리고 Virtual SAN 디스크에서 데이터를 지우지 않고 ESXi 및 vCenter Server를 새로 설치하는 경우에 발생할 수 있습니다. 결과적으로 정상적으로 종료되지 않은 가상 시스템의 디렉토리에서 이전 스왑 파일(.vswp)이 발견됩니다.

    해결 방법: 없음

  • 긴 네트워크 지연 시간으로 인해 VM에 액세스할 수 없게 될 수 있음
    Virtual SAN 클러스터 설정에서 네트워크 지연 시간이 길면 일부 VM은 vCenter Server에서 액세스할 수 없게 될 수 있으며 VM의 전원을 켜거나 VM에 액세스할 수 없습니다.

    해결 방법: vsan.check_state -e -r RVC 명령을 실행하십시오.
  • 네트워크 지연 시간이 길어 VM 작업이 시간 초과될 수 있음
    대기열 크기가 작은 스토리지 컨트롤러가 사용될 때 네트워크 지연 시간이 길어지면 VM 작업이 시간 초과될 수 있습니다.

    해결 방법: 네트워크 로드가 적어질 때 작업을 다시 시도하십시오.
  • VM 이름이 잘린 형태의 vmx 파일 경로로 바뀔 수 있음
    가상 시스템의 vmx 파일에 일시적으로 액세스할 수 없는 경우 VM 이름이 잘린 형태의 vmx 파일 경로로 바뀝니다. 예를 들어 가상 시스템 이름이 /vmfs/volumes/vsan:52f1686bdcb477cd-8e97188e35b99d2e/236d5552-ad93으로 바뀔 수 있습니다. 이러한 잘림은 VM 홈 디렉토리의 UUID 절반을 삭제하므로 이름이 바뀐 VM을 단지 VM 이름만으로 원래 VM에 매핑하기 어려울 수 있습니다.

    해결 방법: vsan.fix_renamed_vms RVC 명령을 실행하십시오.

vCenter Server 및 vSphere Web Client

  • Active Directory 도메인에 ESXi 호스트를 추가할 수 없음
    사용자 및 그룹 선택 옵션 아래에서 사용 권한을 할당할 때 도메인 드롭다운 목록에 Active Directory 도메인 이름이 표시되지 않을 수 있습니다. 또는 Active Directory에 신뢰할 수 있는 도메인이 있음에도 불구하고 인증 서비스 설정 옵션에 신뢰할 수 있는 도메인 컨트롤러가 표시되지 않을 수 있습니다.

    해결 방법:
    1. netlogond, lwiod 및 lsassd 대몬을 차례로 다시 시작합니다.
    2. vSphere Client를 사용하여 ESXi 호스트에 로그인합니다.
    3. 구성 탭에서 인증 서비스 설정을 클릭합니다.
    4. 화면을 새로 고쳐 신뢰할 수 있는 도메인을 확인합니다.

가상 시스템 관리 문제

  • VMDK 파일 이름이 "core"로 시작할 경우 가상 시스템의 콜드 마이그레이션 및 Storage vMotion을 수행할 수 없음*
    VMDK 파일 이름이 "core"로 시작할 경우 가상 시스템의 콜드 마이그레이션 및 Storage vMotion을 수행하면 다음과 유사한 오류 메시지와 함께 실패할 수 있습니다.

    일반 시스템 오류가 발생했습니다. VM 파일의 이름을 지정 또는 변경하는 중 오류가 발생했습니다.

    다음과 유사한 오류 메시지가 vpxd.log 파일에 표시될 수 있습니다.

    mem> 2014-01-01T11:08:33.150-08:00 [13512 info 'commonvpxLro' opID=8BA11741-0000095D-86-97] [VpxLRO] -- FINISH task-internal-2471 -- -- VmprovWorkflow --
    mem> 2014-01-01T11:08:33.150-08:00 [13512 info 'Default' opID=8BA11741-0000095D-86-97] [VpxLRO] -- ERROR task-internal-2471 -- -- VmprovWorkflow: vmodl.fault.SystemError:
    mem> --> Result:
    mem> --> (vmodl.fault.SystemError){
    mem> --> dynamicType = ,
    mem> --> faultCause = (vmodl.MethodFault) null,
    mem> --> reason = "Error naming or renaming a VM file.",
    mem> --> msg = "",
    mem> --> }

    ESXi 호스트가 이름이 "core"로 시작하는 VMDK 파일을 예상된 디스크 유형이 아닌 코어 파일로 잘못 분류할 때 이 문제가 발생합니다.

    해결 방법: 가상 시스템의 VMDK 파일 이름이 "core"로 시작하지 않도록 하십시오. 또한 vmkfstools 유틸리티를 사용하여 VMDK 파일의 이름이 "core" 단어로 시작하지 않도록 파일 이름을 바꾸십시오.
  • 프랑스어 로케일의 Windows 7 Enterprise 64비트 게스트 운영 체제를 사용하는 가상 시스템에서 복제 작업 중 문제 발생
    프랑스어 로케일로 실행 중인 복제된 Windows 7 Enterprise 64비트 가상 시스템이 있는 경우 가상 시스템의 네트워크 연결이 끊어지고 사용자 지정 규격이 적용되지 않습니다. 이 문제는 가상 시스템이 ESXi 5.1 호스트에서 실행되고 있을 때 시스템을 ESXi 5.5로 복제하고 VMware Tools 버전을 5.5 호스트에서 사용 가능한 최신 버전으로 업그레이드하는 경우에 나타납니다.

    해결 방법: 사용 가능한 최신 버전의 VMware Tools로 업그레이드하기 전에 가상 시스템 호환성을 ESXi 5.5 이상으로 업그레이드합니다.

  • 실행 중인 가상 시스템에서 가상 디스크의 크기를 늘리려고 하면 작업이 실패하고 오류가 발생함
    가상 시스템이 실행 중일 때 가상 디스크 크기를 늘리는 경우 작업이 실패하고 다음과 같은 오류가 발생할 수 있습니다.

    이 디바이스 유형에는 이 작업이 지원되지 않습니다.

    디스크 크기를 2TB 이상으로 확장하는 경우 오류가 발생할 수 있습니다. 핫 확장 작업에서는 디스크 크기를 2TB 미만으로만 늘릴 수 있습니다. SATA 가상 디스크는 크기에 관계없이 핫 확장 작업을 지원하지 않습니다.

    해결 방법: 가상 디스크를 2TB 이상으로 확장하려면 가상 시스템의 전원을 끕니다.

VMware HA 및 Fault Tolerance 문제
  • vSphere HA 클러스터에서 ESX/ESXi 4.0 또는 4.1 호스트를 선택하여 가상 시스템을 페일오버하면 가상 시스템이 정상적으로 다시 시작되지 않을 수 있음
    vSphere HA가 가상 시스템이 실행되던 원래 호스트와 다른 ESX/ESXi 4.0 또는 4.1 호스트에서 가상 시스템을 다시 시작하면 응답을 받지 못하는 쿼리가 실행됩니다. vSphere Client에서 사용자가 직접 쿼리에 응답할 때까지 새 호스트에서 가상 시스템의 전원이 켜지지 않습니다.

    해결 방법: vSphere Client에서 쿼리에 응답합니다. 또는 시간이 초과될 때(기본적으로 15분)까지 기다리면 vSphere HA가 다른 호스트에서 가상 시스템을 다시 시작하려고 시도합니다. 호스트가 ESX/ESXi 5.0 이상을 실행하고 있으면 가상 시스템이 다시 시작됩니다.

  • 공유 스토리지가 없는 vMotion 작업이 vSphere HA 클러스터에서 실패하면 대상 가상 시스템이 예기치 않은 호스트에 등록될 수 있음
    공유 스토리지를 포함하지 않는 vMotion 마이그레이션은 대상 가상 시스템이 두 가상 시스템 간의 제어권 전송을 조정하는 핸드셰이크 메시지를 수신하지 않아 실패할 수 있습니다. vMotion 프로토콜은 소스 및 대상 가상 시스템의 전원을 모두 끕니다. 소스 및 대상 호스트가 동일한 클러스터에 있고 vSphere HA를 사용하도록 설정했으면 vSphere HA에 의해 대상 가상 시스템이 vMotion 마이그레이션 대상으로 선택한 호스트가 아닌 다른 호스트에 등록될 수 있습니다.

    해결 방법: 대상 가상 시스템을 유지하고 특정 호스트에 등록되게 하려면 대상 가상 시스템을 대상 호스트에 재배치합니다. 이때 가상 시스템을 재배치한 후에 전원을 켜는 것이 좋습니다.

지원되는 하드웨어 문제
  • 팬, 전원 공급 장치, 전압 및 현재 센서의 센서 값이 vCenter Server 하드웨어 상태 탭의 기타 그룹 아래에 나타남
    일부 센서 값은 분류된 해당 그룹이 아니라 기타 그룹에 나열됩니다.

    해결 방법: 없음.

  • 디버그 DMA(Direct Memory Access) 매퍼를 사용하도록 설정하면 IOMMU(입/출력 메모리 관리 장치) 장애가 나타날 수 있음
    디버그 매퍼는 디바이스를 IOMMU 도메인에 배치하여 디바이스 메모리가 명시적으로 매핑되지 않은 주소에 액세스하도록 도와 줍니다. 이전 펌웨어를 사용하는 일부 HP 시스템에서 IOMMU 장애가 나타날 수 있습니다.

    해결 방법: HP 웹 사이트에서 펌웨어 업그레이드를 다운로드하고 적용합니다.

    • HP iLO2 컨트롤러의 펌웨어를 업그레이드합니다.
      2011년 8월에 릴리스된 버전 2.07에서 이 문제를 해결합니다.
    • HP Smart Array의 펌웨어를 업그레이드합니다.
      HP Smart Array P410의 경우 2012년 1월에 릴리스된 버전 5.14에서 이 문제를 해결합니다.

VMware Tools 문제

  • VMware Tools가 이전에 설치되어 있지 않은 경우 vmware-install.pl -d 명령을 실행하여 Linux 게스트 운영 체제에서 VMware Tools를 설치할 수 없음*
    VMware Tools가 Linux 게스트 운영 체제에 설치되어 있지 않은 경우 vmware-install.pl -d 명령을 실행하여 VMware Tools를 새로 설치하려고 하면 설치가 실패할 수 있습니다.
    이 문제는 다음 게스트 운영 체제에서 발생합니다.
    • RHEL 7 이상
    • CentOS 7 이상
    • Oracle Linux 7 이상
    • Fedora 19 이상
    • SLES 12 이상
    • SLED 12 이상
    • openSUSE 12.2 이상
    • Ubuntu 14.04 이상
    • Debian 7 이상

    해결 방법: -default(-d) 스위치의 작동에 도움이 되는 해결 방법이 없습니다. 그러나 - default 스위치 없이 VMware Tools를 설치할 수 있습니다.
    설치 프로그램에서 이 구형 설치 프로그램으로 계속하시겠습니까?라는 옵션이 있는 메시지가 표시되면 를 선택합니다.

    참고: 이 릴리스에는 VMware Tools를 설치하기 위한 새로운 --force-install'(-f) 스위치가 추가되었습니다.
  • VMware Tools 업그레이드 후 파일이 사라짐
    VMware Tools를 업그레이드한 후 C:\Program Files\Vmware\Vmware Tools\에 있었던 deployPkg.dll 파일을 찾을 수 없습니다. 이 현상은 버전 5.1 업데이트 2에서 5.5 업데이트 1 이상으로, 그리고 버전 5.5에서 5.5 업데이트 1 이상으로 업그레이드할 때 나타납니다.

    해결 방법: 없음
  • OSP를 통해 VMware Tools를 설치 또는 제거하는 동안 사용자가 강제로 로그아웃됨
    OSP(Operating System Specific Package)를 사용하여 설치한 RHEL(Red Hat Linux Enterprise) 및 CentOS 가상 시스템에서 VMware Tools 패키지를 설치하거나 제거할 때 현재 사용자가 강제로 로그아웃됩니다. 이 문제는 RHEL 6.5 64비트, RHEL 6.5 32비트, CentOS 6.5 64비트 및 CentOS 6.5 32비트 가상 시스템에서 발생합니다.

    해결 방법:
    • SSH(보안 셸)를 사용하여 VMware Tools를 설치하거나 제거합니다.
      또는
    • 사용자는 다시 로그인하여 VMware Tools 패키지를 설치하거나 제거해야 합니다.

기타 문제

  • SRM 테스트 복구 작업이 실패하며 오류를 표시할 수 있음*
    SRM(Site Recovery Manager) 테스트 복구를 수행하려고 할 때 다음과 같은 유사한 오류 메시지가 표시되며 실패할 수 있습니다.
    '오류 - 일반 시스템 오류가 발생했습니다. VM을 찾을 수 없습니다.'
    테스트 복구 작업 여러 개를 동시에 수행하면 오류 메시지가 나타날 가능성이 증가합니다.

    해결 방법: 없음. 그러나 이는 지속적으로 발생하는 문제가 아니며 SRM 테스트 복구 작업을 다시 수행하면 이 문제가 발생하지 않을 수 있습니다.