Notas de la versión de VMware ESXi 6.0 Update 3a

|

ESXi 6.0 Update 3 | 11 de julio de 2017 | Compilación ISO 5572656

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

  • Esta versión de ESXi 6.0 Update 3a aborda 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
  • Francés
  • Alemán
  • Japonés
  • 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 base de datos externa para 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.

  • Site Recovery Manager: las versiones de Site Recovery Manager (SRM) anteriores a la 6.5 no admiten personalización de IP ni operaciones de llamada en el invitado para máquinas virtuales que estén ubicadas en ESXi 6.0 y que utilicen VMware Tools 10.1 o una versión posterior. Para obtener más detalles, consulte los problemas de VMware Tools.

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-Update03a incluye los siguientes boletines individuales:

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

La versión de revisión ESXi600-Update03a incluye los siguientes perfiles de imagen:

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

Problemas resueltos

Los problemas resueltos se agrupan del siguiente modo:

Problemas de copias de seguridad
  • Cuando se agrega en caliente un disco virtual nuevo o existente a una máquina virtual con CBT habilitado que se encuentra en el almacén de datos de VVOL, el sistema operativo invitado puede dejar de responder

    Cuando se agrega en caliente un disco virtual nuevo o existente a una máquina virtual con el seguimiento de bloques modificados (Changed Block Tracking, CBT) habilitado que se encuentra en el almacén de datos de VVOL, el sistema operativo invitado puede dejar de responder hasta que se complete el proceso de adición en caliente. La falta de respuesta de la máquina virtual depende del tamaño del disco virtual que se agregue. La máquina virtual se recupera automáticamente una vez que se completa la adición en caliente.

    El problema se resolvió en esta versión.

Problemas con el CIM y las API
  • El agente SNMP notifica los valores de los contadores ifOutErrors y ifOutOctets de forma incorrecta

    El agente de protocolo de administración de red simple (Simple Network Management Protocol, SNMP) informa el mismo valor para los contadores ifOutErrors y ifOutOctets cuando los valores deben ser diferentes.

    El problema se resolvió en esta versión.

  • La pila de IPMI no responde después de un restablecimiento completo de BMC

    La pila de la interfaz de administración de plataforma inteligente (Intelligent Platform Management Interface, IPMI) no responde después de que se restablezca por completo una controladora de administración de placa base (Baseboard Management Controller, BMC).

    El problema se resolvió en esta versión.

  • Los módulos de memoria DDR4 se muestran como desconocidos en la página Estado de mantenimiento de hardware en vCenter Server

    Los módulos de memoria DDR4 de los servidores Dell 13G se muestran como desconocidos en la página Estado de mantenimiento de hardware en vCenter Server.

    El problema se resolvió en esta versión.

Problemas con los sistemas operativos invitados
  • Se produce un error en un host con una pantalla de diagnóstico de color morado donde se muestra VMKPCIPassthru_SetupIntrProxy cuando se utiliza el acceso directo de PCI

    Cuando se utiliza el acceso directo de PCI con dispositivos en los que se utilizan MSI-X y kernels de Linux más recientes, una pantalla de diagnóstico de color morado muestra VMKPCIPassthru_SetupIntrProxy. Este problema se produce por el código en PCIPassthruChangeIntrSettings.

    El problema se resolvió en esta versión.

Problemas de perfiles de host y Auto Deploy
  • No se puede iniciar sesión en un host ESXi que se agregó a un dominio de Active Directory con Auto Deploy mediante vSphere Authentication Proxy

    Después de usar vSphere Auto Deploy para agregar hosts a un dominio de Active Directory mediante vSphere Authentication Proxy, no se puede iniciar sesión en el host con las credenciales de AD.

    El problema se resolvió en esta versión.

Problemas de internacionalización
  • Es posible que los caracteres no latinos se muestren incorrectamente en los nombres de perfiles de almacenamiento de máquinas virtuales

    Los caracteres UTF-8 no se manipulan correctamente antes de transferirse a un proveedor VASA de VVol. Como resultado, el proveedor VASA de VVol no reconoce los perfiles de almacenamiento de máquinas virtuales donde se utilizan caracteres internacionales, o bien no manipula o no muestra correctamente esos caracteres.

    El problema está resuelto en esta versión.

