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

|

Actualizado: 14 de marzo de 2017

ESXi 6.0 Update 3 | 24 de febrero de 2017 | Compilación ISO 5050593

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

  • Se actualizó el cliente del host ESXi: VMware ESXi 6.0 Update 3 incluye una versión actualizada del cliente del host ESXi 1.14.0. El cliente del host actualizado incluye correcciones de errores y se acerca mucho más a la funcionalidad que proporciona vSphere Client. Si actualizó el cliente del host mediante las versiones de revisión de ESXi 6.0, instale la versión 1.14.0 que se ofrece junto con ESXi 6.0 Update 3. Además, las nuevas versiones del cliente del host se siguen publicando en el sitio web de VMware Labs Flings. Sin embargo, estas versiones de Flings no son compatibles de forma oficial y no se recomiendan para entornos de producción.

  • Compatibilidad con TLS: la compatibilidad con TLSv1.0, TLSv1.1 y TLSv1.2 está habilitada de forma predeterminada y se puede configurar para ESXi 6.0 Update 3. Obtenga información sobre cómo configurar TLSv1.0, TLSv1.1 y TLSv1.2 en el artículo 2148819 de la base de conocimientos de VMware. Para obtener una lista de los productos de VMware compatibles con la deshabilitación de TLSv1.0 y el uso de TLSv1.1/1.2, consulte el artículo 2145796 de la base de conocimientos de VMware.

  • Rendimiento de Virtual SAN: se introdujeron varias correcciones en VMware ESXi 6.0 Update 3 para optimizar la ruta de acceso de E/S y así mejorar el rendimiento de Virtual SAN en las configuraciones híbridas y las basadas íntegramente en tecnología flash:

    • Se realizaron mejoras en el almacenamiento y la administración de registros que permiten almacenar más registros por byte de almacenamiento. Esto debería mejorar significativamente el rendimiento de las cargas de trabajo de uso intensivo de escritura. Debido a que Virtual SAN es un sistema de archivos basado en registros, la administración eficiente de las entradas de registro es clave para evitar la acumulación injustificada de registros.

    • Además de aumentar la densidad de empaquetado de las entradas de registro, Virtual SAN anula la realización de copias intermedias de los datos de forma preventiva en el nivel de capacidad, de modo que se administre el crecimiento de los registros de forma eficiente en los casos en los que se eliminan archivos de gran tamaño con los servicios de datos están activados.

    • La ruta de acceso de código de suma de comprobación ahora es más eficiente.

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

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

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

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

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
  • El método de proveedor de VMware que se utiliza para validar los permisos de usuario no funciona con el nombre de usuario y la contraseña después de salir del modo de bloqueo
    Cuando el servidor sale del modo de bloqueo, el método de proveedor de VMware devuelve un valor diferente que no es compatible con el valor presente antes de entrar en el modo de bloqueo. El problema causa que el método de proveedor de VMware que valida los permisos de usuario no funcione con el mismo nombre de usuario y la misma contraseña que antes del modo de bloqueo.

    El problema está resuelto en esta versión.

