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

|

Actualizado: 6 de octubre de 2015

ESXi 6.0 Update 1a | 6 de octubre de 2015 | Compilación ISO 3073146

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 VMware ESXi incluye las siguientes mejoras:

  • Filtro de E/S: vSphere API para los filtros de E/S (VAIO) ofrece un marco que permite que terceros creen componentes de software denominados filtros de E/S. Los filtros pueden instalarse en hosts ESXi y pueden ofrecer servicios de datos adicionales a las máquinas virtuales mediante el procesamiento de solicitudes de E/S que se transfieren entre el sistema operativo invitado de una máquina virtual y los discos virtuales.

  • Afinidad exclusiva con contextos de sistemas adicionales asociados con una máquina virtual de baja latencia: esta versión presenta una nueva opción de VMX, sched.cpu.latencySensitivity.sysContexts, que se ocupa de los problemas en vSphere 6.0 donde la mayoría de los contextos de sistemas siguen siendo worldlets. El programador utiliza la opción sched.cpu.latencySensitivity.sysContexts en cada máquina virtual para identificar automáticamente un conjunto de contextos de sistemas que pueden estar involucrados en las cargas de trabajo sensibles a la latencia. Se proporciona afinidad exclusiva con un núcleo físico dedicado para cada uno de los contextos de sistemas. La opción de VMX sched.cpu.latencySensitivity.sysContexts indica cuántos núcleos exclusivos puede obtener una máquina virtual de baja latencia para los contextos de sistemas.

  • Autenticación de ESXi en Active Directory: ESXi se ha modificado para ser compatible únicamente con el cifrado AES256-CTS/AES128-CTS/RC4-HMAC para la comunicación entre ESXi y Active Directory mediante Kerberos.

  • Compatibilidad con SSLv3: la compatibilidad con SSLv3 se ha deshabilitado de forma predeterminada. Para obtener información detallada, consulte el artículo 2121021 de la base de conocimientos.

  • Dying Disk Handling (DDH): la característica Dying Disk Handling ofrece un marco de supervisión de latencia en el kernel, un daemon para detectar los períodos de alta latencia y un mecanismo para desmontar discos individuales y grupos de discos.

  • Clústeres extendidos: Virtual SAN 6.0 Update 1 es compatible con clústeres extendidos que abarcan varias ubicaciones geográficas para proteger los datos frente a errores en el sitio o pérdida de la conexión de red.

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.

Consulte también el artículo 2108548 de la base de conocimientos para obtener las instrucciones de instalación y configuración de vCenter Server.

Información del sistema operativo host de vCenter

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

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

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

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

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

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

Migrar soluciones de terceros

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

Actualizaciones e instalaciones no permitidas para CPU que no son compatibles

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

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

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

Notas para la actualización de esta versión

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

Componentes de código abierto para VMware vSphere 6.0

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

Avisos de compatibilidad con el producto

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

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

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

Revisiones incluidas en esta versión

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

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

ESXi600-201510401-BG: Actualización de ESXi 6.0 esx-base vib

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

ESXi-6.0.0-20151004001-standard
ESXi-6.0.0-20151004001-no-tools

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

Problemas resueltos

Los problemas resueltos se agrupan del siguiente modo:

Problemas con el CIM y las API
  • El proveedor de ServerView CIM no logra supervisar el estado de hardware si en el mismo host ESXi está instalado el proveedor de Emulex CIM
    Cuando el proveedor de ServerView CIM y el de Emulex CIM están instalados en el mismo host ESXi, es posible que el proveedor de Emulex CIM (sfcb-emulex_ucn) no responda, lo cual produce un error en la supervisión del estado de hardware.

    El problema está resuelto en esta versión.
Problemas con los sistemas operativos invitados
  • Un sistema invitado Linux que arranca con EFI puede presentar un error de respuesta a la entrada del teclado y del mouse
    Un sistema operativo invitado Linux que arranca con firmware de EFI puede presentar un error de respuesta a la entrada del teclado y del mouse si se produce algún movimiento del mouse durante el breve período de tiempo de arranque de EFI.

    El problema está resuelto en esta versión.