Problemas varios
  • El sistema operativo invitado puede mostrar una reducción de velocidad o un pico de uso de CPU

    El sistema operativo invitado puede mostrar una reducción de velocidad o un pico de uso de CPU que se desvanece después de deshabilitar ASLR en el sistema operativo invitado y realizar un proceso de FSR.

    Los siguientes procesos pueden provocar este comportamiento:
    1. La caché de traducción se llena con las traducciones de numerosas instrucciones de CPUID/RDTSC de nivel de usuario que se encuentran en diferentes direcciones virtuales en el sistema operativo invitado.
    2. El supervisor de máquina virtual utiliza una función de hash con dispersión deficiente durante la comprobación de las traducciones existentes.

    Al deshabilitar ASLR, es posible resolver el problema temporalmente hasta que se actualiza el host ESXi a una versión que contenga la corrección. El problema se resolvió en esta versión.

  • Se produce un error en un host ESXi con una pantalla morada o un mensaje de advertencia durante la destrucción de un montón de vmkernel físicamente contiguos con un tamaño inicial asignado de 64 MB o más

    Debido a la contabilización incorrecta de la memoria de sobrecarga, se muestra un error en un host ESXi con una pantalla morada o un mensaje de advertencia en el tiempo de descarga cuando se destruye un montón de vmkernel físicamente contiguos con un tamaño inicial asignado de 64 MB o más.

    Se observa el siguiente mensaje de advertencia:

    Heap: 2781: Non-empty heap (<heapName>) being destroyed (avail is <size>, should be <size>).

    El problema se resolvió en esta versión.

  • Se pueden observar mensajes de error de contención de bloqueo en un archivo lunTimestamps.log de los registros de hostd

    Para actualizar la última marca de tiempo vista de cada LUN en un host ESXi, un proceso debe adquirir un bloqueo en el archivo /etc/vmware/lunTimestamps.log. El bloqueo se mantiene por un período más prolongado de lo necesario en cada proceso. Si existen demasiados procesos intentando actualizar el archivo /etc/vmware/lunTimestamps.log, se puede producir una contención de bloqueo en este archivo. Si hostd es uno de los procesos que intenta adquirir el bloqueo, el host ESXi puede quedar desconectado de vCenter Server o dejar de responder con mensajes de error de contención de bloqueo (en el archivo lunTimestamps.log) en los registros de hostd. Es posible recibir un mensaje de error similar al siguiente:

    Error interacting with configuration file /etc/vmware/lunTimestamps.log: Timeout while waiting for lock, /etc/vmware/lunTimestamps.log.LOCK, to be released. Another process has kept this file locked for more than 30 seconds. The process currently holding the lock is (). This is likely a temporary condition. Please try your operation again.

    Nota:

    • process_name es el proceso o el servicio que actualmente mantiene el bloqueo en /etc/vmware/lunTimestamps.log. Por ejemplo, smartd, esxcfg-scsidevs, localcli, etc.
    • PID es el identificador de proceso de cualquiera de estos servicios.

     

    El problema se resolvió en esta versión.

  • Una máquina virtual se puede apagar automáticamente con el error "MXUserAllocSerialNumber: too many locks"

    Durante el funcionamiento normal de una máquina virtual, los servicios VMware Tools (versión 9.10.0 y versiones posteriores) crean conexiones de vSocket para intercambiar datos con el hipervisor. Cuando se crea una gran cantidad de conexiones de este tipo, el hipervisor puede quedarse sin números de serie de bloqueo y la máquina virtual se puede apagar con un error.

    El problema se resolvió en esta versión.

  • Desborde en los registros del sistema

    Cada vez que la API del kernel vmk_ScsiCmdGetVMUuid no puede obtener un UUID de máquina virtual válido, se imprime en los registros del sistema un mensaje de error similar al siguiente:

    2016-06-30T16:46:08.749Z cpu6:33528)WARNING: World: vm 0: 11020: vm not found

    El problema se resolvió en esta versión mediante la invocación en determinadas condiciones de la función World_GetVcUuid, por la que se produce el desborde de registros desde la PI del kernel vmk_ScsiCmdGetVMUuid.