Problemas varios
  • Error de actualización de VMware Tools en varias máquinas virtuales
    Es posible que se produzca un error al intentar actualizar VMware Tools en varias máquinas virtuales al mismo tiempo mediante Update Manager. El proceso de actualización no se completa en todas las máquinas virtuales.

    El problema está resuelto en esta versión.

  • Una alta carga de lectura de imágenes ISO de VMware Tools puede causar daños en los medios con tecnología flash
    En el entorno de VDI, una alta carga de lectura de imágenes de VMware Tools puede producir daños en los medios con tecnología flash.

    El problema está resuelto en esta versión.

    Puede copiar todos los datos de VMware Tools en su propio disco RAM. Por lo tanto, los datos se podrán leer de los medios con tecnología flash solo una vez por arranque. Las demás lecturas irán al disco RAM. vCenter Server Agent (vpxa) accede a estos datos mediante el directorio /vmimages que contiene vínculos simbólicos que apuntan a productLocker.

    Para activar la característica, siga los siguientes pasos:

    1. Utilice el comando para establecer la opción avanzada ToolsRamdisk como 1:
    2. esxcli system settings advanced set -o /UserVars/ToolsRamdisk -i 1

    3. Reinicie el host.
  • Puede que el archivo syslog.log se llene de mensajes de error Unknown
    En ESXi 6.0 Update 2, puede que el archivo syslog.log de los hosts con el proveedor Dell CIM se llene de mensajes de error Unknown si se deshabilita el proveedor Dell CIM, o bien si este está en estado inactivo. Además, cuando el host ESXi 6.0 Update 2 se reinicia, puede que el archivo syslog.log registre mensajes de error de forma intermitente con entradas de tipo Unknown.

    El problema está resuelto en esta versión.

  • Error de volcado de núcleo del ámbito del usuario
    Puede que se produzca un error de volcado del ámbito del usuario cuando un proceso del usuario se quede sin memoria. Aparecerá el mensaje de error No se puede asignar memoria.

    El problema está resuelto en esta versión. La solución proporciona una memoria global para la asignación de pila de volcado de núcleo del ámbito del usuario, que se utiliza cuando algún proceso se queda sin memoria.

  • Se produce un error al ejecutar la conmutación por error de una máquina virtual al sincronizar el almacenamiento
    Al ejecutar la conmutación por error de una máquina virtual durante una operación de sincronización de almacenamiento, se produce un error con un mensaje similar al siguiente:

    Se produjo un error al comunicarse con el host remoto.

    Los siguientes mensajes se registran en el archivo HBRsrv.log:

    YYYY-MM-DDT13:48:46.305Z info hbrsrv[nnnnnnnnnnnn] [Originator@6876 sub=Host] Heartbeat handler detected dead connection for host: host-9
    YYYY-MM-DDT13:48:46.305Z warning hbrsrv[nnnnnnnnnnnn] [Originator@6876 sub=PropertyCollector] Got WaitForUpdatesEx exception: Server closed connection after 0 response bytes read; 171:53410'>, >)>


    En el host ESXi, también es posible que el servicio del hostd deje de responder con mensajes similares a estos:

    YYYY-MM-DDT13:48:38.388Z panic hostd[468C2B70] [Originator@6876 sub=Default]
    -->
    --> Panic: Assert Failed: "progress >= 0 && progress <= 100" @ bora/vim/hostd/vimsvc/HaTaskImpl.cpp:557
    --> Backtrace:
    -->

    El problema está resuelto en esta versión.

  • Aparecen mensajes de registro de forma persistente en el archivo hostd.log cada 90 segundos
    En el archivo hostd.log, aparecen mensajes de registro relacionados con Virtual SAN parecidos a los que se muestran a continuación cada 90 segundos, incluso cuando Virtual SAN no está habilitado:

    { YYYY-MM-DDT06:50:01.923Z info hostd[nnnnnnnn] [Originator@6876 sub=Hostsvc opID=21fd2fe8] VsanSystemVmkProvider : GetRuntimeInfo: Complete, runtime info: (vim.vsan.host.VsanRuntimeInfo) {
    YYYY-MM-DDT06:51:33.449Z info hostd[nnnnnnnn] [Originator@6876 sub=Hostsvc opID=21fd3009] VsanSystemVmkProvider : GetRuntimeInfo: Complete, runtime info: (vim.vsan.host.VsanRuntimeInfo) {
    YYYY-MM-DDT06:53:04.978Z info hostd[nnnnnnnn] [Originator@6876 sub=Hostsvc opID=21fd3030] VsanSystemVmkProvider : GetRuntimeInfo: Complete, runtime info: (vim.vsan.host.VsanRuntimeInfo) {

    El problema está resuelto en esta versión.

  • Error de actualización de VMware Tools en varias máquinas virtuales
    Es posible que se produzca un error al intentar actualizar VMware Tools en varias máquinas virtuales al mismo tiempo mediante Update Manager. Si se produce este problema, es posible que no se pueda actualizar VMware Tools en algunas máquinas virtuales.

    El problema está resuelto en esta versión.

  • Se puede producir un error al enumerar las clases de proveedor SMX
    Cuando compila el proveedor HPE ESXi WBEM con la versión 6.0 de CIMPDK y lo instala en un sistema ESXi 6.0 U3, la enumeración de las clases de proveedor SMX puede fallar.

    Este error se puede generar debido a la enumeración de las siguientes clases de SMX, entre otras:

    • SMX_EthernetPort
    • SMX_Fan
    • SMX_PowerSupply
    • SMX_SAMediaAccessStatData

    El sfcbd muestra el siguiente error para estas clases de SMX:

    # enum_instances SMX_EthernetPort root/hpq error: enumInstances Server returned nothing (no headers, no data)

    Los proveedores responden a las consultas de enumeración y proporcionan correctamente las respuestas a la sfcbd. No existen reinicios del proveedor ni volcados de núcleo de proveedor. Cada enumeración genera volcados de núcleo CIMXML sfcbd; por ejemplo, sfcb-CIMXML-Pro-zdump.000.

    El problema está resuelto en esta versión.

Problemas de redes
  • Puede que los paquetes de solicitud de ARP se descarten
    Los paquetes de solicitud de ARP entre dos máquinas virtuales podrían descartarse si una de las máquinas virtuales se configura con el etiquetado de VLAN invitado, la otra se configura con el etiquetado de VLAN de conmutador virtual y la descarga de VLAN se desactiva en ambas máquinas virtuales.

  • Puede que se deshabilite la configuración del firewall de ESXi debido a una actualización generada por script
    La configuración del firewall de ESXi podría deshabilitarse después de una actualización generada por script de ESXi 6.0 Update 1 (o una versión posterior) mediante un archivo de inicio a través de NFS o FTP.

    El problema está resuelto en esta versión.

  • Se usa la dirección MAC virtual 00:00:00:00:00:00 durante la comunicación de una NIC física recién agregada, incluso después de reiniciar el host
    Puede que una NIC física recién agregada no tenga la entrada en el archivo esx.conf después de reiniciar el host, lo que ocasiona la aparición de una dirección MAC virtual 00:00:00:00:00:00 para dicha NIC física durante la comunicación.

    El problema está resuelto en esta versión.

  • Aparece un mensaje de error durante la fase de arranque
    En ciertas condiciones, mientras el instalador de ESXi lee el script de instalación durante la fase de arranque, aparece un mensaje de error similar al siguiente:

    VmkNicImpl::DisableInternal:: Eliminando la interfaz de administración de vmk0; advlface se establece como NULL.

    El problema está resuelto en esta versión.

  • El conmutador físico se llena de paquetes RARP cuando se utiliza el arranque PXE de VDI de Citrix
    Al arrancar una máquina virtual para VDI de Citrix, el conmutador físico se llena de paquetes RARP (más de 1.000), que pueden provocar la pérdida de las conexiones de red y una interrupción temporal.

    Esta versión proporciona la opción avanzada /Net/NetSendRARPOnPortEnablement. Debe establecer el valor de /Net/NetSendRARPOnPortEnablement como 0 para solucionar este problema.

  • Un host ESXi puede generar un error con una pantalla de diagnóstico de color morado
    Un host ESXi puede generar un error con una pantalla de diagnóstico de color morado. Esto sucede cuando se invoca a DVFilter_TxCompletionCB() para completar un paquete de memoria de recurso compartido de dvfilter; se liberan todos los datos de E/S almacenados dentro del paquete, pero, en ocasiones, este miembro de datos se convierte en 0, lo que provoca una excepción de puntero nulo. Aparece un mensaje de error similar al siguiente:

    YYYY-MM-DDT04:11:05.134Z cpu24:33420)@BlueScreen: #PF Exception 14 in world 33420:vmnic4-pollW IP 0x41800147d76d addr 0x28
    PTEs:0x587e436023;0x587e437023;0x587e438023;0x0;
    YYYY-MM-DDT04:11:05.134Z cpu24:33420)Code start: 0x418000800000 VMK uptime: 23:18:59:55.570
    YYYY-MM-DDT04:11:05.135Z cpu24:33420)0x43915461bdd0:[0x41800147d76d]DVFilterShmPacket_TxCompletionCB@com.vmware.vmkapi#v2_3_0_0+0x3d sta
    YYYY-MM-DDT04:11:05.135Z cpu24:33420)0x43915461be00:[0x41800146eaa2]DVFilterTxCompletionCB@com.vmware.vmkapi#v2_3_0_0+0xbe stack: 0x0
    YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461be70:[0x418000931688]Port_IOCompleteList@vmkernel#nover+0x40 stack: 0x0
    YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461bef0:[0x4180009228ac]PktListIOCompleteInt@vmkernel#nover+0x158 stack: 0x0
    YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461bf60:[0x4180009d9cf5]NetPollWorldCallback@vmkernel#nover+0xbd stack: 0x14
    YYYY-MM-DDT04:11:05.137Z cpu24:33420)0x43915461bfd0:[0x418000a149ee]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0

    El problema está resuelto en esta versión.