Problemas de actualización e instalación
  • Aplicar el perfil de host con almacenamiento en caché sin estado habilitado en el host ESXi sin estado puede tardar mucho en completarse
    La aplicación del perfil de host en un host ESXi sin estado con gran cantidad de LUN de almacenamiento puede demorar mucho el reinicio si se habilita un almacenamiento en caché sin estado con esx como primer argumento del disco. Esto sucede cuando se aplica manualmente el perfil de host o durante el reinicio del host.

    El problema está resuelto en esta versión.

  • No es posible instalar o actualizar a la versión 9.10.0 de VMware Tools en la versión en neerlandés de Windows Server 2008 R2
    Los intentos de instalar o actualizar a la versión 9.10.0 de VMware Tools disponible en ESXi 6.0 pueden generar errores en la versión en neerlandés de Windows Server 2008 R2. Aparece un mensaje de error similar al siguiente:

    El asistente de configuración de VMware Tools finalizó antes de tiempo

    El problema está resuelto en esta versión.

  • La operación de preconfiguración de VIB puede provocar que los cambios en la instalación o la configuración de VIB se pierdan una vez reiniciado el host ESXi
    Cuando se instalan algunos VIB en el sistema, la utilidad esxupdate construye una nueva imagen en /altbootbank y cambia el estado de arranque de /altbootbank boot.cfg que se actualizará. Cuando se instala un VIB directo instalable, el sistema guarda el cambio de configuración en /altbootbank. La operación de preconfiguración elimina el contenido de /altbootbank a menos que se realice una operación de corrección posteriormente. La instalación de VIB puede perderse si se reinicia el host después de realizar una operación de preconfiguración.

    El problema está resuelto en esta versión.

