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

|

Actualizado: 7 de enero de 2016

ESXi 6.0 Update 1b | 7 de enero de 2016 | Compilación ISO 3380124

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

  • ESXi 6.0 Update 1b ofrece compatibilidad con TLS 1.1 y 1.2 para la mayoría de los componentes de vSphere sin interrumpir la compatibilidad y la interoperabilidad admitidas anteriormente. A continuación, se enumeran algunos de los componentes de vSphere que aún solo son compatibles con TLS 1.0:
    • vSphere Client
    • Virtual SAN Observer en vCenter Server Appliance (vCSA)
    • Syslog en vCSA
    • Auto Deploy en vCSA
    • Auto Deploy/iPXE

    ESXi 6.0 Update 1b ahora admite todas las versiones de TLS (1.0, 1.1 y 1.2), salvo en los casos mencionados anteriormente. Consulte el artículo 2136185 de la base de conocimientos para obtener una lista de los protocolos TLS admitidos.

  • Se incluye compatibilidad de la autenticación de encabezados RPC del cliente NFS 4.1 con el Estándar de cifrado avanzado (Advanced Encryption Standard, AES) con una longitud de clave de 128/256 bits.
    Nota: Consulte la sección de Problemas de seguridad que ya se resolvieron para obtener más información.

  • Esta versión de ESXi 6.0 Update 1b soluciona los problemas documentados en la sección Problemas resueltos.

Versiones anteriores de ESXi 6.0

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

Internacionalización

VMware ESXi 6.0 está disponible en los siguientes idiomas:

  • Inglés
  • Francés
  • Alemán
  • Japonés
  • Coreano
  • Chino simplificado
  • Español
  • Chino tradicional

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

Compatibilidad

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

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

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

Compatibilidad de hardware con ESXi

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

Compatibilidad de dispositivos con ESXi

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

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

Compatibilidad de conmutadores de terceros con ESXi

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

Compatibilidad de sistemas operativos invitados con ESXi

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

Compatibilidad de máquinas virtuales con ESXi

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

Instalación y actualizaciones de esta versión

Notas para la instalación de esta versión

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

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

Modelos de implementación recomendados de vSphere 6.0

VMware recomienda solo dos modelos de implementación:

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

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

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

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

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

Información del sistema operativo host de vCenter

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

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

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

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

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

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

Migrar soluciones de terceros

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

Actualizaciones e instalaciones no permitidas para CPU que no son compatibles

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

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

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

Notas para la actualización de esta versión

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

Componentes de código abierto para VMware vSphere 6.0

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

Avisos de compatibilidad con el producto

  • Base de datos de vCenter Server. Oracle 11g y 12c como bases de datos externas de vCenter Server Appliance cayeron en desuso en la versión de vSphere 6.0. VMware sigue siendo compatible con Oracle 11g y 12c como bases de datos externas de vSphere 6.0. VMware dejará de admitir Oracle 11g y 12c como 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-201601001 incluye los siguientes boletines individuales:

ESXi600-201601401-BG: Actualización de ESXi 6.0 esx-base vib
ESXi600-201601402-BG: Actualización de ESXi 6.0 tools-light vib
ESXi600-201601403-BG: Actualización de ESXi 6.0 ehci-ehci-hcd, misc-drivers vib
ESXi600-201601404-BG: Actualización de ESXi 6.0 net-tg3 vib
ESXi600-201601405-BG: Actualización de ESXi 6.0 net-e1000e vib

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

ESXi600-201601101-SG: Actualización de ESXi 6.0 esx-base vib
ESXi600-201601102-SG: Actualización de ESXi 6.0 tools-light vib

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

ESXi-6.0.0-20160104001-standard
ESXi-6.0.0-20160104001-no-tools

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

ESXi-6.0.0-20160101001s-standard
ESXi-6.0.0-20160101001s-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 de licencias
  • Se produce un error al intentar crear un almacén de datos de VFFS
    vCenter Server impide la creación de un almacén de datos de Virtual Flash File System (VFFS) y muestra un mensaje de error similar al siguiente:

    Licencia no disponible para realizar la operación. Feature 'vSphere Flash Read Cache' is not licensed with this edition

    El problema ocurre debido a una comprobación incorrecta de los permisos de vSphere Flash Read Cache (VFRC).

    El problema está resuelto en esta versión.
