Notas de la versión de VMware ESXi 6.0 Update 2

|

Actualizado: 4 de mayo de 2016

ESXi 6.0 Update 2 | 15 de marzo de 2016 | Compilación ISO 3620759

Compruebe las adiciones y las actualizaciones de las notas de la versión.

Contenido de las notas de la versión

Las notas de la versión abarcan los siguientes temas:

Novedades

  • Alta velocidad de vínculos Ethernet: ESXi 6.0 Update 2 admite velocidades de vínculos Ethernet de 25 G y 50 G.

  • VMware Host Client: VMware Host Client es un cliente HTML5 que se usa para conectar y administrar hosts ESXi individuales. Se puede usar para realizar tareas administrativas en recursos de hosts, como máquinas virtuales, redes y almacenamiento. VMware Host Client también puede resultar útil para solucionar problemas de hosts o máquinas virtuales individuales cuando vCenter Server y vSphere Web Client no están disponibles. Para obtener más información sobre VMware Host Client, consulte Notas de la versión de VMware Host Client 1.0.

  • VMware Virtual SAN 6.2: VMware Virtual SAN 6.2 y ESXi 6.0 Update 2 se incluyen en el mismo paquete. Para obtener más información sobre Virtual SAN, consulte las notas de la versión de VMware Virtual SAN 6.2.

    Virtual SAN incluye un nuevo VIB de vsan en la imagen de ESXi. El nuevo VIB implica la adición de una dependencia al VIB de esx-base, por lo que el VIB de vsan debe instalarse en el nuevo host 6.0 Update 2. Para obtener más información, consulte el artículo 2144595 de la base de conocimientos.

  • Mejora de las API de vSphere para filtros de E/S (VAIO):

    • ESXi 6.0 Update 2 admite el proveedor de VASA de filtro de E/S en un entorno IPv6 puro. Para obtener más información, consulte la sección Problemas resueltos.

    • ESXi 6.0 Update 2 admite las versiones de VMIOF 1.0 y 1.1. Para obtener más información, consulte la sección Problemas resueltos.

  • ESXi 6.0 Update 2 soluciona los problemas documentados en la sección Problemas resueltos.

Versiones anteriores de ESXi 6.0

Las características y los problemas conocidos de ESXi 6.0 se describen en las notas de la versión de cada versión. Las notas de la versión para versiones anteriores de ESXi 6.0 son las siguientes:

Internacionalización

VMware ESXi 6.0 está disponible en los siguientes idiomas:

  • Inglés
  • French
  • German
  • Japanese
  • Coreano
  • Chino simplificado
  • Español
  • Chino tradicional

Los componentes de VMware vSphere 6.0, incluidos vCenter Server, ESXi, vSphere Web Client y vSphere Client, no aceptan entradas que no sean ASCII.

Compatibilidad

Compatibilidad con las versiones de ESXi, vCenter Server y vSphere Web Client

La matriz de interoperabilidad de productos VMware ofrece detalles sobre la compatibilidad de la versión actual y las versiones anteriores de los componentes de VMware vSphere, incluidos ESXi, VMware vCenter Server, vSphere Web Client y los productos VMware opcionales. También se puede comprobar la matriz de interoperabilidad de productos VMware para obtener información sobre la administración admitida y los agentes de copia de seguridad antes de instalar ESXi o vCenter Server.

vSphere Web Client viene empaquetado con vCenter Server. Se puede instalar vSphere Client desde el menú de ejecución automática de VMware vCenter que forma parte del archivo ISO de los módulos.

Compatibilidad de hardware con ESXi

Para ver una lista de los procesadores, los dispositivos de almacenamiento, las matrices SAN y los dispositivos de E/S que son compatibles con vSphere 6.0, utilice la información sobre ESXi 6.0 incluida en la Guía de compatibilidad de VMware.

Compatibilidad de dispositivos con ESXi

Para determinar qué dispositivos son compatibles con ESXi 6.0, utilice la información sobre ESXi 6.0 incluida en la Guía de compatibilidad de VMware.

Algunos dispositivos quedaron obsoletos y ya no son compatibles con ESXi 6.0. Durante el proceso de actualización, el controlador de dispositivos se instala en el host ESXi 6.0. El controlador de dispositivos puede seguir funcionando en ESXi 6.0, pero el dispositivo no es compatible con ESXi 6.0. Para obtener una lista de los dispositivos obsoletos que ya no son compatibles con ESXi 6.0, consulte el artículo KB 2087970.

Compatibilidad de conmutadores de terceros con ESXi

VMware ahora es compatible con Cisco Nexus 1000V y vSphere 6.0. vSphere requiere una versión mínima de NX-OS 5.2(1)SV3(1.4). Para obtener más información sobre Cisco Nexus 1000V, consulte las Notas de la versión de Cisco. Como en las versiones anteriores de vSphere, el modo AVS de Cisco Nexus 1000V no es compatible.

Compatibilidad de sistemas operativos invitados con ESXi

Para determinar qué sistemas operativos invitados son compatibles con vSphere 6.0, utilice la información sobre ESXi 6.0 incluida en la Guía de compatibilidad de VMware.

Compatibilidad de máquinas virtuales con ESXi

Las máquinas virtuales que son compatibles con ESX 3.x y versiones posteriores (versión de hardware 4) se admiten en ESXi 6.0. Las máquinas virtuales que son compatibles con ESX 2.x y versiones posteriores (versión de hardware 3) no se admiten. Para utilizar estas máquinas virtuales en ESXi 6.0, actualice la compatibilidad de máquinas virtuales. Consulte la documentación sobre la actualización de vSphere.

Instalación y actualizaciones de esta versión

Notas para la instalación de esta versión

Lea la documentación sobre Instalación y configuración de vSphere a fin de obtener instrucciones para instalar y configurar ESXi y vCenter Server.

Si bien las instalaciones son directas, hay varios pasos de configuración posteriores que son esenciales. Lea la siguiente documentación:

Modelos de implementación recomendados de vSphere 6.0

VMware recomienda solo dos modelos de implementación:

  • vCenter Server con instancia integrada de Platform Services Controller. Este modelo se recomienda si se precisan implementar una o más instancias independientes de vCenter Server en un centro de datos. No se recomienda la replicación entre estos modelos de vCenter Server con instancias integradas de Platform Services Controller.

  • vCenter Server con instancia externa de Platform Services Controller. Este modelo se recomienda solo si deben vincularse varias instancias de vCenter Server o si se busca reducir el tamaño de la instancia de Platform Services Controller en el centro de datos. La replicación entre estos modelos de vCenter Server con instancias externas de Platform Services Controller es compatible.

Lea la documentación sobre Instalación y configuración de vSphere a fin de obtener instrucciones para instalar y configurar vCenter Server.

Lea el documento Actualizar la secuencia de vSphere 6.0 y sus productos VMware compatibles (Update sequence for vSphere 6.0 and its compatible VMware products) para conocer la secuencia correcta en la que deben actualizarse los componentes de vSphere.

También lea el artículo KB 2108548 para obtener las instrucciones para instalar y configurar vCenter Server.

Información del sistema operativo host de vCenter

Lea el artículo KB 2091273 de la base de conocimientos.

Hacer copias de seguridad de vCenter Server y de las implementaciones de vCenter Server Appliance que utilizan una instancia externa de Platform Services Controller y restaurar

Aunque las instrucciones en la documentación sobre Instalación y configuración de vSphere recomiendan que no intente hacer copias de seguridad ni restaurar implementaciones de vCenter Server y vCenter Server Appliance que utilizan una instancia externa de Platform Services Controller, puede realizar esta tarea siguiendo los pasos en el artículo KB 2110294.

Migración de instancias integradas de Platform Services Controller a instancias externas de Platform Services Controller

vCenter Server con instancias integradas de Platform Services Controller no puede migrarse automáticamente a vCenter Server con instancias externas de Platform Services Controller. La prueba de esta utilidad de migración no está completa.

Antes de instalar vCenter Server, determine la opción de implementación deseada. Si se requiere más de una instancia de vCenter Server para configurar la replicación, implemente siempre vCenter con una instancia externa de Platform Services Controller.