Problemas de redes
  • Los intentos de agregar una vmnic a un host ESXi en VDS generan un error de familia de direcciones no admitidas
    Después de actualizar de ESXi 5.5 a 6.0, puede producirse un error al intentar agregar una vmnic a un host VMware ESXi conectado a vSphere Distributed Switch (VDS). El problema se produce cuando ipfix está habilitado e IPv6 está deshabilitado.

    En el archivo /var/log/vmkernel.log del host ESXi afectado, verá entradas similares a las siguientes:

    cpu10:xxxxx opID=xxxxxxxx)WARNING: Ipfix: IpfixActivate:xxx: Activation failed for 'DvsPortset-1': Unsupported address family
    cpu10:xxxxx opID=xxxxxxxx)WARNING: Ipfix: IpfixDVPortParamWrite:xxx: Configuration failed for switch DvsPortset-1 port xxxxxxxx : Unsupported address family
    cpu10:xxxxx opID=xxxxxxxx)WARNING: NetDVS: xxxx: failed to init client for data com.vmware.etherswitch.port.ipfix on port xxx
    cpu10:xxxxx opID=xxxxxxxx)WARNING: NetPort: xxxx: failed to enable port 0x4000002: Unsupported address family
    cpu10:xxxxx opID=xxxxxxxx)NetPort: xxxx: disabled port 0x4000002
    cpu10:xxxxx opID=xxxxxxxx)Uplink: xxxx: vmnic2: Failed to enable the uplink port 0x4000002: Unsupported address family

    El problema está resuelto en esta versión.

  • Las máquinas virtuales que utilizan un adaptador virtual VMXNET3 pueden presentar errores al intentar arrancar desde iPXE
    Las máquinas virtuales que utilizan un adaptador virtual VMXNET3 pueden presentar errores al intentar arrancar desde iPXE (firmware de arranque de código abierto).

    El problema está resuelto en esta versión.

  • No se inicia la conmutación por error si hay un vínculo superior desconectado o apagado al utilizar el equilibrio de carga en una carga de NIC física
    Cuando se utiliza el equilibrio de carga basado en una carga de NIC física en VDS 6.0, si uno de los vínculos superiores está desconectado o apagado, la conmutación por error no se inicia.

    El problema está resuelto en esta versión.

  • Cuando vmk10 o posterior está habilitada para vMotion, es posible que vmk1 se habilite para vMotion durante el reinicio
    La habilitación de vMotion en vmk10 o posterior puede provocar que vmk1 habilite vMotion al reiniciar el host ESXi. Este problema puede causar un exceso de tráfico en vmk1 y problemas de red.

    El problema está resuelto en esta versión.

  • No hay disponibles métricas sobre datos de rendimiento de red de la máquina virtual para máquinas virtuales configuradas con VMXNET3 conectadas a un vSwitch estándar
    No se puede ver el gráfico de rendimiento en tiempo real de Red de una máquina virtual configurada con un adaptador VMXNET3 en VMware vSphere Client 6.0. Esto se debe a que la opción no está disponible en la lista desplegable Cambiar a.

    El problema está resuelto en esta versión.

  • Se perdió la conectividad de red al aplicar el perfil de host durante la ejecución de Auto Deploy
    Cuando se aplica el perfil de host durante la ejecución de Auto Deploy, puede perderse la conectividad de red porque la NIC del endpoint de túnel de VXLAN (VTEP) recibe una etiqueta de vmknic para administración.

    El problema está resuelto en esta versión.

  • Un ESXi anidado puede perder la conectividad y se podría restablecer la NIC virtual e1000e
    Un ESXi anidado puede perder la conectividad de forma intermitente y podría restablecerse la NIC virtual e1000e. También se puede observar una condición de todas las rutas de acceso inactivas (APD) para los volúmenes NFS. En el archivo vmkernel.log se escribe un mensaje de error parecido al siguiente:

    packets completion seems stuck, issuing reset

    El problema está resuelto en esta versión.

  • Nuevo problema Problemas de conexión de red después de actualizar de ESXi 5.x a ESXi 6.0
    Después de actualizar de ESXi 5.x a ESXi 6.0, puede encontrarse con los siguientes problemas:

    • El host ESXi 6.0 puede perder la conexión de red de forma aleatoria.

    • El host ESXi 6.0 deja de responder y no se puede administrar hasta que se reinicia.

    • Después de reiniciarse, el problema se soluciona temporalmente, pero pasado un tiempo de duración aleatoria, vuelve a producirse

    • El servicio NETDEV WATCHDOG del host ESXi suele registrar los tiempos de espera de transmisión. Puede ver entradas similares a las siguientes en el archivo /var/log/vmkernel.log:

      cpu0:33245)WARNING: LinNet: netdev_watchdog:3678: NETDEV WATCHDOG: vmnic0: transmit timed out
      cpu0:33245)WARNING: at vmkdrivers/src_92/vmklinux_92/vmware/linux_net.c:3707/netdev_watchdog() (inside vmklinux)

    • El problema puede afectar a varios tipos de adaptadores de red de diferentes proveedores de hardware. El registro exacto que se produce durante el tiempo de espera de transmisión puede variar de una tarjeta a otra.

    El problema está resuelto en esta versión.