Problemas de redes
  • Un host ESXi puede dejar de responder cuando se vuelve a conectar a vCenter Server

    Si se desconecta un host ESXi de vCenter Server y algunas de las máquinas virtuales en ese host utilizan un grupo LAG, el host ESXi puede dejar de responder cuando se vuelve a conectar a vCenter Server después de recrear el mismo LAG en el lado de vCenter Server y se puede mostrar un error como el siguiente:
    0x439116e1aeb0:[0x418004878a9c]LACPScheduler@ # +0x3c stack: 0x417fcfa00040 0x439116e1aed0:[0x418003df5a26]Net_TeamScheduler@vmkernel#nover+0x7a stack: 0x43070000003c 0x439116e1af30:[0x4180044f5004]TeamES_Output@ # +0x410 stack: 0x4302c435d958 0x439116e1afb0:[0x4180044e27a7]EtherswitchPortDispatch@ # +0x633 stack: 0x0

    El problema está resuelto en esta versión.

  • Las estadísticas de red muestran un recuento de paquetes anormal en el gráfico de rendimiento de red de vCenter Server

    El cálculo del recuento de paquetes de red puede estar a cargo de varias CPU. Este cálculo puede presentar un error de cálculo de estadísticas de red y mostrar un número incorrecto en el gráfico de rendimiento de red.

    El problema se resolvió en esta versión.

  • Las máquinas virtuales configuradas para utilizar el firmware EFI no pueden arrancar con PXE en algunos entornos de DHCP

    Una máquina virtual configurada para usar el firmware EFI no puede obtener una dirección IP cuando intenta arrancar con PXE si el entorno de DHCP responde mediante una IP de unidifusión. El firmware EFI no es capaz de recibir una respuesta de DHCP enviada mediante una dirección IP de unidifusión.

    El problema se resolvió en esta versión.

  • Todas las máquinas virtuales pierden conectividad cuando un montón de Еtherswitch se queda sin memoria

    Se produce una fuga de memoria en el montón de Еtherswitch con un tamaño de 32 bytes a 63 bytes. Cuando el montón se queda sin memoria, las máquinas virtuales pierden la conexión.

    El problema se resolvió en esta versión.

  • Se produce un error en el host ESXi con una pantalla de diagnóstico de color morado en el nivel DVFilter de vMotion y se muestra el error "PCPU 25: no heartbeat (3/3 IPIs received)"

    Cuando se reinicia el host ESXi en las siguientes condiciones, se puede producir un error en el host con una pantalla de diagnóstico de color morado y un error PCPU xxx: no heartbeat.
     

    •  Se debe utilizar vSphere Network Appliance (DVFilter) en un entorno de NSX
    •  Se debe migrar una máquina virtual con vMotion bajo el control de DVFilter

    El problema se resolvió en esta versión.

  • Las máquinas virtuales, que forman parte de grupos de infraestructura de escritorio virtual (Virtual Desktop Infrastructure, VDI) donde se usa la tecnología de clon instantáneo, pierden la conexión con los servicios de introspección de invitado

    Las máquinas virtuales existentes donde se usa el clon instantáneo y las nuevas, creadas con o sin el clon instantáneo, pierden la conexión con el módulo de host de Guest Introspection. Como resultado, las máquinas virtuales quedan desprotegidas y no se pueden reenviar configuraciones nuevas de Guest Introspection al host ESXi. También se muestra una advertencia "Guest Introspection no listo" en la interfaz de usuario de vCenter Server.

    El problema se resolvió en esta versión.

  • El registro de VMkernel incluye una o varias advertencias de tipo "No se pudo habilitar la conexión persistente"

    Las advertencias de tipo "No se pudo habilitar la conexión persistente" se emiten durante la comunicación entre VMware NSX y las soluciones de socios a través de un socket VMCI (vsock). El registro de VMkernel ahora omite estas advertencias repetidas, ya que se pueden ignorar de forma segura.

    El problema se resolvió en esta versión.

  • El kernel puede entrar en estado de pánico debido a la pérdida de conectividad de red en una máquina virtual con vNIC e1000/e1000e

    En una máquina virtual con vNIC e1000/e1000e, cuando el controlador e1000/e1000e indica a la emulación de vmkernel e1000/e1000e que omita un descriptor (la dirección de descriptor de transmisión y la longitud son 0), se puede producir una pérdida de conectividad y la máquina virtual puede entrar en estado de pánico del kernel.

    El problema se resolvió en esta versión.

  • Se produce un error en vSphere vMotion cuando se conecta una instancia de ESXi a un conmutador vSphere Distributed Switch configurado con LACP

    Si se conecta un host ESXi a un conmutador vSphere Distributed Switch configurado con LACP y si el grupo LAG tiene vínculos superiores en el estado de vínculo inactivo, al intentar usar vSphere vMotion, se mostrará una advertencia similar a la siguiente: Currently connected network interface 'Network Adapter 1' uses network 'DSwitchName', which is not accessible.

    El problema se resolvió en esta versión.

  • Un host ESXi puede dejar de estar disponible durante el apagado

    Si se utiliza un tipo de dirección IPv6 en un host ESXi, el host puede dejar de estar disponible durante el apagado.

    Actualice el host ESXi a la versión 6.0 Update 3a.

Problemas de seguridad
  • Actualización de la biblioteca Pixman

    La biblioteca Pixman se actualizó a la versión 0.35.1.

  • La pila Likewise en ESXi no está habilitada para admitir SMBv2

    El controlador de dominio de Windows 2012 admite SMBv2, mientras que la pila Likewise en ESXi solo admite SMBv1.

    Con esta versión, la pila Likewise en ESXi está habilitada para admitir SMBv2.

    El problema se resolvió en esta versión.

  • Actualización de VMware Tools

    Se actualizó VMware Tools a la versión 10.1.5. Para obtener más información, consulte Notas de la versión de VMware Tools 10.1.5.

    VMware Tools 10.1.5 soluciona los problemas de seguridad en los componentes de código abierto.

  • Actualización de OpenSSL

    El paquete de OpenSSL se actualizó a la versión openssl-1.0.2k para solucionar CVE-2017-3731, CVE-2017-3730, CVE-2017-3732 y CVE-2016-7055.

  • Actualización de Python

    Se actualizó Python a la versión 2.7.13 para solucionar CVE-2016-2183 y CVE-2016-1000110.

Problemas con la configuración de servidores
  • El servicio vpxd se bloquea y la interfaz de usuario de vSphere Web Client no se puede conectar a vCenter Server ni actualizar ese servidor

    En determinadas circunstancias, la ruta del perfil para el objeto VMODL queda sin configurar. Esta condición activa un problema de serialización durante la validación del archivo de respuesta para la configuración de red, lo que produce un bloqueo en el servicio vpxd.

    El problema se resolvió en esta versión.

  • No se puede unir un host ESXi 6.x a Active Directory a través de un perfil de host

    Al intentar usar perfiles de host para unir un host ESXi 6.x a un dominio de Active Directory, la aplicación se bloquea o se produce un error.

    El problema está resuelto en esta versión.