Migrar soluciones de terceros

Para obtener información sobre la actualización con personalizaciones de terceros, consulte la documentación de Actualización de vSphere. Para obtener información sobre cómo utilizar Image Builder para hacer una ISO personalizada, consulte la documentación de Instalación y configuración de vSphere.

Actualizaciones e instalaciones no permitidas para CPU que no son compatibles

vSphere 6.0 admite únicamente procesadores disponibles a partir de junio (tercer trimestre) de 2006. Al comparar los procesadores compatibles con vSphere 5.x, vSphere 6.0 ya no admite los siguientes procesadores:

  • AMD Opteron serie 12xx
  • AMD Opteron serie 22xx
  • AMD Opteron serie 82xx

Durante una instalación o actualización, el instalador comprueba la compatibilidad de la CPU de host con vSphere 6.0. Si el hardware del host no es compatible, aparece una pantalla púrpura con un mensaje de información sobre incompatibilidad y el proceso de instalación de vSphere 6.0 se detiene.

Notas para la actualización de esta versión

Para ver las instrucciones sobre cómo actualizar los hosts vCenter Server y ESX/ESXi, consulte la documentación de Actualización de vSphere.

Componentes de código abierto para VMware vSphere 6.0

Las declaraciones de copyright y las licencias vigentes para los componentes de software de código abierto distribuidos en vSphere 6.0 están disponibles en http://www.vmware.com. Debe iniciar sesión en su cuenta de My VMware. A continuación, en el menú Descargas, seleccione vSphere. En la pestaña Código abierto, también puede descargar los archivos de origen de GPL, LGPL u otros tipos de licencias similares que requieren código abierto o modificaciones disponibles en el código abierto para la versión de vSphere más reciente.

Avisos de compatibilidad con el producto

  • Base de datos de vCenter Server. Oracle 11g y 12c como bases de datos externas de vCenter Server Appliance cayeron en desuso en la versión de vSphere 6.0. VMware sigue siendo compatible con Oracle 11g y 12c como bases de datos externas de vSphere 6.0. VMware dejará de admitir Oracle 11g y 12c como bases de datos externas de vCenter Server Appliance en una versión principal futura.

  • vSphere Web Client. La selección de Informes de almacenamiento en la pestaña Supervisar de un objeto ya no está disponible en vSphere 6.0 Web Client.

  • vSphere Client. La pestaña Vistas de almacenamiento ya no está disponible en vSphere 6.0 Client.

Revisiones incluidas en esta versión

Esta versión incluye todos los boletines de ESXi que se lanzaron antes de la fecha de lanzamiento de este producto. Consulte la página de VMware Descargar revisiones para obtener más información sobre cada boletín.

La versión de revisión ESXi600-Update02 incluye los siguientes boletines individuales:

ESXi600-201603201-UG: Actualización de esx-base, vsanhealth, vsan vib
ESXi600-201603202-UG: Actualización de misc-drivers, xhci-xhci, otros
ESXi600-201603203-UG: Actualización de ESXi 6.0 esx-tboot vib
ESXi600-201603204-UG-BG: Actualización de ESXi 6.0 tools-light vib
ESXi600-201603205-UG-BG: Actualización de ESXi 6.0 esx-ui vib
ESXi600-201603206-UG-BG: Actualización de ESXi 6.0 nvme vib
ESXi600-201603207-UG-BG: Actualización de ESXi 6.0 net-vmxnet3 vib
ESXi600-201603208-UG-BG: Actualización de ESXi 6.0 sata-ahci vib

La versión de revisión ESXi600-Update02 (Security-only build) incluye los siguientes boletines individuales:

ESXi600-201603101-SG: Actualización de ESXi 6.0 esx-base vib
ESXi600-201603102-SG: Actualización de ESXi 6.0 tools-light vib

La versión de revisión ESXi600-Update02 incluye los siguientes perfiles de imágenes:

ESXi-6.0.0-20160302001-standard
ESXi-6.0.0-20160302001-no-tools

La versión de revisión ESXi600-Update02 (Security-only build) incluye los siguientes perfiles de imagen:

ESXi-6.0.0-20160301001s-standard
ESXi-6.0.0-20160301001s-no-tools

Para obtener información sobre la clasificación de revisiones y actualizaciones, consulte el artículo KB 2014447.

Problemas resueltos

Los problemas resueltos se agrupan del siguiente modo:



Problemas con el CIM y las API
  • Posible error en la supervisión de hardware cuando usa el software de terceros ServerView RAID Manager
    Es posible que reciba errores de supervisión de hardware cuando usa el software de terceros ServerView RAID Manager. El comando sfcb-vmware_aux deja de responder debido a una condición de carrera.

    El problema está resuelto en esta versión.

  • Falta de respuesta de la pestaña Estado de hardware con un mensaje de error
    Es posible que la pestaña Estado de hardware deje de responder cuando se accede al dispositivo FRU en Word y read_cnt es mayor o igual que 1. En el archivo syslog.log se registra un mensaje de error similar al siguiente:

    Dropped response operation details -- nameSpace: root/cimv2, className: OMC_RawIpmiEntity, Type: 0\

    El problema está resuelto en esta versión.

Problemas varios
  • Hostd deja de responder cuando se ejecutan comandos esxcli con PowerCLI
    Es posible que hostd deje de responder cuando ejecuta comandos esxcli con PowerCLI, lo cual genera fugas de memoria y consumo de memoria que supera el límite máximo. En el archivo hostd.log se registra un mensaje de error similar al siguiente:

    YYYY-MM-DDTHH:MM:SS.135Z [nnnnnnnn error 'UW Memory checker'] Current value 646016 exceeds hard limit 643993. Shutting down process.

    El problema está resuelto en esta versión.
  • El host ESXi experimenta una pantalla de diagnóstico de color morado con varios mensajes de interrupción de comprobación de equipo corregido (CMCI)

    El host ESXi puede generar un error con una pantalla de diagnóstico de color morado cuando una CPU deja de responder debido a varios CMCI en el archivo vmkernel.log en un plazo de tiempo muy corto. En la pantalla de diagnóstico de color morado, se muestran entradas similares a las siguientes:

    PCPU <N>: no heartbeat (2/2 IPIs received)
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]MCEReapMCABanks@vmkernel#nover+0x195
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]MCEHandleCMCI@vmkernel#nover+0xb4
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]IRQ_DoInterrupt@vmkernel#nover+0x33e
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]IDT_IntrHandler@vmkernel#nover+0x12b 0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]gate_entry@vmkernel#nover+0x64
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]LFQueue_Dequeue@vmkernel#nover+0x59
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]MCEBottomHalf@vmkernel#nover+0x39
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]BH_DrainAndDisableInterrupts@vmkernel#nover+0xf3
    0xXXXXXXXXXXXX:[0xXXXXXXXXXXXX]VMMVMKCall_Call@vmkernel#nover+0x2c6


    En el archivo vmkernel.log, se registran entradas similares a las siguientes:

    cpu1:33127)MCE: 1118: cpu1: MCA error detected via CMCI (Gbl status=0x0): Restart IP: invalid, Error IP: invalid, MCE in progress: no.
    cpu1:33127)MCE: 231: cpu1: bank9: MCA recoverable error (CE): "Memory Controller Scrubbing Error on Channel 0."
    cpu1:33127)MCE: 222: cpu1: bank9: status=0xXXXXXXXXXXXXXXXX: (VAL=1, OVFLW=0, UC=0, EN=0, PCC=0, S=0, AR=0), ECC=no, Addr:0xXXXXXXXXXXXXXXXX (valid), Misc:0x8c3589300 (valid)

    El problema está resuelto en esta versión.