Problemas de almacenamiento
  • El host ESXi puede presentar errores y mostrar una pantalla de diagnóstico morada cuando hay varios filtros vSCSI conectados a un disco de máquina virtual
    Un host ESXi 6.0 puede presentar error y mostrar una pantalla de diagnóstico morada cuando varios filtros vSCSI están conectados a un disco de máquina virtual. La pantalla de diagnóstico o rastreo recesivo contiene entradas similares a las siguientes:

    cpu24:nnnnnn opID=nnnnnnnn)@BlueScreen: #PF Exception 14 in world 103492:hostd-worker IP 0x41802c2c094d addr 0x30
    PTEs:0xnnnnnnnn;0xnnnnnnnnnn;0x0;
    cpu24:nnnnnn opID=nnnnnnnn)Code start: 0xnnnnnnnnnnnn VMK uptime: 21:06:32:38.296
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSCSIFilter_GetFilterPrivateData@vmkernel#nover+0x1 stack: 0xnnnnnnn
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSCSIFilter_IssueInternalCommand@vmkernel#nover+0xc3 stack: 0xnnnnnn
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CBRC_FileSyncRead@<None>#<None>+0xb1 stack: 0x0
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CBRC_DigestRecompute@<None>#<None>+0xnnn stack: 0xnnnn
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]CBRC_FilterDigestRecompute@<None>#<None>+0x36 stack: 0x20
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]VSI_SetInfo@vmkernel#nover+0x322 stack: 0xnnnnnnnnnnnn
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]UWVMKSyscallUnpackVSI_Set@<None>#<None>+0xef stack: 0x41245111df10
    YYYY-MM-DD TIME cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@<None>#<None>+0x243 stack: 0xnnnnnnnnnnnn
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]User_UWVMKSyscallHandler@vmkernel#nover+0x1d stack: 0xnnnnnnnn
    cpu24:nnnnnn opID=nnnnnnnn)0xnnnnnnnnnnnn:[0xnnnnnnnnnnnn]gate_entry@vmkernel#nover+0x64 stack: 0x0

    El problema está resuelto en esta versión.

  • El host ESXi deja de responder y pierde la conexión con vCenter Server durante los inconvenientes con el almacenamiento en los almacenes de datos de VMFS que no son ATS
    Un host ESXi puede dejar de responder y hacer que las máquinas virtuales dejen de estar accesibles. Además, el host ESXi puede perder la conexión con vCenter Server debido a un interbloqueo durante los inconvenientes con el almacenamiento en los almacenes de datos de VMFS que no son ATS.

    El problema está resuelto en esta versión.

  • El almacenamiento no compartido y el almacenamiento usado no reflejan los valores esperados para las máquinas virtuales
    Cuando varias máquinas virtuales comparten espacio de almacenamiento, la página de resumen de vSphere Client puede mostrar valores incorrectos en los siguientes aspectos:

    • Almacenamiento no compartido en la página de resumen de la máquina virtual

    • Espacio aprovisionado en la página de resumen de datos

    • Espacio usado en la pestaña de máquina virtual del host


    El problema está resuelto en esta versión.

  • Es posible que vSphere no detecte todas las unidades del sistema aunque figuren en el BIOS
    Es posible que vSphere no detecte las 18 unidades del sistema debido a que el controlador lsi_msgpt3 no puede detectar una sola unidad por HBA si hay varios HBA en un mismo sistema.

    El problema está resuelto en esta versión.

  • Las unidades de SCSI conectadas en serie (SAS) mayores de 2 TB no se detectan mediante el controlador lsi-mr3
    El controlador lsi_mr3 no detecta las unidades SAS mayores de 2 TB. Se registran mensajes de error similares a los siguientes:

    cpu35:33396)WARNING: ScsiDeviceIO: 8469: Plugin entry point isSSD() failed on device naa.5000c50057b932a7 from plugin NMP: Error
    cpu35:33396)ScsiDevice: 3025: Failing registration of device 'naa.5000c50057b932a7': failed to get device I/O error attributes.
    cpu35:33396)ScsiEvents: 545: Event Subsystem: Device Events, Destroyed!
    cpu35:33396)WARNING: NMP: nmp_RegisterDevice:673: Registration of NMP device with primary uid 'naa.5000c50057b932a7' failed. I/O error

    En esta versión, se actualizó el controlador lsi_mr3 para solucionar el problema.

  • Volumen de VMFS bloqueado
    El volumen de VMFS en un host ESXi puede permanecer bloqueado debido a errores en las operaciones de metadatos. En el archivo vmkernel.log aparece un mensaje de error similar al siguiente:

    WARNING: LVM: 12976: The volume on the device naa.50002ac002ba0956:1 locked, possibly because some remote host encountered an error during a volume operation and could not recover.

    El problema está resuelto en esta versión.

  • Se produce un error al intentar modificar las directivas de almacenamiento de la máquina virtual creada a partir de un clon vinculado
    Los intentos de modificar las directivas de almacenamiento de las máquinas virtuales encendidas que se crearon a partir de clones vinculados pueden generar un error en vCenter Server similar al siguiente:

    Se produjo un error en el cambio del parámetro de programación.

    El problema está resuelto en esta versión.

  • Los LUN conectados a hosts ESXi 6.0 pueden seguir en el estado de tiempo de espera de APD una vez recuperadas las rutas de acceso
    Cuando se produce un evento de todas las rutas de acceso inactivas (APD), es posible que no se pueda seguir accediendo a los LUN conectados a ESXi una vez recuperadas las rutas de acceso a los LUN. En la secuencia de /var/log/vmkernel.log se ven los siguientes eventos:

    1. El dispositivo ingresa en el modo APD.
    2. El dispositivo sale del modo APD.
    3. Las operaciones del sistema de archivos y de recuperación de latidos del dispositivo presentan el error no encontrado.
    4. El tiempo de espera de APD se agota a pesar de que el dispositivo ya salió del modo APD.

    El problema está resuelto en esta versión.

  • Un nuevo análisis innecesario activado por Virtual SAN puede provocar que el host ESXi y las máquinas virtuales dejen de responder
    Un nuevo análisis periódico innecesario del dispositivo y del sistema de archivos, activado por Virtual SAN, puede provocar que las máquinas virtuales y el host ESXi del entorno dejen de responder de forma aleatoria.

    El problema está resuelto en esta versión.

  • El rendimiento de almacenamiento puede ser lento en las máquinas virtuales que se ejecutan en el almacenamiento de NFS aprovisionado con VSA
    En las máquinas virtuales que se ejecutan en un almacenamiento de NFS aprovisionado con VSA, se observa lentitud en el rendimiento de almacenamiento de NFS. Esto se debe a las operaciones de confirmación demoradas del equipo ESXi en cuanto a las respuestas de lectura de NFS.

    En esta versión, el problema se resolvió deshabilitando las operaciones de confirmación demoradas de los paquetes TCP de la LRO.

  • Clonar máquinas virtuales en diferentes contenedores de almacenamiento hace que el identificador de la máquina virtual de origen se establezca como el identificador de máquina virtual de VVOL inicial de la máquina virtual clonada, lo cual es incorrecto
    Cuando se clona una máquina virtual en diferentes contenedores de almacenamiento, el identificador de máquina virtual de Virtual Volumes (VVOL) de origen se toma como el valor inicial del identificador de máquina virtual de VVOL clonado.

    El problema está resuelto en esta versión.

  • El comando WRITE SAME está deshabilitado en las unidades locales
    El comando WRITE SAME está deshabilitado en las unidades locales de ESXi 6.0 Update 1 dado que algunas unidades de disco no pueden implementar completamente la funcionalidad Write Same y, como consecuencia, se produce un comportamiento erróneo. Como alternativa, puede usar el comando esxcli storage core device vaai status para habilitar o deshabilitar las VAAI en las unidades locales. Consulte el artículo 2131056 de la base de conocimientos para obtener más detalles.