Problemas de redes
  • Las máquinas virtuales protegidas con VMware vShield App pierden conectividad de red en los hosts ESXi 6.0
    Las máquinas virtuales protegidas por un firewall de vShield App pierden conectividad de red en los hosts ESXi 6.0. Se mostrarán mensajes de registro similares a los siguientes en los registros del firewall de vShield App:

    YYYY-MM-DDTHH:MM:SS+00:00 vShield-FW-hostname.corp.local kernel: d0: tx hang
    YYYY-MM-DDTHH:MM:SS+00:00 vShield-FW-hostname.corp.local kernel: d0: resetting
    YYYY-MM-DDTHH:MM:SS+00:00 vShield-FW-hostname.corp.local kernel: d0: intr type 3, mode 0, 3 vectors allocated
    YYYY-MM-DDTHH:MM:SS+00:00 vShield-FW-hostname.corp.local kernel: RSS indirection table :

    El problema está resuelto en esta versión. Consulte el artículo 2128069 de la base de conocimientos para obtener más detalles.
  • Se puede producir un error en ESXi 6.0 al intentar cambiar el modo a UPT desde emulación
    Se puede producir un error en ESXi 6.0 al intentar cambiar el modo a acceso directo universal (Universal Pass-through, UPT) desde el modo de emulación. vCenter Server muestra el siguiente mensaje para indicar que DirectPath I/O está deshabilitado:

    The virtual machine does not have full memory reservation which is required to activate DirectPath I/O

    El siguiente mensaje se registra en el archivo vmkernel.log:

    YYYY-MM-DDTHH:MM:SS.820Z cpu11:1000046564)Vmxnet3: VMKDevCanEnterPT:3193: port 0x3000007: memory reservation 0 smaller than guest memory size 262144

    El problema está resuelto en esta versión.
  • El registro de soporte de máquina virtual para un host ESXi tarda mucho en recopilar los registros
    El comando vm-support tarda mucho en recopilar los registros, ya que los registros .dvsData innecesarios se recopilan a partir de todas las carpetas .dvsData de todos los almacenes de datos a los que puede acceder.

    El problema está resuelto en esta versión.
  • Hostd deja de responder en repetidas ocasiones y muestra el error de Señal 11
    Después de configurar cuatro controladoras de interfaz de red (Network Interface Controller, NIC) para dvSwitch, hostd deja de responder en varias ocasiones y muestra un error de Señal 11.

    El problema está resuelto en esta versión.
Problemas de almacenamiento
  • El host ESXi tarda mucho en arrancar y no puede cargar el módulo de SATP VMW_SATP_ALUA
    Un host ESXi puede tardar mucho en arrancar y ser incapaz de cargar el módulo de complemento de tipo de matriz de almacenamiento (Storage Array Type Plug-In, SATP) VMW_SATP_ALUA debido a entradas de LUN obsoletas en el archivo esx.conf del LUN que se encuentra en condición de pérdida permanente de dispositivo (Permanent Device Loss, PDL).

    El problema está resuelto en esta versión.
  • La utilidad esxtop envía estadísticas incorrectas de DAVG/cmd y KAVG/cmd en LUN compatibles con VAAI
    Debido a cálculos incorrectos, la utilidad esxtop envía estadísticas incorrectas en los LUN compatibles con VAAI para DAVG/cmd (latencia promedio del dispositivo por comando) y para KAVG/cmd (latencia promedio de VMkernel de ESXi por comando).

    El problema está resuelto en esta versión.
  • La expansión de VMDK con puesta a cero rápida hace que no se pueda acceder a la máquina virtual
    En ESXi 6.0, los VMDK con puesta a cero rápida se expanden con el formato de puesta a cero rápida, lo cual demora mucho y puede causar que no se pueda acceder a la máquina virtual.

    El problema está resuelto en esta versión.