Problemas de seguridad
  • Actualización de Likewise Kerberos
    Likewise Kerberos se actualiza a la versión 1.14.
  • Actualización de OpenSSL
    OpenSSL se actualiza a la versión openssl-1.0.2j.
  • Actualización de PAM
    PAM se actualiza a la versión 1.3.0.
  • Actualización de la biblioteca libPNG
    La biblioteca libPNG se actualiza a libpng-1.6.26.
  • Actualización del paquete de NTP
    El paquete de ESXi NTP se actualiza a la versión 4.2.8p9.
  • Actualización de la biblioteca libcurl
    La biblioteca de ESXi userworld libcurl se actualiza a libcurl-7.51.0.
Problemas con la configuración de servidores

  • La conectividad entre vCenter Server y el host ESXi se pierde cuando el perfil de host se vuelve a aplicar a un host ESXi sin estado
    Cuando un perfil de host con adaptadores vmknic tanto en vSphere Standard Switch como en vSphere Distributed Switch se aplica a un host ESXi, podría quitar el adaptador vmknic vmk0 (interfaz de administración) de vSphere Standard Switch, lo que haría que el host se desconectara de vCenter Server.

    El problema está resuelto en esta versión.

  • El servicio de hostd puede generar un error al tomar una snapshot en modo inactivo
    El servicio de hostd puede generar un error al realizar una operación de snapshot en modo inactivo durante el proceso de replicación. En el archivo hostd.log se muestra un mensaje de error similar al siguiente: 2016-06-10T22:00:08.582Z [37181B70 info 'Hbrsvc'] ReplicationGroup will retry failed quiesce attempt for VM (vmID=37) 2016-06-10T22:00:08.583Z [37181B70 panic 'Default'] --> -->Panic: Assert Failed: "0" @ bora/vim/hostd/hbrsvc/ReplicationGroup.cpp:2779

    El problema está resuelto en esta versión.

  • Los hosts ESXi 6.0 Update 1 pueden generar un error con una pantalla de diagnóstico morada al recopilar estadísticas
    Los hosts ESXi con un gran número de CPU físicas pueden dejar de responder durante la recopilación de estadísticas. Este problema se produce cuando el proceso de recopilación intenta acceder a páginas que se encuentran fuera del rango que se le asignó inicialmente.

    El problema está resuelto en esta versión.

  • La actualización de la revisión de ESXi puede generar un error con un mensaje de advertencia si el tamaño del perfil de imagen es mayor que el límite establecido
    La instalación de una actualización de la revisión de ESXi puede generar un error si el tamaño del archivo de perfil de destino es superior a 239 MB. Esto puede suceder cuando se actualiza el sistema con ISO, lo que provoca que el tamaño del perfil de imagen sea mayor que 239 MB y no se reciba ningún mensaje de advertencia. Esto impedirá que se instalen VIB adicionales en el sistema.

    El problema está resuelto en esta versión.

  • El archivo vmkernel.log recibe múltiples eventos de suspensión y reanudación de USB
    El archivo vmkernel.log recibe múltiples eventos de suspensión y reanudación de USB similares a los siguientes:

    YYYY-MM-DDT

    El problema está resuelto en esta versión.

  • No se puede ver la lista de usuarios o grupos para asignar permisos en la pestaña Permiso
    No se puede ver la lista de usuarios o grupos para asignar permisos en la pestaña Permiso y la autenticación puede generar un error para el usuario del dominio de confianza. El problema se produce cuando el nombre de dominio DNS de una máquina es diferente del nombre DNS del dominio de AD.

    El problema está resuelto en esta versión. Sin embargo, después de actualizar el host ESXi a ESXi 6.0 Update 3, debe quitarlo del dominio de AD y volver a agregarlo al mismo dominio.

  • El host ESXi puede dejar de responder y mostrar una pantalla de diagnóstico de color morado
    Cuando el conjunto de archivos de volcado se invoca mediante el comando esxcfg-dumppart u otros varias veces en paralelo, un host ESXi puede dejar de responder y mostrar una pantalla de diagnóstico de color morado con entradas similares a las siguientes como resultado de una condición de carrera mientras se libera la asignación de bloque de volcado:

    @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4907 - Corruption in dlmalloc
    Code start: 0xnnnnnnnnnnnn VMK uptime: 234:01:32:49.087
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]PanicvPanicInt@vmkernel#nover+0x37e stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Panic_NoSave@vmkernel#nover+0x4d stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DLM_free@vmkernel#nover+0x6c7 stack: 0x8
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Heap_Free@vmkernel#nover+0xb9 stack: 0xbad000e
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]Dump_SetFile@vmkernel#nover+0x155 stack: 0xnnnnnnnnnnnn
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]SystemVsi_DumpFileSet@vmkernel#nover+0x4b stack: 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSI_SetInfo@vmkernel#nover+0x41f stack: 0x4fc
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UWVMKSyscallUnpackVSI_Set@ # +0x394 stack: 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@ # +0xb4 stack: 0xffb0b9c8
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@vmkernel#nover+0x1d stack: 0x0
    0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]gate_entry_@vmkernel#nover+0x0 stack: 0x0

    El problema está resuelto en esta versión.