Problemas de redes
  • Las estadísticas de vSISH muestran un gran número de paquetes descartados
    Es posible que las estadísticas de VSISH muestren un gran número de falsos positivos de paquetes descartados debido al desbordamiento de enteros.

    El problema está resuelto en esta versión.
  • Nuevo Puede que se produzca un error con una pantalla de diagnóstico de color morado en el host ESXi con la función Netflow habilitada en el entorno VXLAN
    Puede que se produzca un error con una pantalla de diagnóstico de color morado en el host ESXi con la función Netflow habilitada en el entorno VXLAN con entradas similares a las siguientes:

    @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4923 - Error de uso en dlmalloc
    PTEs:0xnnnnnnnn;0xnnnnnnnn;0x0;
    0xnnnnnnnn:[0xnnnnnnnn]PanicvPanicInt@vmkernel#nover+0x37e
    ....
    ....
    0xnnnnnnnn:[0xnnnnnnnn]Net_AcceptRxList@vmkernel#nover+0x115


    El problema está resuelto en esta versión.
  • En un entorno de vDS, vMotion falla después de eliminar LAG
    En un entorno de vSphere Distributed Switch (vDS), vMotion falla después de quitar grupos de agregación de vínculos (LAG). vMotion Wizard Compatibility muestra un mensaje de error similar al siguiente:

    La interfaz de red conectada actualmente 'Adaptador de red 1" usa la red 'DSwitchName', que no está accesible

    El problema está resuelto en esta versión.
  • Posible caída del canal de fibra en Ethernet (FCoE) al recopilar el paquete de registro de ESXi
    Al recopilar el paquete de registro de ESXi, el comando lldpnetmap habilita LLDP; sin embargo, LLDP solo se puede establecer en modo Ambos y los paquetes de LLDP se envían a través del host ESXi. Los paquetes podrían hacer que el vínculo de FCoE se desactive.

    El problema está resuelto en esta versión.
  • Registros de hostd desbordados con mensaje de error varias veces en sucesión rápida
    Los registros de hostd se desbordan con un mensaje de error similar al siguiente varias veces en sucesión rápida al completar los registros:

    Failed to get vsi stat set: Sysinfo error on operation returned status : Not found. Please see the VMkernel log for detailed error information.

    El problema está resuelto en esta versión.


Problemas de seguridad
  • Actualización del paquete de NTP
    El paquete de ESXi NTP se actualiza a la versión 4.2.8p4.

  • Actualización de la versión de zlib
    La versión de zlib se actualiza a la versión 1.2.8.

  • Actualización de la biblioteca libPNG
    La biblioteca libPNG se actualiza a libpng-1.6.20.

  • Actualización de la versión de OpenSSH
    La versión de OpenSSH se actualiza a la versión 7.1p1.

  • El proveedor de VASA de filtro de E/S no completa la inicialización debido a la falta de una línea nueva en un archivo de certificado
    El proveedor de VASA de filtro de E/S lee y combina los archivos de certificado y de clave privada para generar el archivo pem. Si el archivo de certificado no termina con una línea nueva, se crea un archivo pem no válido que OpenSSL no reconoce. A su vez, esto causa un error que impide la inicialización de iofiltervp.

    El problema está resuelto en esta versión.

Problemas con la configuración de servidores
  • No se pueden realizar operaciones de Active Directory después de unir el host ESXi a Active Directory
    Después de unir el host ESXi a Active Directory, es posible que no pueda realizar actividades de Active Directory como agregar usuarios de Active Directory para permiso después de una determinada incorporación de usuarios de diferentes dominios de confianza, inicio de sesión, etc. En el archivo /var/log/likewise.log, se verán entradas similares a las siguientes:

    20150522181259:DEBUG:lsass:LsaJoinDomain():join.c:380: Error code: 40286 (symbol: LW_ERROR_LDAP_SERVER_DOWN)

    El problema está resuelto en esta versión.

  • ID de PCI incorporados más recientemente
    El archivo pci.ids se actualizó y ahora contiene los ID de PCI más recientes.

  • El host ESXi no se mueve al modo de mantenimiento ante un error de asignación de grupo de recursos
    El host ESXi no se mueve al modo de mantenimiento ante un error de asignación de grupo de recursos.

    El problema está resuelto en esta versión.

Problemas de almacenamiento
  • ESXi mClock I/O Scheduler no funciona según lo esperado
    ESXi mClock I/O Scheduler no limita las E/S con una carga más baja incluso después de cambiar el IOPS de la máquina virtual mediante vSphere Client.

    El problema está resuelto en esta versión.

  • Actualización demorada del estado de ruta de los LUN existentes
    En algunas ocasiones, puede notar una leve demora en la actualización del estado de ruta de los LUN, dado que una API interna no emite la llamada de examen para los LUN existentes.

    El problema está resuelto en esta versión.

  • Los intentos de adjuntar más de un Appstack llevan mucho tiempo
    Cuando intenta adjuntar más de un Appstack o volumen que permite escritura a una máquina virtual, se produce una demora en la reconfiguración de la VM.

    El problema está resuelto en esta versión.

  • No se puede abrir un disco de más de 2 TB en Virtual Volumes con el modo de transporte HotAdd de VDDK
    Los intentos de usar el modo de transporte Virtual Disk Development Kit (VDDK) de HotAdd para HotAdd y abrir un disco de más de 2 TB en un almacén de datos de Virtual Volumes podría fallar.

    El problema está resuelto en esta versión.

  • Al instalar filtros de E/S en la configuración de IPv6, no se publican sus capacidades en VPXD
    Después de instalar correctamente el filtro de E/S mediante la API de la máquina virtual, el filtro instalado no puede publicar sus capacidades en VPXD. No se puede conectar el perfil de filtro en ningún disco, ya que no hay capacidades publicadas en la administración de almacenamiento basada en directivas (SPBM) de VMware vSphere.

    El problema está resuelto en esta versión.

  • ESXi 6.0 Update 2 admite las versiones de VMIOF 1.0 y 1.1

    ESXi 6.0 Update 2 admite las versiones de VMIOF 1.0 y 1.1. La etiqueta de VIB vmiof_1_1_0_0 se añadió a la lista de etiquetas de VIB admitidas en la imagen base de ESXi. Esto le permite crear filtros que son compatibles solo con ESXi 6.0 Update 2 y versiones posteriores, ya que los filtros creados en el kit de desarrollo de ESXi 6.0 Update 2 solo se instalarán en los hosts ESXi 6.0 Update 2 o versiones posteriores.

    Los filtros creados en ESXi 6.0 Update 2 también funcionarán con hosts ESXi 6.0 Update sin problema.

  • Después de actualizar los hosts de un clúster de Virtual SAN a ESXi 6.0 Update 1b, algunos hosts del clúster informan de advertencias falsas
    Después de actualizar el entorno de Virtual SAN a ESXi 6.0 Update 1b, vCenter Server informa de una advertencia falsa (similar a la que se muestra a continuación) en la pestaña Resumen en vSphere Web Client, mientras que el host de ESXi muestra un triángulo de notificación:

    Un host no puede comunicarse con todos los demás nodos en el clúster con el servicio Virtual SAN habilitado

    El problema está resuelto en esta versión.

Problemas de actualización e instalación
  • La instalación cifrada de ESXi 6.x advierte de forma incorrecta de que los medios USB o SD no admiten VMFS, incluso aunque el parámetro --novmfsondisk esté incluido en el archivo inicial
    Si usa la instalación cifrada para instalar ESXi 6.0 en un disco que se identifica como medio USB o SD, es posible que el instalador muestre el mensaje de advertencia:

    El disco (<disk-id>) especificado en la instalación no admite VMFS.

    Este mensaje se muestra aún si incluyó el parámetro --novmfsondisk para el comando de instalación en el archivo inicial.

    El problema está resuelto en esta versión.

  • El VIB directo podría no funcionar correctamente y perderse después de un reinicio
    Durante la instalación del VIB directo, se ejecutan complementos de jumpstart, scripts de RC y scripts de servicio del VIB directo. Estos complementos y scripts podrían generar errores y/o excepciones. Los errores y/o excepciones podrían detener el proceso de instalación y causar un comportamiento inesperado, como que el VIB directo se notifique como instalado en el sistema pero no funcione correctamente. Además, el VIB directo se pierde después de un reinicio.

    El problema está resuelto en esta versión.

  • La instalación del VIB directo podría fallar
    Durante la instalación del VIB directo, esximage crea datos intermedios para el VIB directo. Si ejecuta los comandos get y list del VIB del software esxcli al mismo tiempo, los datos intermedios podrían eliminarse y provocar que la transacción de la instalación del VIB directo genere un error.

    El problema está resuelto en esta versión.

  • Los intentos de realizar vMotion pueden generar errores después de actualizar desde ESXi 5.0 o 5.1 a 6.0 Update 1 y versiones posteriores

    Los intentos de realizar vMotion pueden generar errores después de actualizar desde ESXi 5.0 o 5.1 a 6.0 Update 1 y versiones posteriores. En el archivo vmware.log se escribe un mensaje de error parecido al siguiente:

    failed to add memory page 0x201 to VM: Bad parameter

    Para obtener información detallada, consulte el artículo 2143943 de la base de conocimientos.

    El problema está resuelto en esta versión.