Problemas en Virtual SAN
  • El objeto huérfano de Virtual SAN se conserva tras observarse un error de disco de APD en el SSD
    Puede que se conserve un objeto huérfano de Virtual SAN después de que se observe un error de disco de todas las rutas de acceso inactivas (All Paths Down, APD) en el disco de estado sólido (Solid State Disk, SSD).

    El problema está resuelto en esta versión.
  • Se puede producir un error de validación de grupo de discos debido a metadatos no válidos de la partición de disco SSD/MD
    Puede aparecer una pantalla de diagnóstico morada si se intenta quitar un disco del grupo de discos de Virtual SAN, ya que se produce un error de validación del grupo de discos debido a metadatos no válidos de la partición de disco SSD/MD. En el archivo vmkernel.log, se registran mensajes de error similares a los siguientes:

    YYYY-MM-DDTHH:MM:SS.772Z cpu13:xxxxx)PLOG: PLOGRelogCleanup:445: RELOG complete uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx lsn xxxxxxx numRelogged 0
    YYYY-MM-DDTHH:MM:SS.772Z cpu33:xxxxx opID=xxxxxxxx)World: 9728: PRDA 0xnnnnnnnnnnnn ss 0x0 ds 0x10b es 0x10b fs 0x0 gs 0x13b
    YYYY-MM-DDTHH:MM:SS.772Z cpu33:xxxxx opID=xxxxxxxx)World: 9730: TR 0xnnnn GDT 0xnnnnnnnnnnnn (0xnnnn) IDT 0xnnnnnnnnnnnn (0xfff)
    .
    .
    .

    El problema está resuelto en esta versión.
  • Se muestra un valor incorrecto de capacidad de disco cuando se agrega espacio nuevo en archivos de componentes finos durante operaciones de E/S de componentes en Virsto Volumes
    Durante las operaciones de E/S en un componente, se puede agregar espacio nuevo en archivos de componentes finos. En los archivos de componentes en Virsto Volumes, la capacidad de disco no se vuelve a calcular y el valor anterior se publica hasta que se crea el nuevo componente.

    El problema está resuelto en esta versión.
  • La congestión de registros de SSD puede reducir el rendimiento de las máquinas virtuales en un clúster de Virtual SAN
    Debido a un problema de congestión de registros del disco de estado sólido (Solid State Disk, SSD), el rendimiento de las máquinas virtuales en un clúster de Virtual SAN puede reducirse. Los nodos de información del sistema de VMkernel (VMkernel System Information, VSI) del SSD indican que el espacio de registro consumido es muy alto y no se reduce.

    El problema está resuelto en esta versión.
Problemas de seguridad
  • Se incluye compatibilidad de la autenticación de encabezados RPC del cliente NFS 4.1 con el Estándar de cifrado avanzado (Advanced Encryption Standard, AES) con una longitud de clave de 128/256 bits
    Se incluye compatibilidad de la autenticación de encabezados RPC del cliente NFS 4.1 con el Estándar de cifrado avanzado (Advanced Encryption Standard, AES) con una longitud de clave de 128/256 bits.
    Nota: El cifrado DES_CBC_MD5 ya no es compatible con el cliente NFS 4.1. Si el cifrado con AES no está habilitado o la versión actual del firmware de la matriz no es compatible con el cifrado con AES, debe actualizar el firmware de la matriz o habilitar el cifrado con AES antes de ejecutar esta actualización de revisión.
  • El protocolo SSLv3 está deshabilitado en el cliente remoto de Syslog de SSL para ESXi
    El cliente de Syslog remoto de SSL para ESXi utiliza el protocolo SSLv3, el cual se considera no seguro. En esta versión, se deshabilita SSLv3 de manera predeterminada y se admite TLS 1.0, 1.1 y 1.2 para resolver este problema.
  • Actualización de la biblioteca OpenSSL
    La biblioteca userworld OpenSSL de ESXi se actualiza a la versión openssl-1.0.1p.