Problemas de almacenamiento
  • No se pueden eliminar los volúmenes Virtual Volume obsoletos y los archivos VMDK mediante el comando esxcli vvol abandonedvvol
    Los intentos de usar el comando esxcli storage vvol storagecontainer abandonedvvol para limpiar el volumen Virtual Volume obsoleto y los archivos VMDK que permanecen en el volumen Virtual Volume no tienen éxito.

    El problema está resuelto en esta versión.

  • La cancelación de tareas de creación de snapshots para Virtual Volumes puede provocar una pérdida de datos
    Los intentos de cancelar la creación de snapshots de una máquina virtual cuyos VMDK se encuentran en almacenes de datos de Virtual Volumes pueden provocar que los discos virtuales no se reviertan correctamente y, por lo tanto, se pierdan datos. Esta situación se produce cuando una máquina virtual tiene varios VMDK con el mismo nombre y estos proceden de diferentes almacenes de datos de Virtual Volumes.

    El problema está resuelto en esta versión.

  • Un VMDK no se revierte correctamente cuando falla la creación de snapshots en máquinas virtuales de Virtual Volumes
    Cuando los intentos de crear snapshots para una máquina virtual de Virtual Volumes fallan, el VMDK se vincula a un Virtual Volume de datos incorrecto. El problema solo se produce cuando el VMDK de la máquina virtual de Virtual Volumes procede de varios almacenes de datos de Virtual Volumes.

    El problema está resuelto en esta versión.

  • Las operaciones de E/S de una máquina virtual se detienen o cancelan cuando el almacenamiento subyacente devuelve por equivocación un error de comparación durante latidos de VMFS periódicos
    El VMFS utiliza el comando compare-and-write de SCSI, también llamado ATS, para los latidos periódicos. Cualquier error de comparación durante la ejecución del comando ATS se considera un latido perdido y el almacén de datos inicia una acción de recuperación. Para evitar daños, se cancelan todas las operaciones de E/S en el dispositivo. Cuando el almacenamiento subyacente notifica de forma incorrecta errores de comparación durante los latidos del VMFS, el almacén de datos inicia una acción de recuperación innecesaria.

    El problema está resuelto en esta versión.

  • Los hosts ESXi 6.x dejan de responder después de funcionar durante 85 días
    Cuando se produce este problema, el archivo de registro /var/log/vmkernel muestra entradas similares a las siguientes:

    YYYY-MM-DDTHH:MM:SS.833Z cpu58:34255)qlnativefc: vmhba2(5:0.0): Recieved a PUREX IOCB woh oo
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:34255)qlnativefc: vmhba2(5:0.0): Recieved the PUREX IOCB.
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)qlnativefc: vmhba2(5:0.0): sizeof(struct rdp_rsp_payload) = 0x88
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674qlnativefc: vmhba2(5:0.0): transceiver_codes[0] = 0x3
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)qlnativefc: vmhba2(5:0.0): transceiver_codes[0,1] = 0x3, 0x40
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)qlnativefc: vmhba2(5:0.0): Stats Mailbox successful.
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)qlnativefc: vmhba2(5:0.0): Sending the Response to the RDP packet
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674 0 1 2 3 4 5 6 7 8 9 Ah Bh Ch Dh Eh Fh
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)--------------------------------------------------------------
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 53 01 00 00 00 00 00 00 00 00 04 00 01 00 00 10
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) c0 1d 13 00 00 00 18 00 01 fc ff 00 00 00 00 20
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 00 00 00 00 88 00 00 00 b0 d6 97 3c 01 00 00 00
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 0 1 2 3 4 5 6 7 8 9 Ah Bh Ch Dh Eh Fh
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674)--------------------------------------------------------------
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 02 00 00 00 00 00 00 80 00 00 00 01 00 00 00 04
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 18 00 00 00 00 01 00 00 00 00 00 0c 1e 94 86 08
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 0e 81 13 ec 0e 81 00 51 00 01 00 01 00 00 00 04
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 2c 00 04 00 00 01 00 02 00 00 00 1c 00 00 00 01
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 00 00 00 00 40 00 00 00 00 01 00 03 00 00 00 10
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 50 01 43 80 23 18 a8 89 50 01 43 80 23 18 a8 88
    YYYY-MM-DDTHH:MM:SS.833Z cpu58:33674) 00 01 00 03 00 00 00 10 10 00 50 eb 1a da a1 8f

    Este problema se debe a un error en el controlador de qlnativefc, que envía una respuesta de lectura de parámetros de diagnóstico (RDP) al adaptador HBA con una longitud de transferencia incorrecta. Como resultado, el firmware del adaptador HBA no libera el espacio del grupo de búfer. Cuando se agota el grupo de búfer, el adaptador HBA no puede procesar más solicitudes y deja de estar disponible. De forma predeterminada, la rutina RDP la inicia el conmutador de FC y tiene lugar cada hora, lo que hace que, en circunstancias normales, el grupo de búfer tarde en agotarse aproximadamente entre 80 y 85 días.

    El problema está resuelto en esta versión.

  • En vSphere 6.0, el objeto HostMultipathStateInfoPath de la API de la directiva de almacenamiento proporciona el valor de ruta de acceso como Run Time Name vmhbaX:CX:TX:LX
    En ESXi 5.5, HostMultipathStateInfoPath proporcionaba la información de ruta de acceso con este formato: HostWWN-ArrayWWN-LUN_ID. Por ejemplo: sas.500605b0072b6550-sas.500c0ff1b10ea000-naa.600c0ff0001a20bd1887345701000000. Sin embargo, en ESXi 6.0, el valor de la ruta de acceso aparece como vmhbaX:CX:TX:LX, lo que puede afectar a los usuarios que se basan en el objeto HostMultipathStateInfoPath para recuperar información como HostWWN y ArrayWWN.

    El problema está resuelto en esta versión. El objeto HostMultipathStateInfoPath ahora muestra la información de ruta de acceso como Nombre de hora de ejecución y HostWWN-ArrayWWN-LUN_ID.

    También puede usar el comando esxcli storage core path list para recuperar la información relacionada con la ruta de acceso. Este comando proporciona los detalles de HostWWN y ArrayWWN. Para obtener más información, consulte el artículo 1003973 de la base de conocimientos.

  • Un host ESXi puede generar un error con una pantalla de diagnóstico de color morado
    Un host ESXi con vFlash configurado puede generar un error con una pantalla de diagnóstico de color morado y un mensaje de error similar a PSOD: @BlueScreen: #PF Exception 14 in world 500252:vmx-vcpu-0:V.

    El problema está resuelto en esta versión.

  • Un host ESXi genera un error con una pantalla de diagnóstico de color morado debido a conflictos de notificación de ruta de acceso
    Un host ESXi muestra una pantalla de diagnóstico de color morado cuando encuentra un dispositivo que está registrado, pero cuyas rutas de acceso están reclamadas por dos complementos de múltiples rutas, como por ejemplo el complemento de múltiples rutas nativas (NMP) y EMC PowerPath. Este tipo de conflicto se produce cuando una regla de notificación de complemento no puede reclamar la ruta de acceso y NMP la reclama de forma predeterminada. NMP intenta registrar el dispositivo, pero, debido a que el otro complemento ya lo registró, se produce una condición de carrera y se genera un error en el host ESXi.

    El problema está resuelto en esta versión.

  • En archivos de gran tamaño, se produce un error en las operaciones de archivo cuando el host se queda sin memoria
    Al realizar operaciones de archivo como el montaje de archivos grandes presentes en un almacén de datos, estas pueden generar un error en un host ESXi. Esta situación puede producirse cuando una fuga de memoria en la caché del búfer hace que el host ESXi se quede sin memoria; por ejemplo, cuando una copia de datos distintos de cero impide que los búferes se liberen. En la máquina virtual se muestra un mensaje de error similar al siguiente.

    The operation on file /vmfs/volumes/5f64675f-169dc0cb/CloudSetup_20160608.iso failed. If the file resides on a remote file system, make sure that the network connection and the server where this disk resides are functioning properly. If the file resides on removable media, reattach the media. Select Retry to attempt the operation again. Select Cancel to end this session. Select Continue to forward the error to the guest operating system.

    El problema está resuelto en esta versión.

  • Es posible que la operación de redacción de Horizon View falle para las máquinas virtuales de escritorio que residen en el almacén de datos de NFS
    La operación de redacción de Horizon View puede generar el error Administrar archivo NFS obsoleto para algunas máquinas virtuales de escritorio que residan en el almacén de datos de NFS.

    El problema está resuelto en esta versión.