Problemas en vCenter Server, vSphere Web Client y vSphere Client
  • No se puede abrir la conexión de la consola de VM con las VM encendidas de vSphere Web Access
    Cuando agrega un host ESXi con VM encendidas a vCenter Server o cuando cambia el host de un vCenter Server a otro, vSphere Web Access no puede abrir la conexión de la consola a las VM. Con este problema, se observa un mensaje de error similar al siguiente:

    Mensaje de error de la consola web:

    Se desconectó la consola. Cierre esta ventana y reinicie la consola para volver a conectarse.

    Mensaje de error de VMware Remote Console independiente:

    No se pudo inicializar la sesión de SSL en el host remoto.

    Mensaje de error de la consola de cliente de VI:

    No se puede conectar con mks: error interno

    Mensaje de error en el archivo vmware.log:

    SOCKET 6 (150) Error during authd-VNC negotiation: (1) Asyncsocket error.

    El problema está resuelto en esta versión.

Problemas en la administración de máquinas virtuales
  • Hostd deja de responder de forma aleatoria en hosts con aceleración 3D
    Hostd podría dejar de responder de forma aleatoria en hosts ESXi con aceleración 3D. En los registros de hostd se registran mensajes similares a los siguientes:

    Crash Report build=2809209
    Signal 11 received, si_code 1, si_errno 0
    Bad access at 34
    eip 0xnnnnnnn esp 0xnnnnnnnn ebp 0xnnnnnnnn
    eax 0xnnnnnnnn ebx 0xnnnnnnn ecx 0x47 edx 0x0 esi 0x30 edi 0xnnnnnnnn
    El problema está resuelto en esta versión.

  • Las máquinas virtuales afectadas por pérdida permanente de dispositivos no realizan conmutación por error
    Las máquinas virtuales afectadas por pérdida permanente de dispositivos (PDL) no se encienden en un host de conmutación por error. La VM se queda en un estado no válido con un mensaje de advertencia que indica que la versión de hardware 1 no se reconoce cuando hay una PDL de cualquiera de las VM que alojan almacenamiento.

    El problema está resuelto en esta versión.

  • El contador de rendimiento cpu.system.summation de una VM siempre se muestra como 0
    Las métricas de rendimiento de máquinas virtuales no se muestran correctamente porque el contador de rendimiento cpu.system.summation de una VM siempre se muestra como 0.

    El problema está resuelto en esta versión.