Problemas de copias de seguridad
  • Las instantáneas no se pueden poner en modo inactivo en las máquinas virtuales Linux
    Cuando se crea una instantánea en modo inactivo de una máquina virtual Linux, puede ocurrir un error en la máquina virtual después de la operación de la instantánea. En el archivo vmware.log se registran los siguientes mensajes de error:

    <YYYY-MM-DD>T<TIME>Z| vmx| I120: SnapshotVMXTakeSnapshotComplete: done with snapshot 'smvi_UUID': 0
    <YYYY-MM-DD>T<TIME>Z| vmx| I120: SnapshotVMXTakeSnapshotComplete: Snapshot 0 failed: Failed to quiesce the virtual machine (40).
    <YYYY-MM-DD>T<TIME>Z| vmx| I120: GuestRpcSendTimedOut: message to toolbox timed out.
    <YYYY-MM-DD>T<TIME>Z| vmx| I120: Vix: [18631 guestCommands.c:1926]: Error VIX_E_TOOLS_NOT_RUNNING in MAutomationTranslateGuestRpcError(): VMware Tools are not running in the guest

    El problema está resuelto en esta versión.

Problemas de seguridad
  • Actualización del paquete de Python
    La biblioteca Python de terceros se actualiza a la versión 2.7.9.
  • Actualización de la biblioteca libPNG
    La biblioteca libPNG se ha actualizado a libpng-1.6.16.
  • Actualización de la biblioteca OpenSSL
    La biblioteca userworld OpenSSL de ESXi se actualiza a la versión openssl-1.0.1m.
  • Actualización de la biblioteca libxml2
    La biblioteca userworld libxml2 de ESXi se actualizó a la versión 2.9.2.

  • Actualización de las bibliotecas libPNG y libxml2 de VMware Tools
    Las bibliotecas libPNG y libxml2 de VMware Tools se actualizaron a las versiones 1.2.52 y 2.9.2, respectivamente.
  • Actualización de la biblioteca OpenSSL de VMware Tools
    La biblioteca OpenSSL de VMware Tools se actualizó a la versión openssl-0.9.8zg.