Problemas de actualización e instalación
  • La actualización de ESXi con vSphere Update Manager falla si ESXi se implementa usando una imagen dd en USB y /altbootbank contiene el archivo BOOT.CFG en mayúsculas
    Una imagen dd de ESXi generada en determinadas versiones de RHEL mediante la utilidad esxiso2dd puede contener el archivo BOOT.CFG en mayúsculas en /altbootbank. Si el archivo BOOT.CFG está en mayúsculas, vSphere Update Manager no puede actualizar el host debido a que el comprobador previo a la actualización solo acepta boot.cfg en minúsculas.

    El problema está resuelto en esta versión.

  • Hostd genera un error al actualizar los hosts ESXi 5.5.x a ESXi 6.0.x con la revisión 6.0 de ESXi ESXi600-201611011 o superior
    Se puede observar este problema cuando se sintala un controlador HPSA asíncrono que admite el modo HBA. A pesar de que ESXi admite la obtención de información de ubicación del disco de HPSA en el modo HBA, se pueden producir problemas si se cumple alguna de las siguientes condiciones:

    • Instaló una utilidad hpssacli antigua, versión 2.10.14.0 o anterior.
    • Utilizó una matriz externa para conectar la controladora HPSA.

    Estos problemas causan errores de hostd e impiden a vSphere Client y a vCenter Server acceder al host.

    El problema está resuelto en esta versión. Ahora, cuando utiliza el comando esxcli para obtener la información de ubicación de disco, hostd no genera errores. El comando esxcli devuelve un mensaje de error similar al siguiente:

    “# esxcli storage core device physical get -d naa.500003963c888808 El complemento lsu-hpsa-plugin no puede obtener suficiente información para el dispositivo con el nombre naa.500003963c888808. El error fue: Salida no válida para la unidad física.

  • La actualización de vSphere Update Manager de ESXi iniciada con una imagen dd en USB puede generar un error cuando /altbootbank contiene el archivo BOOT.CFG (mayúsculas) en lugar de boot.cfg (minúsculas)
    La imagen dd de ESXi generada en determinadas versiones de RHEL mediante la utilidad esxiso2dd contiene el archivo BOOT.CFG (en mayúsculas) en /altbootbank; la presencia de BOOT.CFG hace que la actualización de vSPhere Update Manager de ESXi falle debido a que la comprobación previa a la actualización solo busca el archivo boot.cfg en minúsculas.
  • El problema está resuelto en esta versión.

  • Tras la actualización a la versión 6.0, el nombre del perfil de imagen en la pestaña Resumen del host no se actualiza correctamente
    Cuando se utiliza el comando esxcli software profile update para aplicar un nuevo perfil de imagen, el nombre del perfil de imagen no cambia al nuevo nombre de perfil de imagen. Además, cuando se utiliza la imagen ISO para realizar la actualización, el nuevo nombre de perfil de imagen no está marcado como Actualizado.

    El problema está resuelto en esta versión.