Problemas de vMotion y Storage vMotion
  • Hostd podría dejar de responder cuando el host ESXi con hardware 3D se coloca en modo de mantenimiento y se activa vMotion
    En un host ESXi que tiene hardware 3D, cuando hostd detecta un cambio de estado de energía de una VM, se llama a una función para comprobar el estado de la VM. En el caso de vMotion, la VM de origen se apaga antes de que se anule el registro en el host de origen, se muestra la excepción ManagedObjectNotFound y hostd podría dejar de responder.

    El problema está resuelto en esta versión.

  • No se puede realizar vMotion con VM que tengan dos discos virtuales de 2 TB
    Los intentos de realizar vMotion con máquinas virtuales ESXi 6.0 que tienen discos virtuales de 2 TB creados en ESXi 5.0 fallan con mensajes de error similares al siguiente, registrados en el archivo vpxd.log:

    2015-09-28T10:00:28.721+09:00 info vpxd[xxxxx] [Originator@6876 sub=vpxLro opID=xxxxxxxx-xxxxxxxx-xx] [VpxLRO] -- BEGIN task-919 -- vm-281 -- vim.VirtualMachine.relocate -- xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx(xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
    2015-09-28T10:00:28.727+09:00 info vpxd[xxxxx] [Originator@6876 sub=vpxLro opID=xxxxxxxx-xxxxxxxx-xx-xx] [VpxLRO] -- BEGIN task-internal-343729 -- -- VmprovWorkflow --
    ....

    El problema está resuelto en esta versión.

  • La máquina virtual deja de responder o pasa a estado apagado durante vMotion de almacenamiento en disco únicamente
    Cuando realiza vMotion de almacenamiento en disco únicamente, la VM podría dejar de responder o pasar a estado apagado porque varios subprocesos intentan acceder a los mismos datos.

    El problema está resuelto en esta versión.

Problemas de VMware Tools

Problemas conocidos

Los problemas conocidos en ESXi 6.0 se agrupan de la siguiente forma:

Los nuevos problemas conocidos que se documentan en esta versión se resaltan con la frase Nuevo problema.

Problemas de instalación
  • Se puede conservar el sufijo DNS incluso después de cambiar la configuración predeterminada en la DCUI
    Un host ESXi se puede configurar de manera automática con el DNS y el sufijo DNS predeterminados durante el primer arranque si se implementa en una red con un servidor DHCP. Sin embargo, al intentar cambiar el sufijo DNS, la DCUI no quita el sufijo DNS existente, sino que añade también el nuevo sufijo que se proporcionó.

    Solución alternativa: Al configurar el nombre de host de DNS del OVF testigo, defina FQDN COMPLETO en el campo Nombre de host de DNS para utilizar el sufijo DNS correcto. A continuación, puede quitar los sufijos DNS no deseados en el campo Sufijos DNS personalizados.

  • Puede que los procesos de usuario del servicio VMware Tools no se ejecuten en el sistema operativo Linux después de instalar el paquete de VMware Tools más reciente
    En los sistemas operativos Linux pueden surgir problemas de actualización e instalación de VMware Tools; también es posible que los procesos de usuario de servicio (vmtoolsd) de VMware Tools no se ejecuten después de instalar el paquete de VMware Tools más reciente. Este problema ocurre si la versión de blibc es anterior a la versión 2.5, como SLES10sp4.

    Solución alternativa: Actualice la biblioteca glibc de Linux a la versión 2.5 o posterior.

Problemas de actualización

Revise también la sección Problemas de instalación, en las notas de la versión. Muchos problemas de instalación pueden afectar el proceso de actualización.

  • Nuevo problema No se puede actualizar desde ESXi 6.x a 6.0 Update 2 con el comando "esxcli software vib update"
    El intento de actualizar ESXi 6.x a 6.0 Update 2 con esxcli software vib update genera un mensaje de error similar al siguiente:

    "[DependencyError]
    VIB VMware_bootbank_esx-base_6.0.0-2.34.xxxxxxx requires vsan << 6.0.0-2.35, but the requirement cannot be satisfied within the ImageProfile.
    VIB VMware_bootbank_esx-base_6.0.0-2.34.xxxxxxx requires vsan >= 6.0.0-2.34, but the requirement cannot be satisfied within the ImageProfile."


    Este problema se debe a la introducción de un nuevo VIB de Virtual SAN que es interdependiente con el VIB esx-base y el comando esxcli software vib update solo actualiza los VIB ya instalados en el sistema.

    Solución alternativa: Para solucionar este problema, ejecute esxcli software profile update como se muestra en el siguiente ejemplo:

    esxcli software profile update -d /vmfs/volumes/datastore1/update-from-esxi6.0-6.0_update02.zip -p ESXi-6.0.0-20160302001-standard

  • Nuevo problema Es posible que se produzcan errores al intentar actualizar ESXi si la tabla de particiones ESXi contiene una partición coredump
    Al implementar ESXi en una tarjeta SD con el comando "dd" (implementar ESXi con la imagen .dd creada mediante el comando esxiso2dd proporcionado por VMware), ESXi crea una partición coredump como segunda partición durante el primer arranque. Como resultado, se produce un error en la actualización de ESXi.

    Solución alternativa: Para solucionar este problema, debe quitar la segunda partición coredump manualmente. Consulte el artículo 2144074 de la base de conocimientos.

  • Novedad SSLv3 permanece habilitado en Auto Deploy después de actualizar de una versión anterior de vSphere 6.0 a vSphere 6.0 Update 1 y versiones superiores
    Cuando se actualiza de una versión anterior de vSphere 6.0 a vSphere 6.0 Update 1 y versiones superiores, el protocolo SSLv3 permanece habilitado en Auto Deploy.

    Solución alternativa: Realice los siguientes pasos para deshabilitar SSLv3 mediante comandos de PowerCLI:

    1. Ejecute el siguiente comando para conectarse a vCenter Server:

      PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Connect-VIServer -Server <FQDN_hostname or IP Address of vCenter Server>

    2. Ejecute el siguiente comando para comprobar el estado actual de SSLv3:

      PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Get-DeployOption

    3. Ejecute el siguiente comando para deshabilitar SSLv3:

      PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> Set-DeployOption disable-sslv3 1

    4. Reinicie el servicio Auto Deploy para actualizar el cambio.

  • El número de dispositivo adaptador de bus host de canal de fibra puede cambiar después de actualizar ESXi de la versión 5.5.x a la 6.0

    Durante la actualización de ESXi de la versión 5.5.x a la 6.0, cambia el número de dispositivo adaptador de bus host de canal de fibra en algunos casos. El número de dispositivo puede cambiar por otro si se utiliza el comando esxcli storage core adapter list.

    Por ejemplo, los números de dispositivo de un adaptador de bus host de canal de fibra pueden verse así antes de la actualización de ESXi:

    Nombre de HBA
    ––––––––
    vmhba3
    vmhba4
    vmhba5
    vmhba66

    Los números de dispositivo adaptador de bus host de canal de fibra pueden verse así después de la actualización de ESXi a la versión 6.0:

    Nombre de HBA
    ––––––––
    vmhba64
    vmhba65
    vmhba5
    vmhba6

    El ejemplo ilustra el cambio aleatorio que puede producirse al utilizar el comando esxcli storage core adapter list: los números de alias de los dispositivos vmhba2 y vmhba3 cambian a vmhba64 y vmhba65, en tanto que los números de los dispositivos vmhba5 y vmhba6 no cambian. No obstante, si se utilizó el comando esxcli hardware pci list, los números del dispositivo no cambian después de la actualización.

    Este problema es externo a VMware y es posible que no lo afecte. ESXi muestra los nombres de alias de los dispositivos, pero no los utiliza para ninguna operación. Se puede utilizar el perfil de host para restablecer el nombre de alias de un dispositivo. Consulte la documentación de productos VMware y los artículos de la base de conocimientos.

    Solución alternativa: Ninguna.

  • La configuración de Active Directory no continúa después de la actualización
    La configuración de Active Directory establecida en el host ESXi antes de la actualización no se mantiene cuando el host se actualiza a la versión ESXi 6.0.

    Solución alternativa: Agregue el host al dominio de Active Directory después de actualizar si la versión de ESXi previa a la actualización es 5.1 o posterior. No agregue el host al dominio de Active Directory después de actualizar si la versión de ESXi previa a la actualización es ESXi 5.0.x.

  • Después de actualizar ESXi a la versión 6.0, los hosts que se habían agregado al dominio ya no están unidos a este
    Cuando se actualiza de vSphere 5.5 a vSphere 6.0 por primera vez, la configuración de Active Directory no se mantiene.

    Solución alternativa: Después de actualizar, vuelva a unir los hosts al dominio de vCenter Server:

    1. Agregue los hosts a vCenter Server.

    2. Una los hosts al dominio (por ejemplo, ejemplo.com).

    3. Actualice todos los hosts a ESXi 6.0.

    4. Una manualmente al dominio un host actualizado recientemente.

    5. Extraiga el perfil de host y deshabilite todos los otros perfiles, excepto el de autenticación.

    6. Aplique el perfil de host unido manualmente a los otros hosts actualizados recientemente.

  • El servicio VMware ESXi Dump Collector que estaba en ejecución anteriormente se restablece al valor Deshabilitado predeterminado después de actualizar vCenter Server para Windows
    El proceso de actualización instala VMware Vsphere ESXi Dump Collector 6.0 como parte de un grupo de servicios opcionales para vCenter Server. Se debe habilitar manualmente el servicio VMware vSphere ESXi Dump Collector para utilizarlo como parte de vCenter Server 6.0 para Windows.

    Solución alternativa: Lea la documentación de VMware o realice una búsqueda en la base de conocimientos de VMware para obtener información sobre cómo habilitar y ejecutar servicios opcionales en vCenter Server 6.0 para Windows.

    Habilite el servicio VMware vSphere ESXi Dump Collector en el sistema operativo:

    1. En el menú Panel de control, seleccione Herramientas administrativas y haga doble clic en Servicios.

    2. Haga clic con el botón derecho en VMware vSphere ESXi Dump Collector y en Editar tipo de inicio.

    3. Establezca la opción Tipo de inicio en Automático.

    4. Haga clic con el botón derecho en VMware vSphere ESXi Dump Collector y en Inicio.

    La opción Tipo de inicio del servicio se establece en modo automático y el servicio aparece en estado de ejecución.

Problemas con vCenter Single Sign-On y la administración de certificados
  • No es posible conectarse a la consola de la máquina virtual después de actualizar el certificado SSL del host ESXi.
    Puede producirse un error en la validación del certificado si se actualiza el certificado SSL que utiliza un host ESXi y, a continuación, se intenta conectarse a la consola de la máquina virtual de alguna máquina virtual que estaba en ejecución cuando se reemplazó el certificado. Esto se debe a que el certificado antiguo se almacena en la memoria caché y toda conexión nueva con la consola se rechaza debido a la falta de coincidencia.
    La conexión con la consola puede realizarse correctamente (aunque no está garantizado) si, por ejemplo, el certificado antiguo se valida por otros medios. Las conexiones actuales con la consola de la máquina virtual no se ven afectadas. No obstante, pueden surgir inconvenientes si la consola estaba en ejecución durante el reemplazo del certificado y, a continuación, se la detuvo y después se la reinició.

    Solución alternativa: Coloque el host en el modo de mantenimiento, o bien suspenda o apague todas las máquinas virtuales. Solo se verán afectadas las máquinas virtuales en ejecución. Se recomienda realizar todas las actualizaciones de certificados SSL después de colocar el host en el modo de mantenimiento.

Problemas de redes

  • Ciertas funcionalidades de vSphere no admiten IPv6
    Se puede habilitar IPv6 para todos los nodos y componentes, excepto en las siguientes características:

    • Direcciones IPv6 para hosts ESXi y vCenter Server que no fueron asignadas a nombres de dominio completo (FQDN) en el servidor DNS.
      Solución alternativa: Utilice los FQDN o asegúrese de que las direcciones IPv6 se asignen a FQDN en los servidores DNS para realizar una búsqueda inversa de nombres.

    • Volúmenes virtuales

    • Arranque PXE como parte de Auto Deploy y de perfiles de host
      Solución alternativa: Realice un arranque PXE de un host ESXi en IPv4 y configure el host para IPv6 mediante los perfiles de host.

    • Conexión de hosts ESXi y de vCenter Server Appliance en Active Directory
      Solución alternativa: Utilice Active Directory en LDAP como origen de identidad en vCenter Single Sign-On.

    • Almacenamiento NFS 4.1 con Kerberos
      Solución alternativa: Utilice NFS 4.1 con AUTH_SYS.

    • Authentication Proxy

    • Conexión de vSphere Management Assistant y vSphere Command-Line Interface con Active Directory.
      Solución alternativa: Conéctese a Active Directory en LDAP.

    • Uso de vSphere Client para habilitar IPv6 en características de vSphere
      Solución alternativa: Utilice vSphere Web Client para habilitar IPv6 en características de vSphere.

  • Aviso importante recursivo durante el uso de ESXi Dump Collector
    Puede aparecer un aviso importante recursivo sobre el kernel cuando el host está en estado de pánico mientras muestra una pantalla de diagnóstico de color púrpura y escribe el volcado de núcleo en la red conectada a ESXi Dump Collector. Es posible que no haya disponible un archivo zdump para el VMkernel que permita solucionar los problemas de ESXi Dump Collector en vCenter Server.

    Si aparece un aviso importante recursivo sobre el kernel, la pantalla de diagnóstico de color púrpura en el host muestra el siguiente mensaje:
    2014-09-06T01:59:13.972Z cpu6:38776)Starting network coredump from host_ip_address to esxi_dump_collector_ip_address.
    [7m2014-09-06T01:59:13.980Z cpu6:38776)WARNING: Net: 1677: Check what type of stack we are running on [0m
    Recursive panic on same CPU (cpu 6, world 38776, depth 1): ip=0x418000876a27 randomOff=0x800000:
    #GP Exception 13 in world 38776:vsish @ 0x418000f0eeec
    Secondary panic trap frame registers:
    RAX:0x0002000001230121 RCX:0x000043917bc1af80 RDX:0x00004180009d5fb8 RBX:0x000043917bc1aef0
    RSP:0x000043917bc1aee8 RBP:0x000043917bc1af70 RSI:0x0002000001230119 RDI:0x0002000001230121
    R8: 0x0000000000000038 R9: 0x0000000000000040 R10:0x0000000000010000 R11:0x0000000000000000
    R12:0x00004304f36b0260 R13:0x00004304f36add28 R14:0x000043917bc1af20 R15:0x000043917bc1afd0
    CS: 0x4010 SS: 0x0000 FS: 0x4018 GS: 0x4018 IP: 0x0000418000f0eeec RFG:0x0000000000010006
    2014-09-06T01:59:14.047Z cpu6:38776)Backtrace for current CPU #6, worldID=38776, rbp=0x43917bc1af70
    2014-09-06T01:59:14.056Z cpu6:38776)0x43917bc1aee8:[0x418000f0eeec]do_free_skb@com.vmware.driverAPI#9.2+0x4 stack: 0x0, 0x43a18b4a5880,
    2014-09-06T01:59:14.068Z cpu6:38776)Recursive panic on same CPU (cpu 6, world 38776): ip=0x418000876a27 randomOff=0x800000:
    #GP Exception 13 in world 38776:vsish @ 0x418000f0eeec
    Halt$Si0n5g# PbC8PU 7.

    Puede aparecer un aviso importante recursivo sobre el kernel cuando el VMkernel entra en estado de pánico durante la transferencia de gran cantidad de tráfico a través del adaptador de red físico, que también está configurado para enviar los volcados de núcleo al recopilador de vCenter Server.

    Solución alternativa: Elija alguna de las siguientes alternativas:

    • Dedique un adaptador de red físico a la transmisión de volcado de núcleo únicamente para reducir el impacto del tráfico del sistema y la máquina virtual.

    • Deshabilite ESXi Dump Collector en el host; para ello, ejecute el siguiente comando de la consola ESXCLI:
      esxcli system coredump network set --enable false