Problemas con la configuración de servidores
  • Se puede establecer el registro de depuración y habilitar el registro de seguimiento para el motor de perfil de host
    El nuevo complemento de perfil de host ahora permite recopilar el registro de depuración y habilitar el registro de seguimiento del motor de perfil de host ESXi cuando el host se inicia desde Active Directory.

  • Se produce un error al intentar reiniciar varias máquinas virtuales cuando se utiliza un dispositivo vGPU de NVIDIA GRID
    Cuando se restablecen muchas máquinas virtuales al mismo tiempo con un dispositivo vGPU de NVIDIA GRID, puede producirse un error en el reinicio de las máquinas virtuales. Puede aparecer un error de reinicio similar al siguiente:

    VMIOP: no hay dispositivo de gráficos disponible para vGPU grid_k100.

    El problema está resuelto en esta versión.

  • Configuración del límite de la CPU de cara al efecto de la máquina virtual en otras máquinas virtuales
    Cuando configura el límite de la CPU de una máquina virtual de un solo procesador, la utilización general del ESXi podría verse reducida debido a un defecto en el planificador de este host. Esto sucede cuando el planificador de ESXi considera que las máquinas virtuales con CPU limitada son ejecutables (cuando no se están ejecutando) durante la creación de estimaciones de carga de CPU. Esto lleva a una decisión incorrecta sobre el equilibrio de carga. Para obtener más detalles, consulte el artículo 2096897 de la base de conocimientos.

    El problema está resuelto en esta versión.

  • Los intentos de crear un patrón primero en entrar, primero en salir y escribir datos en él da como resultado una pantalla de diagnóstico morada
    Cuando crea un patrón FIFO e intenta escribir datos en /tmp/dpafifo, podría mostrarse una pantalla de diagnóstico morada bajo determinadas condiciones.

    El problema está resuelto en esta versión.
  • Informe avanzado de errores deshabilitado al utilizar dispositivos de acceso directo
    Mientras se recopila la información de PCI en un dispositivo para el acceso directo, el informe de errores de ese dispositivo se deshabilita.

    Este problema se resuelve en esta versión al proporcionarse la opción de arranque VMkernel pcipDisablePciErrReporting que permite que los dispositivos PCI de acceso directo notifiquen los errores. De forma predeterminada, la opción se establece en TRUE, lo que implica que los informes de errores están deshabilitados.
  • Es posible que la máquina virtual no muestre un mensaje de advertencia cuando la CPU no está completamente reservada
    Cuando se crea una máquina virtual con el parámetro sched.cpu.latencySensitivity en los valores Alto y Encendido, puede producirse un error en la habilitación de la afinidad exclusiva con las vCPU si la máquina virtual no tiene una reserva de CPU completa.

    En versiones anteriores, la máquina virtual no muestra un mensaje de advertencia cuando la CPU no está completamente reservada.

    El problema está resuelto en esta versión.
  • Comando esxcli system snmp set -p actualizado
    Se configuró el agente SNMP para escuchar en un puerto personalizado mediante el comando esxcli system snmp set -p <port>. En ESXi 6.0 Update 1, se estableció un conjunto aparte de puertos tcp/udp de 32768 a 40959 para uso de terceros. Ya no se permite que otros puertos utilicen este rango.

    Después de ESXi 6.0 Update 1, el agente SNMP no se inicia y muestra un error de comprobación de rango si se establece un puerto personalizado en este rango.
  • Los perfiles de host dejan de admitir cambios simples en los parámetros syscontact o syslocation de SNMP
    Los perfiles de host dejan de admitir cambios simples en los parámetros syscontact o syslocation de SNMP. El problema ocurre cuando el complemento de perfil de host de SNMP aplica solamente un valor único a todos los hosts conectados al perfil de host. Puede aparecer un mensaje de error similar al siguiente:

    Diferencia en la configuración del agente SNMP

    En esta versión, el problema se resolvió habilitando una configuración de valores por host para ciertos parámetros, como syslocation, syscontact, v3targets,v3users y engineid.