Problemas en vCenter Server, vSphere Web Client y vSphere Client
  • Nuevo problema vSphere Web Client tarda mucho tiempo en completar ciertas operaciones
    Ciertas operaciones realizadas en vSphere Web Client tardan mucho tiempo en completarse y mostrar los cambios de configuración. Este problema puede producirse si Storage I/O Control está habilitado en algunos o todos los almacenes de datos de un inventario de vCenter Server de tamaño medio o grande. Si desea obtener más detalles sobre el problema, consulte el artículo 2146935 de la base de conocimientos.

    El problema está resuelto en esta versión.

Problemas en la administración de máquinas virtuales
  • vSphere Update Manager envía recordatorios de reinicio de VMware Tools cuando el reinicio ya tuvo lugar tras la instalación
    El código de error de instalación de VMware Tools muestra que se requiere un reinicio incluso después de que VMware Tools se haya reiniciado tras las instalación. La variable guestInfo.toolsInstallErrCode en el lado de ejecutable de máquina virtual (VMX) no se borra cuando VMware Tools se instala correctamente y se produce el reinicio. Esto hace que vSphere Update Manager envíe avisos incorrectos para reiniciar VMware Tools.

    El problema está resuelto en esta versión.

  • Hostd genera un error cuando ListProcesses se ejecuta en el sistema operativo invitado
    Cuando hay un gran número de procesos en un sistema operativo invitado, el proceso ListProcesses se invoca más de una vez y los datos de VMware Tools se reciben en múltiples fragmentos. Cuando varias llamadas de ListProcesses al sistema operativo invitado (uno para cada fragmento) se ensamblan juntas, la implementación crea un conflicto. Varios ListProcesses identifican cuándo han llegado todos los datos y llaman a un controlador de devolución de llamada interno. Si se llama dos veces al controlador, se produce un error en hostd.

    El problema está resuelto en esta versión.

  • Posibles daños o pérdidas de datos cuando un sistema operativo invitado emite comandos de cancelación de asignación de SCSI y un filtro de E/S impide la operación de cancelación de asignación
    Cuando un disco virtual de máquina virtual se configura con filtros de E/S y el sistema operativo invitado emite comandos de cancelación de asignación de SCSI, dichos comandos pueden ejecutarse correctamente incluso si uno de los filtros de E/S configurados genera un error en la operación. Como resultado, el estado que se refleja en el VMDK difiere del que se muestra en el filtro de E/S, y el sistema operativo invitado puede ver los daños o la pérdida de datos.

    El problema está resuelto en esta versión.

  • Un host ESXi puede generar un error con una pantalla de diagnóstico de color morado
    Cuando una operación DVFilter_TxCompletionCB() intenta completar un paquete de memoria de recurso compartido de dvfilter, libera al miembro de datos completo de E/S almacenado en el paquete. En algunos casos, este miembro de datos se convierte en 0, lo que ocasiona una excepción de puntero nulo. Aparece un mensaje de error similar al siguiente:

    YYYY-MM-DDT04:11:05.134Z cpu24:33420)@BlueScreen: #PF Exception 14 in world 33420:vmnic4-pollW IP 0x41800147d76d addr 0x28 PTEs:0x587e436023;0x587e437023;0x587e438023;0x0; YYYY-MM-DDT04:11:05.134Z cpu24:33420)Code start: 0x418000800000 VMK uptime: 23:18:59:55.570 YYYY-MM-DDT04:11:05.135Z cpu24:33420)0x43915461bdd0:[0x41800147d76d]DVFilterShmPacket_TxCompletionCB@com.vmware.vmkapi#v2_3_0_0+0x3d sta YYYY-MM-DDT04:11:05.135Z cpu24:33420)0x43915461be00:[0x41800146eaa2]DVFilterTxCompletionCB@com.vmware.vmkapi#v2_3_0_0+0xbe stack: 0x0 YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461be70:[0x418000931688]Port_IOCompleteList@vmkernel#nover+0x40 stack: 0x0 YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461bef0:[0x4180009228ac]PktListIOCompleteInt@vmkernel#nover+0x158 stack: 0x0 YYYY-MM-DDT04:11:05.136Z cpu24:33420)0x43915461bf60:[0x4180009d9cf5]NetPollWorldCallback@vmkernel#nover+0xbd stack: 0x14 YYYY-MM-DDT04:11:05.137Z cpu24:33420)0x43915461bfd0:[0x418000a149ee]CpuSched_StartWorld@vmkernel#nover+0xa2 stack: 0x0

    El problema está resuelto en esta versión.

  • Un host ESXi con acceso directo de PCI puede dejar de responder y mostrar una pantalla de diagnóstico de color morado
    Al reiniciar una máquina virtual con acceso directo de PCI varias veces, el host ESXi podría dejar de responder y podría mostrar una pantalla de diagnóstico de color morado con mensajes similares a los siguientes en el archivo vmware.log:

    XXXXXXXXXXXXXXX| vcpu-0| W110: A core file is available in " /vmx-debug-zdump.000"
    XXXXXXXXXXXXXXX| vcpu-0| I120: Msg_Post: Error
    XXXXXXXXXXXXXXX| vcpu-0| I120: [msg.log.error.unrecoverable] VMware ESX
    XXXXXXXXXXXXXXX| vcpu-0| unrecoverable error: (vcpu-0)
    XXXXXXXXXXXXXXX| vcpu-0| I120+ vcpu-7:ASSERT vmcore/vmm/intr/intr.c:459

    El problema está resuelto en esta versión.

  • El servicio de hostd puede fallar durante el proceso de replicación
    El servicio de hostd puede generar un error cuando una operación de snapshot en modo inactivo falla durante el proceso de replicación. En el archivo hostd.log, podría incluirse un mensaje de error similar al siguiente:

    YYYY-MM-DDT22:00:08.582Z [37181B70 info 'Hbrsvc'] ReplicationGroup will retry failed quiesce attempt for VM (vmID=37)
    YYYY-MM-DDT22:00:08.583Z [37181B70 panic 'Default']
    -->
    --> Panic: Assert Failed: "0" @ bora/vim/hostd/hbrsvc/ReplicationGroup.cpp:2779

    El problema está resuelto en esta versión.

  • El servicio de hostd puede dejar de responder si encuentra errores de E/S para una máquina virtual aprovisionada con una controladora SCSI virtual de LSI
    Un host ESXi puede dejar de responder si encuentra errores de E/S de almacenamiento para una máquina virtual aprovisionada con una controladora virtual de LSI y si la memoria está sobrecomprometida en el host ESXi.

    El problema está resuelto en esta versión.