Problemas con la configuración de servidores
  • El host ESXi se reinicia de manera inesperada y le sigue un error de excepción de comprobación de equipo no corregible
    Después de actualizar el host ESXi con 1,5 TB de memoria de la versión 5.1 a la 6.0 en un servidor HP con un procesador AMD, el host puede dejar de responder o reiniciarse inesperadamente. Se escriben excepciones de comprobación de equipo no corregibles (Uncorrectable Machine Check Exception, UMCE) similares a la siguiente en el archivo de registro de administración integrada (Integrated Management Log, IML):

    Critical","CPU","##/##/2014 15:41","##/##/2014 15:41","1","Uncorrectable Machine Check Exception (Board 0, Processor 3, APIC ID 0x00000060, Bank 0x00000004, Status 0xF6000000'00070F0F, Address 0x00000050'61EA3B28, Misc 0x00000000'00000000)",
    Mode of failure: Unexpectedly reboot. IML displays UMCE occurred.

    El problema está resuelto en esta versión.
  • No se puede configurar un host ESXi para la autenticación de Active Directory
    Se puede producir un error al intentar unir un host ESXi con una gran cantidad de CPU a un dominio de Active Directory.

    El problema está resuelto en esta versión. Consulte el artículo 2130395 de la base de conocimientos para obtener más detalles.
  • Se muestra un mensaje de interrupción en un vector no válido como sys-alert
    Tras aplicar la versión de revisión de ESXi, ESXi600-201510001, puede que se generen mensajes de sys-alert similares al siguiente debido a un vector no válido y que se produzcan varios eventos en vCenter Server.

    cpu48:88874)ALERT: IntrCookie: 3411: Interrupt received on invalid vector (cpu 48, vector 73); ignoring it.

    El problema está resuelto en esta versión.
  • La funcionalidad de CBT, QueryChangedDiskAreas API, puede devolver sectores incorrectos
    En ESXi 6.0, cuando se ejecutan copias de seguridad de máquinas virtuales que utilizan el seguimiento de bloques modificados (Changed Block Tracking, CBT), la llamada API de CBT QueryDiskChangedAreas() puede devolver sectores modificados incorrectos, lo cual puede causar que existan copias de seguridad de máquina virtual incrementales incoherentes. El problema ocurre cuando el CBT no puede realizar el seguimiento de bloques modificados en las máquinas virtuales que realizan operaciones de E/S durante la consolidación de snapshots.

    El problema está resuelto en esta versión. Consulte el artículo 2136854 de la base de conocimientos para obtener más detalles.
Problemas en la administración de máquinas virtuales
  • El comando esxcli vm process list command puede mostrar el nombre anterior de la máquina virtual después de cambiar el nombre de una máquina virtual encendida
    Después de cambiar el nombre de una máquina virtual encendida, si se ejecuta el comando esxcli vm process list para obtener del host la lista de las máquinas virtuales en ejecución, la lista puede incluir el nombre anterior de la máquina virtual.

    El problema está resuelto en esta versión.
  • vCenter Server puede dejar de responder cuando el host ESXi pierde conectividad con el servidor Syslog
    Cuando un host ESXi pierde conectividad con un servidor Syslog remoto, los eventos GeneralHostWarningEvent y AlarmStatusChangedEvent registran demasiados mensajes de alerta indefinidamente. Como resultado, las tablas vpx_event y vpx_event_arg llenan la base de datos de vCenter. Este problema causa alta latencia de vCenter, por lo que vCenter Server deja de responder.

    El problema está resuelto en esta versión.
  • Se produce un error en el VMX de la máquina virtual Windows 10
    Se produce un error similar al siguiente en el proceso del VMX de la máquina virtual Windows 10 en el archivo vmware.log:

    NOT_REACHED bora/devices/ahci/ahci_user.c:1530

    El problema está resuelto en esta versión.
  • Se puede producir un error en el VMX al ejecutar algunas aplicaciones 3D
    Al ejecutar algunas aplicaciones 3D, se puede producir un error en el VMX. En el archivo vmware.log, se registran mensajes de error similares a los siguientes:

    xxxx-xx-xxTxx:xx:xx.xxxZ| svga| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (svga)
    xxxx-xx-xxTxx:xx:xx.xxxZ| svga| I120+ NOT_REACHED bora/mks/hostops/shim/shimOps.c:674

    El problema está resuelto en esta versión.
Problemas de vMotion y Storage vMotion
  • La máquina virtual deja de responder durante la consolidación de snapshots en ESXi 6.0
    Al consolidar un snapshot de máquina virtual alojado en un host ESXi 6.0, la máquina virtual deja de responder y crea un archivo vmx-zdump en el directorio de trabajo de la máquina virtual. El archivo vmkernel.log, que se encuentra en var/log/vmkernel.log, muestra mensajes de error similares a los siguientes:

    cpu17:xxxxxxxx)SVM: xxxx: Error destroying device xxxxxxxx-xxxxxxxx-svmmirror (Busy)
    cpu2:xxxxx)FSS: xxxx: No FS driver claimed device 'xxxxxxxx-xxxxxxxx-svmmirror': No filesystem on the device
    cpu2:xxxxx)FSS: xxxx: No FS driver claimed device 'control': No filesystem on the device

    El problema está resuelto en esta versión. Consulte el artículo 2135631 de la base de conocimientos para obtener más detalles.
  • Se produce un error en la instancia de Storage vMotion de una máquina virtual cuyo nombre comience por "core"
    Se puede producir un error al intentar realizar una migración en frío o de Storage vMotion de una máquina virtual cuyo nombre comience por "core". vSphere Web Client muestra mensajes de error similares al siguiente:

    Relocate virtual machine core01 Cannot complete the operation because the file or folder
    ds:///vmfs/volumes/xxxxxxxx-xxxxxxxx-xxxx-xxxxxxxxxxxx/core01/core01-xxxxxxxx.hlog already exists
    Checking destination files for conflicts Administrator vCenter_Server_name

    El problema está resuelto en esta versión. Consulte el artículo 2130819 de la base de conocimientos para obtener más detalles.