Problemas de almacenamiento
  • El comando vm-support se ejecuta con un error no irrecuperable

    El comando vm-support utiliza un script llamado smartinfo.sh para recopilar datos SMART para cada dispositivo de almacenamiento en el host ESXi. El comando vm-support impone un tiempo de espera de 20 segundos para cada comando que recopila datos de compatibilidad. Sin embargo, smartinfo.sh tarda más de 20 segundos en completarse, lo que hace que el comando vm-support se ejecute con el siguiente error: Se agotó el tiempo de espera de cmd /usr/lib/vmware/vm-support/bin/smartinfo.sh después de 20 segundos debido a la falta de progreso en los últimos 10 segundos (0 bytes leídos).

    El problema se resolvió en esta versión.

  • hostd se bloquea debido a bibliotecas no inicializadas

    Cuando se intenta volver a agregar un host a vCenter Server, hostd puede bloquearse si el host tiene habilitado el filtro de E/S y existen máquinas virtuales con el seguimiento de bloques modificados (Changed Block Tracking, CBT) habilitado en ese host. La biblioteca de filtros utiliza las bibliotecas de sondeos y de trabajadores. Cuando la biblioteca de filtros se inicializa antes de las bibliotecas de sondeos y de trabajadores, no puede funcionar correctamente y se bloquea.

    El problema se resolvió en esta versión.

  • Un host ESXi puede dejar de responder mientras se ejecuta una máquina virtual de ese host en una instantánea de SeSparse

    Después de crear una instantánea de una máquina virtual en un formato SEsparse, es posible enfrentar una condición de carrera extraña si se producen operaciones de E/S por segundo de escritura significativas y diversas en la instantánea. Esta condición de carrera puede hacer que el host ESXi deje de responder.

    El problema se resolvió en esta versión.

  • Las máquinas virtuales que utilizan el formato de disco virtual SEsparse pueden dejar de responder durante la ejecución de cargas de trabajo de E/S específicas

    Las máquinas virtuales con instantáneas basadas en SEsparse pueden dejar de responder durante las operaciones de E/S con un tipo específico de carga de trabajo de E/S en varios subprocesos.

    El problema se resolvió en esta versión.

  • La reversión de un error durante una operación de cambio de perfil de almacenamiento da como resultado un ID de perfil dañado

    Si un proveedor VASA de VVol devuelve un error durante una operación de cambio de perfil de almacenamiento, vSphere intenta deshacer la operación, pero el ID de perfil se daña en el proceso.

    El problema se resolvió en esta versión.

  • Se muestra una latencia de lectura/escritura incorrecta en vSphere Web Client para los almacenes de datos de VVol

    La latencia de lectura/escritura por host que se muestra para los almacenes de datos de VVol en vSphere Web Client no es correcta.

    El problema se resolvió en esta versión.

  • Se producen errores en las operaciones de perfil de host en un entorno de Auto Deploy

    Las operaciones de perfil de host, como la comprobación de cumplimiento, la corrección y la clonación de un perfil de host, no se pueden realizar en un entorno de Auto Deploy.
    Se observan los siguientes escenarios:

    1. Durante la instalación desde cero de hosts ESXi mediante Auto Deploy
      • Se produce un error en la comprobación de cumplimiento de los perfiles de host y se muestra un mensaje similar al siguiente:
        Host is unavailable for checking compliance
      • Se produce un error en la corrección de perfiles de host (al aplicar perfiles de host) y se muestra un mensaje similar al siguiente:
        Call "HostProfileManager.GenerateConfigTaskList" for object "HostProfileManager" on vCenter Server <vCenter_hostname> failed
    2. Se produce un error al cambiar el host de referencia del perfil de host y se muestra un mensaje similar al siguiente:
      Call "HostProfileManager.CreateProfile" for object "HostProfileManager" on vCenter Server <vCenter_hostname> failed.
    3. Se produce un error a clonar el perfil de host y se muestra un mensaje similar al siguiente:
      Call "HostProfileManager.CreateProfile" for object "HostProfileManager" on vCenter Server <vCenter_hostname> failed. The profile does not have an associated reference host

    En los archivos de registro, ubicados en /var/log/syslog.log, se muestran las operaciones con errores y el siguiente mensaje:
    Error: profileData from only a single profile instance supported in VerifyMyProfilesPolicies.

    El problema se resolvió en esta versión.

  • Un host ESXi que contiene una máquina virtual configurada con VMware vFlash Read Cache (VFRC) puede presentar un error con una pantalla morada

    Un host ESXi que contiene una máquina virtual configurada con VMware vFlash Read Cache (VFRC) puede presentar un error con una pantalla morada cuando el almacenamiento back-end se vuelve lento o inaccesible. Este error se debe a un defecto de bloqueo en el código VFRC.

    El problema se resolvió en esta versión.

  • SESparse provoca daños en el sistema de archivos del sistema operativo invitado

    El uso de SESparse para crear instantáneas y clonar máquinas virtuales puede provocar daños en el sistema de archivos del sistema operativo invitado.

    El problema se resolvió en esta versión.

  • Un cambio dinámico en el parámetro de profundidad de la cola para el dispositivo produce el desbordamiento de hostd con notificaciones de eventos

    Cuando Storage I/O Control (SIOC) cambia el parámetro de profundidad máxima de la cola de LUN, se envía una notificación de eventos de la arquitectura de almacenamiento acoplable (Pluggable Storage Architecture, PSA) a hostd. En las configuraciones donde se cambia el parámetro de profundidad de la cola de manera dinámica, se envía una carga de notificaciones de eventos a hostd, la cual produce problemas de rendimiento como tareas de vSphere lentas o la desconexión de hostd de vCenter Server.

    En esta versión, PSA no envía ninguna notificación de eventos a hostd.

  • Al volver a calcular el resumen para un disco con la memoria caché de lectura basada en contenido (Content Based Read Cache, CBRC) habilitada, nunca se notifica el cálculo de porcentaje de finalización, sino que se devuelve un error del sistema

    El filtro CBRC utiliza el cálculo de 32 bits para realizar cálculos y devuelve un porcentaje de finalización para cada solicitud de recálculo del resumen. En los discos de gran tamaño, la cantidad de hash es suficiente como para desbordar el cálculo de 32 bits, lo que produce un porcentaje de finalización incorrecto.

    El problema se resolvió en esta versión.

  • El usuario debe configurar manualmente la regla de SATP para el modelo FlashArray de Pure Storage

    En un dispositivo FlashArray de Pure Storage, el usuario debe agregar manualmente la regla de SATP para establecer los valores de SATP, PSP y E/S por segundo según los requisitos.

    Este problema se resolvió en esta versión y se agregó una nueva regla de SATP a ESXi para establecer SATP en VMW_SATP_ALUA, PSP en VMW_PSP_RR y E/S por segundo en 1 para todos los modelos FlashArray de Pure Storage.

    Nota: En el caso de una instalación de ESXi sin estado, si se aplica un perfil de host anterior, se sobrescriben las reglas nuevas después de la actualización.

  • Error al desmontar el almacén de datos

    En ocasiones, cuando se intenta desmontar un almacén de datos NFS de vCenter Server, se puede producir un error en la operación con el mensaje NFS datastore unmount failure - Datsatore has open files, cannot be unmounted.

    El problema se resolvió en esta versión.

  • Cuando se utiliza Storage vMotion, el UUID de un disco virtual puede cambiar

    Cuando se utiliza Storage vMotion en el almacenamiento de vSphere Virtual Volumes, el UUID de un disco virtual puede cambiar. El UUID identifica el disco virtual. Cuando se cambia el UUID, el disco virtual aparece como un disco nuevo diferente. El UUID también es visible para el sistema operativo invitado y puede provocar que las unidades no se identifiquen correctamente.

    El problema se resolvió en esta versión.

  • Se muestran mensajes de error "No se pudo abrir el archivo" en vmkernel.log durante el montaje de grupos de discos o el arranque de ESXi en vSAN

    Se ven mensajes de error "No se pudo abrir el archivo" en el archivo vmkernel.log cuando un host ESXi habilitado para vSAN arranca o durante el montaje manual de un grupo de discos en vSAN.

    El problema se resolvió en esta versión.

  • Una máquina virtual de clonación vinculada con su tipo de disco SESparse puede colgarse cuando se descartan paquetes o E/S por algún problema con el controlador HBA, la controladora, el firmware, la conectividad o la topología de almacenamiento

    Cuando se cuelgan o se descartan operaciones de E/S en la capa de controladores HBA por algún problema con el controlador HBA, las controladoras, el firmware, la conectividad o la topología de almacenamiento, la operación de E/S detenida no se cancela, lo que hace que la máquina virtual se bloquee.

    El problema se resolvió en esta versión.

  • El sistema deja de responder y se puede recibir el error "Problema de eliminación de bloques" en el archivo vmkernel.log

    Cuando se produce un error en los comandos unmap, el host ESXi puede dejar de responder debido a una fuga de memoria en la ruta de error. Es posible recibir el siguiente mensaje de error en el archivo vmkernel.log: FSDisk: 300: Issue of delete blocks failed [sync:0] and the host gets unresponsive.

    Al evitar la fuga de memoria, se pudo resolver este problema en esta versión.

  • Si se usa SEsparse y se habilita la operación de anulación de asignaciones, el sistema de archivos del sistema operativo invitado se puede dañar

    Si se usa SEsparse y se habilita la operación de anulación de asignaciones para crear instantáneas y clones de máquinas virtuales, después de que se completa la operación de barrido (la anulación de asignaciones de almacenamiento), el sistema de archivos del sistema operativo invitado puede quedar dañado. El clon completo de la máquina virtual se ejecuta bien.

    El problema se resolvió en esta versión.

  • Se puede producir un error al modificar el límite de E/S por segundo de los discos virtuales con el seguimiento de bloques modificados (Changed Block Tracking, CBT) habilitado

    Para definir la directiva de programación de E/S de almacenamiento de una máquina virtual, se puede modificar el límite de E/S por segundo para configurar la capacidad de proceso de E/S de cada disco de la máquina virtual. Al modificar el límite de E/S por segundo y habilitar CBT para la máquina virtual, se produce un error en la operación y se muestra el mensaje The scheduling parameter change failed. Debido a este problema, no se permite modificar las directivas de programación de las máquinas virtuales. El mensaje de error se muestra en el panel Tareas recientes de vSphere.

    Se pueden ver los siguientes errores en el archivo /var/log/vmkernel.log:

    2016-11-30T21:01:56.788Z cpu0:136101)VSCSI: 273: handle 8194(vscsi0:0):Input values: res=0 limit=-2 bw=-1 Shares=1000 2016-11-30T21:01:56.788Z cpu0:136101)ScsiSched: 2760: Invalid Bandwidth Cap Configuration 2016-11-30T21:01:56.788Z cpu0:136101)WARNING: VSCSI: 337: handle 8194(vscsi0:0):Failed to invert policy
     

    El problema se resolvió en esta versión.

  • La cancelación de una tarea de creación de instantáneas no se ejecuta correctamente

    Cuando se intenta cancelar una tarea de creación de instantáneas, pero el proveedor VASA no puede cancelar las operaciones subyacentes relacionadas en un disco con respaldo de VVol, se crea un VVol con instantánea que se conserva hasta que lo borra la recopilación de elementos no utilizados.

    El problema se resolvió en esta versión.

  • La cancelación de una tarea de creación de clones no se ejecuta correctamente

    Cuando se intenta cancelar una tarea de creación de clones, pero el proveedor VASA no puede cancelar las operaciones subyacentes relacionadas, vCenter Server crea una nueva instancia de VVol, copia todos los datos e informa de que la creación de clones se realizó correctamente.

    El problema se resolvió en esta versión.