Problemas en Virtual SAN
  • Nuevo problema Una máquina virtual que utiliza almacenamiento de Virtual SAN puede tardar en responder, o dejar de hacerlo, y se puede producir un error de administración de host de Virtual SAN cuando el host entra en modo de mantenimiento o se reconfigura una directiva en un clúster de Virtual SAN
    Este problema puede ocurrir cuando no se acumula ningún dato en el nivel de memoria caché del grupo de discos de Virtual SAN y el procesamiento de cero datos congestiona el registro. Dicha congestión puede reducir la velocidad de E/S de las máquinas virtuales que usan almacenamiento de Virtual SAN y un error de administración de host de Virtual SAN. Este problema ocurre únicamente en los clústeres de vSAN habilitados para la desduplicación y la compresión.

    El problema está resuelto en esta versión.

  • Errores intermitentes en operaciones de clúster de Virtual SAN relacionadas con el aprovisionamiento o que crean nuevos objetos
    Una fuga de memoria en el daemon de administrador de objetos a nivel de clúster (Cluster Level Object Manager Daemon, CLOMD) agota la memoria tras un tiempo de ejecución prolongado, lo que causa que el daemon deje de estar disponible de forma temporal.

    El problema está resuelto en esta versión.

  • El módulo DOM no se inicializa
    Descripción: Es posible que el CLOMD no utilice Virtual SAN en un host ESXi con un gran número de CPU físicas. Este problema puede ocurrir si el módulo DOM de Virtual SAN no se inicializa cuando se une a un clúster.

    En el archivo clomd.log, se muestra un mensaje de error similar al siguiente:

    2016-12-01T22:34:49.446Z 2567759 Failed to run VSI SigCheck: Failure 2016-12-01T22:34:49.446Z 2567759 main: Clomd is starting 2016-12-01T22:34:49.446Z 2567759 main: Is in stretched cluster mode? No 2016-12-01T22:34:49.446Z 2567759 CLOMSetOptions: Setting forground to TRUE 2016-12-01T22:34:49.446Z 2567759 CLOMSetOptions: No default configuration specified. 2016-12-01T22:34:49.447Z 2567759 main: Starting CLOM trace 2016-12-01T22:34:49.475Z 2567759 Cannot open DOM device /dev/dom: No such file or directory 2016-12-01T22:34:49.475Z 2567759 Cannot connect to DOM: Failure 2016-12-01T22:34:49.475Z 2567759 CLOM_CleanupRebalanceContext: Cleaning up rebalancing state 2016-12-01T22:34:49.481Z 2567759 Failed to dump data 2016-12-01T22:34:49.481Z 2567759 2016-12-01T22:34:49.481Z 2567759 main: clomd exit

    El problema está resuelto en esta versión.

  • El host ESXi no puede volver a unirse al clúster de VMware Virtual SAN después de un reinicio
    Los intentos de volver a unirse de forma manual al clúster de VMware Virtual SAN después de un reinicio pueden generar el siguiente error:

    No se pudo unir al host en el clúster de VSAN (no se pudo iniciar vsantraced: código de retorno 2)

    El problema está resuelto en esta versión.

  • Las llamadas constantes a la API de VSAN pueden hacer que se muestre un mensaje de tarea engañoso
    En un entorno con vCenter Server 6.0 Update 2 y Virtual SAN 6.2, llamar a la API de VSAN constantemente da como resultado la creación de tareas de registro de un ticket en el proveedor VASA de Virtual SAN y la aparición de un mensaje similar al siguiente:

    Recuperar un ticket para registrar el proveedor VASA de Virtual SAN

    El problema está resuelto en esta versión.

  • La tarea de reequilibrio de disco de Virtual SAN se detiene en 5% durante más de 24 horas
    El servicio de estado de Virtual SAN informa de advertencias de equilibrio de disco de Virtual SAN en vSphere Web Client. Al hacer clic en Volver a equilibrar discos, parece que la tarea se detiene en 5% durante más de 24 horas.

    Este problema se resuelve en esta versión y la tarea Volver a equilibrar discos se muestra como completada después de 24 horas.

  • El host ESXi puede dejar de responder y mostrar una pantalla de diagnóstico de color morado
    Un host ESXi puede dejar de responder y mostrar una pantalla de diagnóstico de color morado con mensajes similares a los siguientes:

    YYYY-MM-DDT22:59:29.686Z cpu40:84493)@BlueScreen: #PF Exception 14 in world 84493:python IP 0xnnnnnnnnnnnn addr 0xfffffffffffffff0 PTEs:0x0;
    YYYY-MM-DDT22:59:29.686Z cpu40:84493)Code start: 0xnnnnnnnnnnnn VMK uptime: 7:15:08:48.373
    YYYY-MM-DDT22:59:29.686Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DOMClient_IsTopObject@com.vmware.vsan#0.0.0.1+0x18 stack: 0xnnnnnnnn
    YYYY-MM-DDT22:59:29.687Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DOMListUuidTopHierarchyCbk@com.vmware.vsan#0.0.0.1+0x69 stack: 0x900
    YYYY-MM-DDT22:59:29.687Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSANUUIDTable_Iterate@com.vmware.vsanutil#0.0.0.1+0x4b stack: 0x139d
    YYYY-MM-DDT22:59:29.687Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]DOMVsi_ListTopClients@com.vmware.vsan#0.0.0.1+0x5a stack: 0x66
    YYYY-MM-DDT22:59:29.688Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSI_GetListInfo@vmkernel#nover+0x354 stack: 0xnnnnnnnnnnnn
    YYYY-MM-DDT22:59:29.688Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UWVMKSyscallUnpackVSI_GetList@#+0x216 stack: 0xnnnnnnnnn
    YYYY-MM-DDT22:59:29.688Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@#+0xb4 stack: 0xnnnnnnn
    YYYY-MM-DDT22:59:29.689Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@vmkernel#nover+0x1d stack: 0x0
    YYYY-MM-DDT22:59:29.689Z cpu40:84493)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]gate_entry_@vmkernel#nover+0x0 stack: 0x0

    El problema está resuelto en esta versión.

  • Los hosts ESXi pueden generar un error con una pantalla de diagnóstico de color morado
    Los hosts ESXi en un clúster de Virtual SAN pueden generar un error con una pantalla de diagnóstico de color morado cuando se pone en pausa una operación de resincronización de Virtual SAN.

    El problema está resuelto en esta versión.