Problemas en la administración de máquinas virtuales
  • Los contadores de rendimiento de vSphere Flash Read Cache pueden no estar disponibles en una máquina virtual
    Los contadores de métricas de memoria caché de vFlash, como FlashCacheIOPs, FlashCacheLatency y FlashCacheThroughput, pueden dejar de estar disponibles cuando se habilita CBT en un disco virtual. En el archivo stats.log pueden registrarse mensajes de error similares a los siguientes:

    xxxx-xx-xxTxx:xx:xx.200Z [xxxxxxxx error 'Statssvc.vim.PerformanceManager'] CollectVmVdiskStats : Failed to get VFlash Cache stats for vscsi id scsi0:0 for vm 3
    xxxx-xx-xxTxx:xx:xx.189Z [xxxxxxxx error 'Statssvc.vim.PerformanceManager'] GetVirtualDiskVFCStats: Failed to get VFlash Cache stat values for vmdk scsi0:0. Exception VFlash Cache filename not found!

    El problema está resuelto en esta versión.

  • No se pueden iniciar las máquinas virtuales con una resolución de pantalla más alta y una configuración de varios monitores
    Puede ocurrir un error al intentar iniciar máquinas virtuales con una resolución de pantalla más alta y una configuración de varios monitores desde VDI mediante soluciones PCOIP. Las máquinas virtuales no pueden iniciarse y pasan al estado Apagado. En el archivo /var/log/vmkwarning.log, se verán entradas similares a las siguientes:

    cpu3:xxxxxx)WARNING: World: vm xxxxxx: 12276: vmm0:VDI-STD-005:vmk: vcpu-0:p2m update buffer full
    cpu3:xxxxxx)WARNING: VmMemPf: vm xxxxxx: 652: COW copy failed: pgNum=0x3d108, mpn=0x3fffffffff
    cpu3:xxxxxx)WARNING: VmMemPf: vm xxxxxx: 2626: PhysPageFault failed Failure: pgNum=0x3d108, mpn=0x3fffffffff
    cpu3:xxxxxx)WARNING: UserMem: 10592: PF failed to handle a fault on mmInfo at va 0x60ee6000: Failure. Terminating...
    cpu3:xxxxxx)WARNING: World: vm xxxxxx: 3973: VMMWorld group leader = 255903, members = 1
    cpu7:xxxxxx)WARNING: World: vm xxxxxx: 3973: VMMWorld group leader = 255903, members = 1
    cpu0:xxxxx)WARNING: World: vm xxxxxx: 9604: Panic'd VMM world being reaped, but no core dumped.


    El problema está resuelto en esta versión.

Problemas de configuración de VMware HA y Fault Tolerance
  • Se produce un error al migrar una máquina virtual secundaria con una carga de trabajo pesada
    Puede ocurrir un error al intentar migrar una máquina virtual secundaria con Fault Tolerance habilitado: la máquina virtual puede dejar de responder ante una carga de trabajo pesada.

    El problema está resuelto en esta versión.
Problemas varios
  • Registro excesivo de mensajes de VmkAccess en el registro del vmkernel
    En los sistemas HP con ESXi 6.0, se puede ver un registro excesivo de mensajes de VmkAccess en el archivo vmkernel.log respecto de los siguientes comandos del sistema que operan durante el tiempo de ejecución:

    • esxcfg-scsidevs
    • localcli storage core path list
    • localcli storage core device list


    En los registros de VmkAccess, se ven mensajes de registro excesivo similares a los siguientes:

    cpu7:36122)VmkAccess: 637: localcli: access denied:: dom:appDom(2), obj:forkExecSys(88), mode:syscall_allow(2)
    cpu7:36122)VmkAccess: 922: VMkernel syscall invalid (1025)
    cpu7:36122)VmkAccess: 637: localcli: access denied:: dom:appDom(2), obj:forkExecSys(88), mode:syscall_allow(2)
    cpu7:36122)VmkAccess: 922: VMkernel syscall invalid (1025)
    cpu0:36129)VmkAccess: 637: esxcfg-scsidevs: access denied:: dom:appDom(2), obj:forkExecSys(88), mode:syscall_allow(2)

    El problema está resuelto en esta versión.
  • Nuevo problema No se puede importar un paquete de Python
    Se puede producir un error al importar un paquete de Python en la nueva versión de Python 2.7.9. El problema se produce porque la nueva versión de Python no puede encontrar el módulo pkg_resources.py, de modo que la instrucción import pkg_resources no se realiza correctamente.

    El problema está resuelto en esta versión.