Problemas de hardware compatible
  • Los hosts ESXi que se ejecutan con la revisión ESXi600-201611001 pueden mostrar un error en una pantalla de diagnóstico de color morado a causa de interrupciones no enmascarables (Non-Maskable-Interrupts, NMI) en servidores HPE ProLiant Gen8

    La revisión ESXi600-201611001 incluye un cambio que permite que ESXi deshabilite la funcionalidad de reasignación de interrupción de Intel® IOMMU (también conocida como VT-d). En los servidores HPE ProLiant Gen8, la deshabilitación de esta funcionalidad provoca errores de PCI. Como resultado de estos errores, la plataforma genera interrupciones NMI que hacen que el host ESXi muestre un error en una pantalla de diagnóstico de color morado.

    El problema está resuelto en esta versión.

Problemas de actualización e instalación
  • El inicio de sesión en un host ESXi mediante SSH requiere volver a indicar la contraseña

    Se solicitará dos veces una contraseña al conectarse a un host ESXi a través de SSH si el host ESXi se actualiza de vSphere 5.5 a la versión 6.0 cuando forma parte de un dominio.

    El problema está resuelto en esta versión.

Problemas en vCenter Server, vSphere Web Client y vSphere Client
  • No se puede usar VMware Host Client en Chrome 57

    Cuando se intenta iniciar sesión en VMware Host Client mediante Chrome 57, VMware Host Client informa inmediatamente de un error. El error sobre el que se informa es un error de tipo Digest in progress de Angular.

    El problema está resuelto en esta versión.