Problemas de configuración de VMware HA y Fault Tolerance
  • Un host ESXi puede generar un error al habilitar Fault Tolerance en una máquina virtual
    Un host ESXi puede generar un error con una pantalla de diagnóstico de color morado cuando no se puede encender una máquina virtual secundaria con Fault Tolerance.

    El problema está resuelto en esta versión.

  • Se produce un error en el SDK de supervisión de aplicaciones invitadas de vSphere para las máquinas virtuales en las que se habilitó vSphere Fault Tolerance
    Cuando vSphere FT está habilitado en una máquina virtual protegida por vSphere HA en la que se instaló el supervisor de aplicaciones invitadas de vSphere, es posible que se produzca un error en el SDK de supervisión de aplicaciones invitadas de vSphere.

    Esta versión reduce considerablemente el aumento de la latencia de red de máquina virtual cuando se habilita Fault Tolerance.

  • Aumento de latencia cuando Fault Tolerance de SMP está habilitado en una máquina virtual
    Cuando se habilita Fault Tolerance de multiprocesador simétrico (symmetric multiprocessor, SMP) en una máquina virtual, la latencia de red de máquina virtual puede aumentar de manera significativa tanto en promedio como en variaciones. El aumento de la latencia puede provocar una considerable degradación del rendimiento o la inestabilidad de las cargas de trabajo de máquina virtual que son sensibles a tales aumentos de latencia.

    Esta versión reduce considerablemente el aumento de la latencia de red de máquina virtual cuando se habilita Fault Tolerance.

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.

  • 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

  • Nuevo problema La interfaz de usuario del 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.

  • Nuevo problema 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%.

  • Nuevo problema 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í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).