Problemas de VMware Tools
  • Actualización de la biblioteca FUSE
    La biblioteca FUSE se actualizó a libfuse 2.9.4.

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

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

Problemas de actualización

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

  • Nuevo problema SSLv3 permanece habilitado en Auto Deploy después de actualizar de una versión anterior de ESXi 6.0 a ESXi 6.0 Update 1
    Cuando se actualiza de una versión anterior de ESXi 6.0 a ESXi 6.0 Update 1, el protocolo SSLv3 permanece habilitado en Auto Deploy.

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

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

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

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

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

    3. Ejecute el siguiente comando para deshabilitar SSLv3:

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

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

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

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

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

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

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

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

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

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

    Solución alternativa: Ninguna.

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

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

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

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

    1. Agregue los hosts a vCenter Server.

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

    3. Actualice todos los hosts a ESXi 6.0.

    4. Una manualmente al dominio un host actualizado recientemente.

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

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

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

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

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

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

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

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

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

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

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

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

Problemas de redes

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

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

    • Volúmenes virtuales

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

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

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

    • Authentication Proxy

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

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

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

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

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

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

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

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

Problemas de almacenamiento

Problemas con la versión 4.1 de NFS

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

    Solución alternativa: Ninguna.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Solución alternativa: Ninguna.

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

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

Problemas de Virtual Volumes

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

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

Problemas de almacenamiento generales

  • Nuevo problema vSphere Web Client muestra incorrectamente la directiva de almacenamiento como asociada cuando se crea 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.

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

    Solución alternativa: Ninguna.

  • Nuevo problema 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 en Virtual SAN
  • Nuevo problema Al agregar un host al clúster de Virtual SAN, se activa un error del instalador
    Cuando se agrega un host ESXi a un clúster que tiene HA y servicio de mantenimiento de Virtual SAN instalados, es posible encontrar uno de los siguientes errores, o ambos, debido a una condición de carrera en la instalación de VIB:

    • En la vista de tareas, la tarea de configuración de vSphere HA puede generar un mensaje de error similar al siguiente:

      No se puede instalar el servicio del agente vCenter Server. "Error del instalador desconocido"

    • La tarea Habilitar agente puede generar un mensaje de error similar al siguiente:

      No se puede completar la operación. Consulte el registro de eventos para ver más detalles.

    Solución alternativa:

    • Para solucionar el error de configuración de HA, reinicie el host y vuelva a configurar el HA como se muestra aquí:

      Vaya a la vista Hosts y clúster -> haga clic en el nombre del clúster -> pestaña Administrar -> vSphere HA

    • Para solucionar el error en la tarea de habilitación del agente, vaya a la vista de clúster y reintente habilitar el servicio de mantenimiento de VSAN como se muestra aquí:

      Vaya a la vista Hosts y clúster -> haga clic en el nombre del clúster -> pestaña Administrar -> Estado, en la categoría Virtual SAN, y haga clic en el botón Reintentar en la parte superior.

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

Problemas varios
  • Nuevo problema Virtual SAN Observer es compatible con el cifrado SSLv3
    SSLv3 está deshabilitado de forma predeterminada en ESXi 6.0 Update 1; sin embargo, Virtual SAN Observer es aún compatible con SSLv3.

    Solución alternativa: Ninguna.

Problemas de VMware Tools
  • Nuevo problema El módulo vmxnet de compilación en open-vm-tools 9.10 genera un error con la versión de kernel 3.3.0 o superior
    Cuando compila e instala open-vm-tools 9.10, puede encontrarse con varios errores debidos a que vmxnet.c no se puede compilar con la versión del kernel 3.3.0 o superior. Este problema se resuelve en open-vm-tools 9.10.2 y puede instalar open-vm-tools 9.10.2 con cualquier versión del kernel.

    Solución alternativa: Para instalar open-vm-tools 9.10, edite el parámetro vmxnet de ./configure o --without-kernel-modules.

>