Problemas en la administración de máquinas virtuales
  • No se eliminan los archivos VMDK de resumen de la carpeta de máquina virtual cuando se elimina una máquina virtual

    Cuando se crea un clon vinculado a partir de un archivo VMDK de resumen, vCenter Server marca el archivo de disco de resumen como no eliminable. Por lo tanto, cuando se elimina la máquina virtual correspondiente, el archivo VMDK de resumen no se elimina de la carpeta de máquina virtual debido a la entrada ddb.deletable = FALSE ddb en el archivo descriptor.

    El problema se resolvió en esta versión.

  • La máquina virtual puede dejar de responder

    Cuando se crea una instantánea de una máquina virtual, esta puede dejar de responder.

    El problema se resolvió en esta versión.

  • La máquina virtual puede dejar de responder debido a una caída de la memoria activa

    Si la memoria activa de una máquina virtual que se ejecuta en un host ESXi queda en 1 % y cae a cero, el host puede comenzar a recuperar memoria incluso si el host tiene suficiente memoria libre.

    El problema se resolvió en esta versión.

    1. Conéctese a vCenter Server mediante vSphere Web Client.
    2. Seleccione un host ESXi del inventario.
    3. Apague todas las máquinas virtuales en el host ESXi.
    4. Haga clic en Configuración.
    5. En el encabezado Sistema, haga clic en Configuración avanzada del sistema.
    6. Busque el valor Mem.SampleActivePctMin.
    7. Haga clic en Editar.
    8. Cambie el valor a 1.
    9. Haga clic en Aceptar para aplicar los cambios.
    10. Encienda las máquinas virtuales.
  • Es posible que un host ESXi se desconecte de vCenter Server

    Debido a una fuga de memoria, es posible que el proceso de hostd se bloquee con el siguiente error: 

    Memory exceeds hard limit. Panic.

    Los registros de hostd notifican varios errores como Unable to build Durable Name.

    Este tipo de fuga de memoria hace que el host se desconecte de vCenter Server.

    El problema se resolvió en esta versión.

  • La máquina virtual deja de responder durante la consolidación de instantáneas

    Durante la consolidación de instantáneas, se puede realizar un cálculo preciso a fin de determinar el espacio de almacenamiento necesario para realizar la consolidación. Este cálculo preciso puede provocar que la máquina virtual deje de responder debido a que tarda mucho tiempo en completarse.

    El problema se resolvió en esta versión.

  • La migración con vMotion de una máquina virtual se suspende durante algún tiempo y más tarde se produce un error en el tiempo de espera

    Si una máquina virtual tiene un controlador (especialmente un controlador de gráficos) o una aplicación que fija demasiada memoria, crea una página rápida en la máquina virtual. Cuando esta máquina virtual está a punto de migrarse con vMotion a otro host, el proceso de migración se suspende y más tarde se produce un error debido a cálculos de entrada/salida pendientes incorrectos.

    El problema está resuelto en esta versión.