Problemas de configuración de VMware HA y Fault Tolerance
  • No se pueden iniciar las máquinas virtuales después de una conmutación por error de High Availability
    Después de un error de host ESXi, cuando HA intenta iniciar las máquinas virtuales afectadas en otros hosts, algunas de las máquinas virtuales pueden dejar de responder durante el arranque.

    El problema está resuelto en esta versión.
Problemas varios
  • Los grupos de seguridad universal no se muestran en la interfaz de usuario de asignación de permisos de ESXi
    Si se intentan asignar permisos en un host ESXi, solo se muestran los grupos de seguridad global y no se muestran los grupos de seguridad universal en la lista Seleccionar usuarios y grupos.

    El problema está resuelto en esta versión.
  • Se escriben muchas advertencias en el archivo de registro de VMkernel en la ruta de acceso de error de la página de máquina virtual, lo que puede producir un error en el host
    Si se intentan encender máquinas virtuales con una resolución de pantalla superior o con varias pantallas, se pueden escribir varios mensajes de advertencia similares a los siguientes en el archivo vmkernel.log, lo que puede producir un error en el host debido a una carga de registro excesiva:

    XXXX-XX-XXTXX:XX:XX.XXXZ cpuXX:XXXXXXX)WARNING: VmMemPf: vm XXXXXXX: 654: COW copy failed: pgNum=0xXXXXX, mpn=0x3fffffffff
    XXXX-XX-XXTXX:XX:XX.XXXZ cpuXX:XXXXXXX)WARNING: VmMemPf: vm XXXXXXX: 654: COW copy failed: pgNum=0xXXXXX, mpn=0x3fffffffff

    El problema está resuelto en esta versión.
Problemas de VMware Tools
  • Se produce un error con el código 21009 al intentar actualizar VMware Tools
    Al intentar actualizar una instancia de VMware Tools de una máquina virtual que se ejecuta en VMware ESXi 6.0, se produce el siguiente error en la actualización automática:

    vix error code = 21009

    El problema ocurre si los archivos de invitado siguientes se encuentran en la máquina virtual:

    C:\Windows\\Temp\\vmware-SYSTEM\\VMwareToolsUpgrader.exe

    Máquina virtual de Red Hat Enterprise Linux:

    /tmp/vmware-root

    El problema está resuelto en esta versión.
  • Se producen errores de manera aleatoria en las máquinas virtuales que ejecutan SAP
    Se pueden producir errores de manera aleatoria en las máquinas virtuales que ejecutan SAP en vmx.zdump si se ejecutan demasiados comandos de estadísticas de VMware Tools en la máquina virtual. En el archivo vmware.log se registra un mensaje de error similar al siguiente:

    CoreDump error line 2160, error Cannot allocate memory.

    El problema está resuelto en esta versión. Consulte el artículo 2137310 de la base de conocimientos para obtener más detalles.

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 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.

  • 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

  • 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.

  • 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.

  • 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
  • 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
  • Nuevo problema No se puede conectar el host ESXi 6.0 con TLS 1.1 y 1.2 que solo están habilitadas para vCenter Virtual Appliance 5.5
    Se produce un error al intentar conectar el host ESXi 6.0 con TLS 1.1 y 1.2 que solo están habilitadas para vCenter Virtual Appliance (VCVA) 5.5, ya que VCVA solo admite los protocolos SSLv3 y TLSv1.0.

    Solución alternativa: Habilite los protocolos SSLv3 o TLS1.0 en el host ESXi 6.0 para establecer una conexión con vCenter Virtual Appliance 5.5.

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

>