Problemas de almacenamiento

Problemas con la versión 4.1 de NFS

  • Las máquinas virtuales de un almacén de datos de NFS 4.1 pueden presentar errores cuando el recurso compartido de NFS 4.1 se recupera del estado de todas las rutas de acceso inactivas (APD)
    Cuando el almacenamiento de NFS 4.1 ingresa en el estado APD y, a continuación, sale de ese estado tras un período de gracia, se produce un error en las máquinas virtuales que se están ejecutando en el almacén de datos de NFS 4.1. El período de gracia depende del proveedor de la matriz.
    Una vez que el recurso compartido NFS 4.1 se recuperó del estado APD, aparece el siguiente mensaje en la página de resumen de la máquina virtual en vSphere Web Client:
    Se perdió el bloqueo que protege a VM.vmdk, posiblemente debido a problemas de almacenamiento subyacentes. Si esta máquina virtual se configuró para alta disponibilidad, asegúrese de que esté ejecutándose en algún otro host antes de hacer clic en Aceptar.
    Después de hacer clic en Aceptar, se generan archivos de bloqueo y se apaga la máquina virtual.

    Solución alternativa: Ninguna.

  • El cliente NFS 4.1 pierde sincronización con el servidor al intentar crear nuevas sesiones
    Después de un período de conectividad interrumpida con el servidor, el cliente NFS 4.1 puede perder la sincronización con el servidor al intentar crear nuevas sesiones. Cuando esto ocurre, el archivo vmkernel.log contiene una serie limitada de mensajes de advertencia en los cuales se indica que en la solicitud de NFS41 CREATE_SESSION hubo un error de tipo NFS4ERR_SEQ_MISORDERED.

    Solución alternativa: Realice la siguiente secuencia de pasos.

    1. Intente desmontar los sistemas de archivos afectados. Si no hay archivos abiertos al desmontarlos, la operación se completa correctamente y el módulo de cliente NFS limpia el estado interno. Se pueden volver a montar los sistemas de archivos desmontados y reanudar el funcionamiento normal.

    2. Apague las NIC conectadas a las direcciones IP de los montajes y déjelas en ese estado hasta que caduquen los tiempos de concesión de varios servidores. Cinco minutos deberían ser suficientes. A continuación, podrá volver a encender las NIC. Debería reanudarse el funcionamiento normal.

    3. Si los pasos anteriores no funcionan, reinicie el host ESXi.

  • El cliente NFS 4.1 pierde sincronización con un servidor NFS y no se puede recuperar la conexión cuando se restablece la sesión
    Después de un período de conectividad interrumpida con el servidor, el cliente NFS 4.1 puede perder la sincronización con el servidor y no es posible recuperar la conexión sincronizada con el servidor aunque se restablezca la sesión. Este problema se debe a un problema con el servidor VNX de EMC. Cuando ocurre esto, el archivo vmkernel.log contiene una serie limitada de mensajes de advertencia en los que se indica lo siguiente sobre NFS41: NFS41ProcessSessionUp:2111: resetting session with mismatched clientID; probable server bug

    Solución alternativa: Para finalizar la sesión, desmonte los almacenes de datos y, a continuación, vuelva a montarlos.

  • Los volúmenes ONTAP Kerberos dejan de estar accesibles o tienen errores de E/S en las máquinas virtuales
    Un servidor NetApp no responde cuando recibe solicitudes de RPCSEC_GSS que llegan fuera de secuencia. Como resultado, la correspondiente operación de E/S se detiene a menos que se la finalice y el sistema operativo invitado puede detener o encontrar los errores de E/S. Asimismo, de acuerdo con RFC 2203, el cliente solo puede tener una cantidad de solicitudes pendientes igual a seq_window (32 en el caso de ONTAP), según el contexto de RPCSEC_GSS, y debe esperar hasta que el servidor complete la solicitud pendiente más baja. Por lo tanto, el servidor nunca responde a la solicitud de RPCSEC_GSS fuera de secuencia y el cliente deja de enviar solicitudes al servidor una vez alcanzada la cantidad máxima seq_window de solicitudes pendientes. Esto hace que el volumen deje de estar accesible.

    Solución alternativa: Ninguna. Compruebe la lista de compatibilidad de hardware (HCL) más reciente para encontrar un servidor ONTAP compatible que haya resuelto el problema.

  • No se puede crear un disco virtual mayor de 1 TB en el almacén de datos NFS 4.1 de EMC VNX
    El almacenamiento NFS versión 4.1 de EMC VNX con firmware versión 7.x admite solamente formatos de archivo de 32 bits. Esto impide crear archivos de máquina virtual mayores de 1 TB en el almacén de datos NFS 4.1.

    Solución alternativa: Actualice la matriz EMC VNX a la versión 8.x.

  • Los almacenes de datos NFS 4.1 respaldados por el almacenamiento EMC VNX dejan de estar accesibles durante las actualizaciones del firmware
    Cuando se actualiza el almacenamiento EMC VNX con un nuevo firmware, los almacenes de datos NFS 4.1 montados en el host ESXi dejan de estar accesibles. Esto ocurre porque el servidor VNX cambia el número de dispositivo principal después de actualizado el firmware. El cliente NFS 4.1 del host no espera que cambie el número principal una vez que estableció la conectividad con el servidor, por lo cual provoca que los almacenes de datos queden permanentemente inaccesibles.

    Solución alternativa: Desmonte todos los almacenes de datos NFS 4.1 que exportó el servidor VNX antes de actualizar el firmware.

  • Cuando los hosts ESXi utilizan diferentes mecanismos de seguridad para montar el mismo almacén de datos NFS 4.1, pueden producirse errores en las máquinas virtuales
    Si diferentes hosts ESXi montan el mismo almacén de datos NFS 4.1 mediante distintos mecanismos de seguridad (AUTH_SYS y Kerberos), las máquinas virtuales de este almacén de datos pueden tener problemas y errores. Por ejemplo, al intentar migrar las máquinas virtuales del host 1 al host 2, pueden ocurrir errores de permiso denegado. También se pueden presentar estos errores al intentar acceder a la máquina virtual del host 1 desde el host 2.

    Solución alternativa: Asegúrese de que todos los hosts que monten un volumen NFS 4.1 utilicen el mismo tipo de seguridad.

  • Se produce un error al intentar copiar archivos de solo lectura en el almacén de datos NFS 4.1 con Kerberos
    El error puede ocurrir cuando se intentan copiar datos de un archivo de origen a un archivo de destino. El archivo de destino queda vacío.

    Solución alternativa: Ninguna.

  • No se garantiza la uniformidad en los tipos de seguridad de NFS 4.1 al crear un clúster de almacenes de datos
    Cuando se crea un clúster de almacenes de datos, vSphere no comprueba ni aplica la uniformidad de los tipos de seguridad de NFS 4.1. Como consecuencia, pueden formar parte del mismo clúster almacenes de datos que utilizan distintos tipos de seguridad (AUTH_SYS y Kerberos). Si se migra una máquina virtual de un almacén de datos con Kerberos a uno con AUTH_SYS, el nivel de seguridad de la máquina virtual se vuelve más bajo.
    Este problema ocurre en funcionalidades como vMotion, Storage vMotion, DRS y Storage DRS.

    Solución alternativa: Si las máquinas virtuales requieren el tipo de seguridad Kerberos, asegúrese de que todos los volúmenes de NFS 4.1 que integran el mismo clúster utilicen solamente el tipo de seguridad Kerberos. No incluya almacenes de datos NFS 3, ya que NFS 3 solo admite AUTH_SYS.