Problemas de vSAN
  • Los valores de cálculo bytsToSync en VC y RVC pueden aparecer de manera incorrecta en los objetos de RAID5/6

    El cálculo actual de los bytes de resincronización sobrevalora el tráfico de resincronización total para las configuraciones de RAID5/6. Esto puede ocurrir cuando se presenta cualquiera de las siguientes opciones:

    • Se coloca el nodo en modo de mantenimiento, ya sea en modo de evacuación "Migración de datos completa" o "Garantizar accesibilidad".
    • Se crea un reflejo completo de un componente después de perderlo debido a un error en el clúster.

    El problema se resolvió en esta versión.

  • El sistema puede mostrar un mensaje de error genérico en lugar de un mensaje específico para identificar los problemas de falta de espacio

    En algunos casos, el sistema puede mostrar un mensaje de error genérico en lugar de un mensaje específico para identificar los problemas de falta de espacio. Por ejemplo, si se provocó un error por espacio de disco insuficiente, se puede ver un mensaje de error como "Storage policy change failure: 12 (Cannot allocate memory)" (Error de cambio de directiva de almacenamiento: 12 [no se puede asignar memoria]).

    El problema está resuelto en esta versión.

  • Es posible que se produzca un error en un host ESXi con una pantalla morada en bora/modules/vmkernel/lsomcommon/ssdlog/ssdopslog.c:199

    Se producen algunas carreras entre las diversas rutas de acceso de código interno de LSOM. Liberar dos veces una región en el nivel de almacenamiento en caché conlleva un seguimiento de pila y un estado de pánico de tipo:

    PanicvPanicInt@vmkernel#nover+0x36b stack: 0x417ff6af0980, 0x4180368 2015-04-20T16:27:38.399Z cpu7:1000015002)0x439124d1a780:[0x4180368ad6b7]Panic_vPanic@vmkernel#nover+0x23 stack: 0x46a, 0x4180368d7bc1, 0x43a 2015-04-20T16:27:38.411Z cpu7:1000015002)0x439124d1a7a0:[0x4180368d7bc1]vmk_PanicWithModuleID@vmkernel#nover+0x41 stack: 0x439124d1a800, 0x4 2015-04-20T16:27:38.423Z cpu7:1000015002)0x439124d1a800:[0x418037cc6d46]SSDLOG_FreeLogEntry@LSOMCommon#1+0xb6e stack: 0x6, 0x4180368dd0f4, 0 2015-04-20T16:27:38.435Z cpu7:1000015002)0x439124d1a880:[0x418037d3c351]PLOGCommitDispatch@com.vmware.plog#0.0.0.1+0x849 stack: 0x46a7500, 0

    Las condiciones de carrera se producen entre los flujos de trabajo PLOG Relog, PLOG Probe y PLOG Decommission.

    El problema está resuelto en esta versión.

  • En una carga de trabajo de E/S pesada, un proceso de vSAN puede ocupar los ciclos de CPU por un período prolongado, lo que da como resultado un bloqueo de PCPU breve

    En una carga de trabajo de E/S pesada, es posible que un proceso de vSAN ocupe los ciclos de CPU por un período prolongado, lo que da como resultado un bloqueo de PCPU breve. Esto da lugar a una interrupción no enmascarable y a un desborde en los archivos de registro de vmkernel.

    El problema se resolvió en esta versión.

  • Un host ESXi habilitado para VSAN puede presentar un error con PSOD

    Un host ESXi habilitado para VSAN puede producir un error y una pantalla morada con el siguiente rastreo inverso en la pantalla:

    2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bd20:[0x418032a77f83]Panic_vPanic@vmkernel#nover+0x23 stack: 0x4313df6720ba, 0x418032a944 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bd40:[0x418032a944a9]vmk_PanicWithModuleID@vmkernel#nover+0x41 stack: 0x43911b29bda0, 0x4 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bda0:[0x41803387b46c]vs_space_mgmt_svc_start@com.vmware.virsto#0.0.0.1+0x414 stack: 0x100 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29be00:[0x41803384266d]Virsto_StartInstance@com.vmware.virsto#0.0.0.1+0x68d stack: 0x4312df 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bf00:[0x4180338f138f]LSOMMountHelper@com.vmware.lsom#0.0.0.1+0x19b stack: 0x43060d72b980, 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bf30:[0x418032a502c2]helpFunc@vmkernel#nover+0x4e6 stack: 0x0, 0x43060d6a60a0, 0x35, 0x0, 2017-02-19T09:58:26.778Z cpu17:33637)0x43911b29bfd0:[0x418032c14c1e]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0, 0x0, 0x0, 0x0, 0

    El problema se resolvió en esta versión.

  • El uso de objtool en un host testigo de vSAN puede ocasionar que un host ESXi produzca un error con una pantalla morada

    Si utiliza objtool en un host testigo, este realiza una llamada de ioctl que implica una desreferencia del puntero NULL en el host ESXi testigo de vSAN y el host se bloquea.

    El problema se resolvió en esta versión.

  • La desinstalación de discos con la compresión y la eliminación de duplicados habilitadas donde se producen errores de comandos de acceso a medios pueden provocar un error en una pantalla morada en el nodo de vSAN

    Durante la desinstalación de un grupo de discos de vSAN con la compresión y la eliminación de duplicados habilitadas, el grupo de discos puede tener discos con errores de comandos de acceso. Los errores se pueden verificar mediante mensajes de registro de vmkernel como:
    Partition: 914: Read of GPT header (hdrlba = 1) failed on "naa.55cd2e404c185332" : I/O error.
    Esto produce un error en el host de vSAN durante la desinstalación.

    El problema está resuelto en esta versión.

  • Es posible recibir una falsa alarma por la comprobación de estado de vSAN

    En ocasiones, la interfaz de usuario de estado de vSAN puede presentar un estado incorrecto en la comprobación de estado de la red del tipo "Todos los hosts tienen una vmknic de Virtual SAN configurada". A continuación, se puede activar la alarma falsa de vCenter Server.

    El problema está resuelto en esta versión.

  • Una máquina virtual puede dejar de responder o un host puede desconectarse de vCenter Server, además de la congestión de registros en la versión 6.0 Update 2 o la congestión de memoria en la versión 6.0 Update 3

    Al quitar de un clúster de vSAN un componente de vSAN que se encuentra en un estado no válido, una máquina virtual puede dejar de responder o un host puede desconectarse de vCenter Server.

    El problema está resuelto en esta versión.

  • Un host ESXi puede generar un error con una pantalla de color morado

    Un host ESXi puede generar un error con una pantalla de color morado debido a una condición de carrera entre la inicialización de cliente del administrador de objetos distribuidos y los códigos de la interfaz sysinfo de VMkernel del administrador de objetos distribuidos.

    El problema se resolvió en esta versión.

  • La congestión de SSD puede provocar que varias máquinas virtuales dejen de responder

    Según la carga de trabajo y el número de máquinas virtuales, los grupos de discos en el host pueden entrar en estado de pérdida permanente de dispositivo (Permanent Device Loss, PDL). Esto hace que los grupos de discos no admitan más E/S, lo cual los deja inutilizables hasta que se lleva a cabo una intervención manual.
     

    El problema está resuelto en esta versión.