Problemas de Virtual Volumes

  • Se produce un error al crear almacenes de datos virtuales porque el proveedor VASA de Virtual Volumes utilizó el certificado incorrecto
    Algunas veces, un certificado autofirmado utilizado por el proveedor VASA de Virtual Volumes puede definir incorrectamente la extensión de KeyUsage como crítica sin configurar el bit keyCertSign. En este caso, el registro del proveedor se realiza correctamente. No obstante, no se puede crear un almacén de datos virtual a partir de contenedores de almacenamiento informados por el proveedor VASA.

    Solución alternativa: El certificado autofirmado utilizado por el proveedor VASA en el momento del registro del proveedor no debe definir la extensión KeyUsage como crítica sin configurar el bit keyCertSign.

Problemas de almacenamiento generales

  • Nuevo problema Los hosts de ESXi 6.0 Update 2 conectados a ciertas matrices de almacenamiento con una versión concreta del firmware podrían experimentar tiempos de espera de E/S y cancelaciones posteriores
    Cuando los hosts de ESXi 6.0 Update 2 conectados a ciertas matrices de almacenamiento con una versión concreta del firmware envían solicitudes de datos SMART a la matriz de almacenamiento, y si la matriz responde con un error de PDL, el comportamiento de la respuesta de PDL en 6.0 Update 2 podría dar lugar a una condición donde estos comandos erróneos se reintentasen continuamente, bloqueando así otros comandos. Este error provoca tiempos de espera de E/S e interrupciones generalizados.

    Además, los hosts de ESXi podrían tardar bastante en volver a conectarse a vCenter Server tras el reinicio, o los hosts podrían pasar al estado No responde en vCenter Server. Las tareas relacionadas con el almacenamiento, como volver a analizar el HBA, podrían tardar mucho en finalizar.

    Solución alternativa: Para resolver este problema, consulte el artículo 2133286 de la base de conocimientos.

  • vSphere Web Client muestra incorrectamente la directiva de almacenamiento como asociada al crear una nueva máquina virtual a partir de un disco existente
    Cuando se utiliza vSphere Web Client para crear una nueva máquina virtual a partir de un disco existente y se especifica una directiva de almacenamiento al configurar el disco. El filtro aparece como asociado cuando se selecciona una nueva máquina virtual --> se hace clic en Directivas de máquina virtual --> Editar directivas de almacenamiento de máquina virtual. Sin embargo, el filtro efectivamente no está asociado. Puede revisar el archivo .vmdk o vmkfstools --iofilterslist <vmdk-file>' para comprobar si el filtro está asociado o no.

    Solución alternativa: Después de crear la nueva máquina virtual, pero antes de encenderla, agregue el filtro al archivo vmdk. Para ello, haga clic en Directivas de máquina virtual --> Editar directivas de almacenamiento de máquina virtual.

  • La operación Lookup de NFS devuelve errores NFS STALE
    Cuando implementa un gran número de máquinas virtuales en el almacén de datos de NFS, la implementación de la máquina virtual da error con un mensaje parecido al siguiente debido a una condición de carrera:

    Administrar archivo NFS obsoleto

    Solución alternativa: Reinicie la operación Lookup. Consulte el artículo 2130593 de la base de conocimientos para obtener más detalles.

  • Se produce un error al intentar crear un almacén de datos de VMFS en los LUN de Dell EqualLogic cuando se utilizan adaptadores de iSCSI QLogic
    No se puede crear un almacén de datos de VMFS en un dispositivo de almacenamiento Dell EqualLogic que se detecta mediante adaptadores de iSCSI QLogic.
    Cuando los intentos fallan, aparece el siguiente mensaje de error en vCenter Server: No se puede crear Filesystem; consulte el registro de VMkernel para ver más detalles: se agotó el tiempo de espera para la conexión. El registro del VMkernel contiene mensajes continuos de iscsi session blocked e iscsi session unblocked. En la matriz de almacenamiento Dell EqualLogic, los registros de supervisión muestran el mensaje protocol error in packet received from the initiator para los nombres IQN del iniciador QLogic.

    Este problema se observa con el uso de los siguientes componentes:

    • Firmware de la matriz Dell EqualLogic: V6.0.7

    • Versiones de firmware del adaptador de iSCSI QLogic: 3.00.01.75

    • Versión del controlador: 5.01.03.2-7vmw-debug

    Solución alternativa: Habilite el parámetro del adaptador para Datos inmediatos de iSCSI en el adaptador de iSCSI QLogic. De forma predeterminada, el parámetro está desactivado. No se puede cambiar el parámetro desde vSphere Web Client o con los comandos esxcli. Para cambiarlo, utilice el software proporcionado por el proveedor, como QConvergeConsole CLI.

  • Error de arranque del host ESXi con HBA Emulex OneConnect
    Cuando un host ESXi tiene instalado HBA Emulex OneConnect, es posible que el host no arranque. Este error se debe a un problema con el firmware de Emulex.

    Solución alternativa: Para solucionarlo, póngase en contacto con Emulex para recibir el firmware más reciente para el HBA.

    Si continúa utilizando el firmware anterior, siga estos pasos para evitar errores en el arranque:

    1. Cuando ESXi se está cargando, presione Shift+O antes de iniciar el kernel ESXi.

    2. Deje la opción de arranque actual como está y agregue un espacio seguido de dmaMapperPolicy=false.

  • Flash Read Cache no acelera las operaciones de E/S durante APD
    Cuando el disco flash configurado como recurso flash virtual para Flash Read Cache resulta defectuoso o no accesible, o bien cuando desde el host no puede accederse al almacenamiento del disco, las instancias de Flash Read Cache del host no son válidas y no aceleran las operaciones de E/S. Como resultado, las memorias caché no aportan datos obsoletos cuando se restablece la conectividad entre el host y el almacenamiento. El corte de conectividad puede ser temporal (una condición de todas las rutas de acceso inactivas [APD]), o bien puede ser permanente (pérdida permanente del dispositivo [PDL]). Esta condición persiste hasta que la máquina virtual se reinicia.

    Solución alternativa: La máquina virtual puede reiniciarse para restaurar la aceleración de las operaciones de E/S mediante Flash Read Cache.

  • Todas las rutas de acceso inactivas (APD) o la conmutación por error de las rutas pueden provocar errores en el sistema
    En un entorno de SAS compartido, las situaciones de APD o de conmutación por error de las rutas pueden provocar errores en el sistema si el controlador lsi_msgpt3 reclama los discos y estos tienen una actividad de E/S intensa.

    Solución alternativa: Ninguna

  • El uso frecuente de comandos de cancelación de SCSI puede provocar errores en el sistema
    Con una actividad intensa de E/S, el uso frecuente de los comandos de cancelación de SCSI puede hacer que la controladora MegaRAID proporcione una respuesta muy lenta. Puede ocurrir un error si se produce una interrupción inesperada en las referencias de recursos que ya se habían publicado en un contexto anterior.

    Solución alternativa: Ninguna

  • Las conexiones de iSCSI tienen errores y los almacenes de datos dejan de estar accesibles cuando cambia IQN
    Este problema puede ocurrir si se cambia el IQN de un adaptador de iSCSI mientras las sesiones iSCSI del adaptador siguen activas.

    Solución alternativa: Cuando se cambia el IQN de un adaptador de iSCSI, no debe haber ninguna sesión activa en ese adaptador. Cierre todas las sesiones iSCSI y todos los destinos del adaptador antes de cambiar el IQN.

  • No se aplican siempre las operaciones en línea y sin conexión de nvmecli
    Cuando se realiza la operación nvmecli device online -A vmhba* para poner al dispositivo NVMe en línea, la operación parece funcionar. Sin embargo, el dispositivo puede permanecer en estado sin conexión.

    Solución alternativa: Compruebe el estado de los dispositivos NVMe mediante la ejecución del comando nvmecli device list.

Problemas con la configuración de servidores
  • La corrección tiene errores cuando se aplica un perfil de host desde un host con estado a un host aprovisionado con Auto Deploy
    Cuando se aplica un perfil de host desde un host implementado con estado a un host aprovisionado con Auto Deploy (sin estado) y sin almacenamiento local, aparece uno de los siguientes mensajes de error durante el intento de corrección:

    • El dispositivo vmhba en la dirección de bus PCI sxxxxxxxx.xx no está presente en el host. Debe apagar el dispositivo y, a continuación, insertar una tarjeta en la ranura PCI yy. El tipo de tarjeta debe coincidir exactamente con el del host de referencia.

    • No se encontró una partición de volcado de núcleo válida.

    Solución alternativa: Deshabilite el complemento que está causando el problema (por ejemplo, la configuración de alias de dispositivo o la configuración de volcado de núcleo) en el perfil de host y, a continuación, corrija el perfil de host.

  • Error de cumplimiento al aplicar el perfil de host con IP estática a un host
    Si se extrae un perfil de host de un host con configuración de red DHCP y, a continuación, se edita ese perfil con una dirección IP estática, aparece el siguiente mensaje de error de cumplimiento cuando se aplica el perfil a otro host:

    No coincide la cantidad de rutas de IPv4.

    Solución alternativa: Antes de extraer el perfil de host del host DHCP, configure el host para que tenga una dirección IP estática.

  • La máquina virtual puede apagarse cuando se agrega en caliente un adaptador de red virtual con recursos de red sobrecomprometidos
    En un conmutador vSphere Distributed Switch que tiene habilitado Network I/O Control, se configura una máquina virtual encendida con una reserva de ancho de banda conforme a la reserva para el tráfico de sistema de la máquina virtual en el adaptador de red físico del host. Se agrega en caliente un adaptador de red a la reserva de ancho de banda de red de la configuración de la máquina virtual que está por encima del ancho de banda disponible en los adaptadores de red físicos del host.

    Cuando se agrega en caliente el adaptador de red, el VMkernel inicia un proceso de suspensión y reanudación rápido (FSR). Como la máquina virtual solicita más recursos de red que los que hay disponibles, el VMkernel ejecuta la ruta de error del proceso FSR. Un error en esta ruta de error hace que la máquina virtual se apague.

    Solución alternativa: No configure la reserva de ancho de banda al agregar un adaptador de red a una máquina virtual encendida.

Problemas con VMware HA y Fault Tolerance
  • Incompatibilidad de Fault Tolerance (FT) heredado con plataformas Intel Skylake-DT/S, Broadwell-EP, Broadwell-DT y Broadwell-DE
    FT heredado no es compatible con las plataformas Intel Skylake-DT/S, Broadwell-EP, Broadwell-DT y Broadwell-DE. Los intentos de encender una máquina virtual tienen errores después de habilitar Fault Tolerance heredado de procesador único.

    Solución alternativa: Ninguna.

Problemas con los sistemas operativos invitados
  • Después de una conexión en caliente, los intentos de habilitar el modo de acceso directo en los dispositivos NVMe PCIe SSD pueden generar errores
    Para habilitar el modo de acceso directo en un dispositivo SSD desde vSphere Web Client, seleccione un host, haga clic en la pestaña Administrar y en Configuración; desplácese hasta la sección Hardware y haga clic en Dispositivos PCI > Editar. A continuación, seleccione un dispositivo de la lista de dispositivos activos que pueden habilitarse para el modo directo y haga clic en Aceptar. No obstante, cuando conecte en caliente un nuevo dispositivo NVMe a un host ESXi 6.0 que no tiene la unidad PCIe NVMe, el nuevo dispositivo NVMe PCIe SSD no podrá habilitarse para el modo de acceso directo y no aparecerá la lista de dispositivos disponibles para el acceso directo.

    Solución alternativa: Reinicie el host. También puede ejecutar el comando en el host ESXi.

    1. Inicie sesión como usuario raíz.

    2. Ejecute el comando
      /etc/init.d/hostd start

Problemas de hardware compatible
  • Al ejecutar esxcli para obtener la ubicación del disco, el resultado no es correcto en las controladoras Avago de los servidores HP.

    Cuando ejecuta el comando esxcli storage core device physical get en una controladora Avago o un servidor HP, el resultado no es correcto.

    Por ejemplo, si ejecuta:
    esxcli storage core device physical get -d naa.5000c5004d1a0e76
    El sistema devuelve:
    Physical Location: enclosure 0, slot 0

    La etiqueta real de esa ranura en el servidor físico es 1.

    Solución alternativa: Revise con cuidado la etiqueta del servidor HP. Como los números de ranura del servidor HP empiezan por 1, deberá aumentar el número de ranura que devuelve el comando para obtener el resultado correcto.

Problemas con el CIM y las API
  • Se puede producir un error en el parámetro sfcb-vmware_raw
    El parámetro sfcb-vmware_raw podría dar error cuando la memoria máxima asignada al grupo de recursos predeterminado del complemento no es suficiente.

    Solución alternativa: Agregue UserVars CIMOemPluginsRPMemMax para los límites de memoria de complementos sfcbd que utilizan el siguiente comando; a continuación, reinicie sfcbd para que se apliquen los nuevos valores del complemento:

    esxcfg-advcfg -A CIMOemPluginsRPMemMax --add-desc 'Maximum Memory for plugins RP' --add-default XXX --add-type int --add-min 175 --add-max 500

    Donde XXX es el límite de memoria que se desea asignar. Este valor debe encontrarse entre los valores mínimos (175) y máximos (500).