Problemas conocidos

Los problemas conocidos se agrupan del siguiente modo:

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ónRevise 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.
  • No se puede actualizar de ESXi 6.x a 6.0 Update 2 y versiones superiores 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

  • 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 en Virtual SAN

    • La interfaz de usuario de estado de Virtual SAN no se muestra debido a que se agota el tiempo de espera
      Cuando accede a la interfaz de usuario de estado de Virtual SAN en Clúster de Virtual SAN > Supervisar > Virtual SAN > Estado, la interfaz de usuario no se muestra. Una posible causa es que vSphere ESX Agent Manager deja de responder y el tiempo de espera se agota. Para confirmar, abra el registro de estado de Virtual SAN ubicado en /var/log/vmware/vsan-health/vmware-vsan-health-service.log y busque llamadas al servicio vSphere ESX Agent Manager mediante la cadena VsanEamUtil.getClusterStatus:.

      Solución alternativa: Reinicie el servicio vSphere ESX Agent Manager mediante vSphere Web Client y actualice la interfaz de usuario de estado de Virtual SAN.

    • La capacidad de servicio de un disco de Virtual SAN no funciona cuando se utilizan controladores lsi_msgpt3 de terceros
      Después de un error de host adicional, una comprobación de estado de un clúster de Virtual SAN de dos o tres nodos en Clúster de Virtual SAN > Supervisar > Virtual SAN > Estado > Estado límite se muestra en color rojo y activa una alarma o un evento de vCenter Server falsos cuando el uso de espacio de disco del clúster supera el 50%.

      Solución alternativa: Agregue uno o más hosts al clúster de Virtual SAN o agregue más discos para reducir el uso de espacio de disco del clúster a menos del 50%.

    • La comprobación de estado límite de un clúster de Virtual SAN de dos o tres nodos se muestra en color rojo
      El complemento para la capacidad de servicio de un disco de Virtual SAN (lsu-lsi-lsi-msgpt3-plugin) es compatible con la operación de obtener la ubicación del dispositivo y de activar o desactivar el LED del disco. El controlador de bandeja de entrada lsi_msgpt3 de VMware admite el complemento de capacidad de servicio. Sin embargo, si usa un controlador asíncrono de terceros, el complemento no funciona.

      Solución alternativa: Utilice la versión 06.255.10.00-2vmw o posterior del controlador de bandeja de entrada lsi_msgpt3 de VMware.

    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

    • Los hosts ESXi 6.0 Update 2 conectados a ciertas matrices de almacenamiento con una versión concreta del firmware podrían experimentar agotamiento de los 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ísica 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ísica 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).