This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

ESXi 7.0 Update 2 | 9 de marzo de 2021 | ISO Build 17630552

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

  • vSphere Fault Tolerance admite el cifrado de máquinas virtuales de vSphere: A partir de vSphere 7.0 Update 2, vSphere FT admite el cifrado de máquinas virtuales. El cifrado en invitados y basado en matrices no depende ni interfiere con el cifrado de máquinas virtuales, pero al tener varias capas de cifrado se utilizan recursos informáticos adicionales, lo que puede afectar al rendimiento de la máquina virtual. El impacto varía según el hardware, así como la cantidad y el tipo de E/S, por lo que VMware no puede cuantificarlo, pero el impacto general es insignificante para la mayoría de las cargas de trabajo. La eficacia y la compatibilidad de las funciones de almacenamiento back-end, como la desduplicación, la compresión y la replicación, también pueden verse afectadas por el cifrado de máquinas virtuales y se deben tener en cuenta las compensaciones de almacenamiento. Para obtener más información, consulte Cifrado de máquinas virtuales y Prácticas recomendadas de cifrado de máquinas virtuales.
     
  • ESXi 7.0 Update 2 admite vSphere Quick Boot en los siguientes servidores:
    • Dell Inc.
      • PowerEdge M830
      • PowerEdge R830
    • HPE
      • ProLiant XL675d Gen10 Plus
    • Lenovo 
      • ThinkSystem SR 635
      • ThinkSystem SR 655
         
  • Algunos archivos de configuración ESXi se convierten en archivos de solo lectura: A partir de ESXi 7.0 Update 2, la configuración que anteriormente se almacenaba en los archivos /etc/keymap, /etc/vmware/welcome, /etc/sfcb/sfcb.cfg, /etc/vmware/snmp.xml, /etc/vmware/logfilters, /etc/vmsyslog.conf y /etc/vmsyslog.conf.d/*.conf ahora se encuentra en la base de datos de ConfigStore. Esta configuración solo se puede modificar mediante comandos ESXCLI, nunca editando los archivos. Para obtener más información, consulte los artículos 82637 y 82638 de la base de conocimientos de VMware.
     
  • Estadísticas de VMware vSphere Virtual Volumes para mejorar la depuración: Con ESXi 7.0 Update 2, puede realizar un seguimiento de las estadísticas de rendimiento de vSphere Virtual Volumes para identificar rápidamente problemas como la latencia en las respuestas de proveedores VASA externos. Mediante el uso de un conjunto de comandos, puede obtener estadísticas de todos los proveedores VASA del sistema, para un espacio de nombres o una entidad especificados en el espacio de nombres dado, o habilitar el seguimiento de estadísticas para el espacio de nombres completo. Para obtener más información, consulte Recopilar información estadística para VVols.
     
  • Compatibilidad con la arquitectura NVIDIA Ampere: vSphere 7.0 Update 2 incorpora compatibilidad con la arquitectura NVIDIA Ampere, que le permite realizar la capacitación de IA/ML de alta gama, y cargas de trabajo de inferencia de ML, mediante el uso de la capacidad acelerada de la GPU A100. Además, vSphere 7.0 Update 2 mejora el uso compartido y la utilización de GPU, ya que admite la tecnología de GPU de varias instancias (Multi-Instance GPU, MIG). Con vSphere 7.0 Update 2, también experimentará una mejora de rendimiento en la comunicación entre dispositivos, basada en la funcionalidad NVIDIA GPUDirect existente, al habilitar los servicios de traducción de direcciones (ATS) y los servicios de control de acceso (ACS) en la capa de bus PCIe del kernel de ESXi.
     
  • Compatibilidad con NIC Mellanox ConnectX-6 200G: ESXi 7.0 Update 2 es compatible con las NIC de la familia MT28908 de Mellanox Technologies (ConnectX-6) y la familia MT2892 de Mellanox Technologies (ConnectX-6 Dx) 200G.
     
  • Mejoras de rendimiento para las CPU AMD Zen: Con ESXi 7.0 Update 2, las optimizaciones inmediatas pueden aumentar el rendimiento de las CPU AMD Zen hasta en un 30 % en varios bancos de pruebas. El programador de ESXi actualizado aprovecha al máximo la arquitectura AMD NUMA para tomar las decisiones de colocación más adecuadas para las máquinas virtuales y los contenedores. Las optimizaciones de CPU de AMD Zen permiten un mayor número de máquinas virtuales o implementaciones de contenedores con un mejor rendimiento.
     
  • Menos recursos informáticos y una latencia de E/S reducida, así como vibración para cargas de trabajo sensibles a la latencia: Las cargas de trabajo sensibles a la latencia, como en las aplicaciones financieras y de telecomunicaciones, pueden experimentar beneficios significativos en el rendimiento de latencia de E/S y optimizaciones de vibración en ESXi 7.0 Update 2. Las optimizaciones reducen las interferencias y las fuentes de vibración para proporcionar un entorno de tiempo de ejecución coherente. Con ESXi 7.0 Update 2, también puede observar una mayor velocidad en la entrega de interrupciones para dispositivos de acceso directo.
     
  • Pods de vSphere confidenciales en un clúster supervisor en vSphere with Tanzu: A partir de vSphere 7.0 Update 2, puede ejecutar pods de vSphere confidenciales, lo que mantiene la memoria del sistema operativo invitado cifrada y protegida contra el acceso desde el hipervisor en un clúster supervisor de vSphere with Tanzu. Puede configurar pods de vSphere confidenciales si agrega el estado cifrado de SEV (Secure Encrypted Virtualization-Encrypted State, SEV-ES) como una mejora de seguridad adicional. Para obtener más información, consulte Implementar un pod de vSphere confidencial.
     
  • Actualizaciones rápidas de vSphere Lifecycle Manager: A partir de vSphere 7.0 Update 2, puede reducir significativamente el tiempo de actualización y el tiempo de inactividad del sistema, así como minimizar el tiempo de arranque del sistema mediante la suspensión de las máquinas virtuales en la memoria y el uso de la funcionalidad Quick Boot. Puede configurar vSphere Lifecycle Manager para que suspenda las máquinas virtuales en la memoria en lugar de migrarlas, apagarlas o suspenderlas en el disco cuando actualice un host ESXi. Para obtener más información, consulte Configurar vSphere Lifecycle Manager para actualizaciones rápidas.
     
  • Tráfico de registro cifrado de Fault Tolerance: A partir de vSphere 7.0 Update 2, puede cifrar el tráfico de registro de Fault Tolerance para mejorar la seguridad. vSphere Fault Tolerance realiza comprobaciones frecuentes entre las máquinas virtuales principal y secundaria para habilitar la reanudación rápida a partir del último punto de control correcto. El punto de control contiene el estado de la máquina virtual que se modificó desde el punto de control anterior. Al cifrar el tráfico de registro, se evitan el acceso malintencionado o los ataques de red.

Versiones anteriores de ESXi 7.0

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

Para obtener información sobre internacionalización, compatibilidad y componentes de código abierto, consulte las Notas de la versión de VMware vSphere 7.0.

Revisiones incluidas en esta versión

Esta versión de ESXi 7.0 Update 2 tiene las siguientes revisiones:

Detalles de la compilación

Nombre de archivo de descarga: VMware-ESXi-7.0U2-17630552-depot
Compilación: 17630552
Tamaño de descarga: 390,9 MB
md5sum: 4eae7823678cc7c57785e4539fe89d81
sha1checksum: 7c6b70a0190bd78bcf118f856cf9c60b4ad7d4b5
Reinicio requerido del host: Sí
Migración de máquina virtual o apagado requeridos: Sí

IMPORTANTE:

  • En el complemento Lifecycle Manager de vSphere Client, la fecha de la versión de la imagen base, los perfiles y los componentes de ESXi 7.0.2 es 2021-02-17. Esto se espera. Para asegurarse de que puede utilizar los filtros correctos por fecha de publicación, solo la fecha de publicación del boletín acumulativo de actualizaciones es 2021-03-09.
     
  • A partir de vSphere 7.0, VMware utiliza componentes para empaquetar los VIB junto con los boletines. Los boletines de ESXi y esx-update dependen entre sí. Incluya siempre a ambos en una sola línea base de revisión de host ESXi, o bien incluya el boletín acumulativo en la línea base para evitar errores durante la aplicación de revisiones de hosts. 
  • Cuando se aplican revisiones de hosts ESXi mediante VMware Update Manager desde una versión anterior a ESXi 7.0 Update 2, se recomienda encarecidamente utilizar el boletín acumulativo de actualizaciones en la línea base de revisión. Si no puede utilizar el boletín acumulativo de actualizaciones, asegúrese de incluir todos los paquetes a continuación en la línea base de revisión. Si los siguientes paquetes no se incluyen en la línea base, se produce un error en la operación de actualización:
    • VMware-vmkusb_0.1-1vmw.701.0.0.16850804 o una versión superior
    • VMware-vmkata_0.1-1vmw.701.0.0.16850804 o una versión superior
    • VMware-vmkfcoe_1.0.0.2-1vmw.701.0.0.16850804 o una versión superior
    • VMware-NVMeoF-RDMA_1.0.1.2-1vmw.701.0.0.16850804 o una versión superior


Boletín acumulativo de actualizaciones

Este boletín acumulativo de actualizaciones contiene los VIB más recientes con todas las revisiones posteriores a la publicación inicial de ESXi 7.0.

Identificador del boletín Categoría Gravedad
ESXi70U2-17630552 Mejora Importante

Perfiles de imagen

Las versiones de revisiones y actualizaciones de VMware contienen perfiles de imagen general y de nivel crítico. El perfil de imagen general de la versión se aplica a las nuevas correcciones de errores.

Nombre del perfil de imagen
ESXi-7.0.2-17630552-standard
ESXi-7.0.2-17630552-no-tools

Imagen ESXi

Nombre y versión Fecha de versión Categoría Detalles
ESXi_7.0.2-0.0.17630552 03/09/2021 General Imagen del corrector de error

Para obtener información sobre los componentes individuales y boletines, consulte la página Revisiones de producto y la sección Problemas resueltos.

Descarga e instalación de revisiones

En vSphere 7.x, el componente Update Manager, que se utiliza para administrar vSphere Update Manager, se reemplaza con el componente Lifecycle Manager. Las operaciones administrativas de vSphere Update Manager aún están disponibles bajo el componente Lifecycle Manager, junto con nuevas capacidades de vSphere Lifecycle Manager.
La manera típica de aplicar las revisiones a los hosts de ESXi 7.x es utilizando vSphere Lifecycle Manager. Para obtener más detalles, consulte Información sobre vSphere Lifecycle Manager y Líneas base e imágenes de vSphere Lifecycle Manager.
También puede actualizar los hosts ESXi sin usar el complemento Lifecycle Manager y, en su lugar, usar un perfil de imagen. Para ello, debe descargar manualmente el archivo ZIP del paquete sin conexión de revisiones desde la página de descarga de VMware o la página de revisiones del producto y usar el comando esxcli software profile update.
Para obtener más información, consulte la guía Actualizar los hosts a través de comandos ESXCLI y Actualizar VMware ESXi.

Avisos de compatibilidad con el producto

  • El controlador de red i40en de la bandeja de entrada cambia de nombre: A partir de vSphere 7.0 Update 2, el controlador de red i40en de la bandeja de entrada para ESXi cambia de nombre a i40enu.
  • Eliminación de SHA1 del shell seguro (SSH): En vSphere 7.0 Update 2, el algoritmo de hash criptográfico SHA-1 se elimina de la configuración predeterminada de SSHD.
  • REST API de vSphere 6.0 a 6.7 en desuso: VMware deja de usar las REST API de vSphere 6.0 a 6.7 provistas bajo /rest y se las denomina "REST API antiguas". Con vSphere 7.0 Update 2, las REST API se proveen bajo /api y se denominan "REST API nuevas". Para obtener más información, consulte el artículo vSphere 7 Update 2: Modernización de REST API y el artículo de la base de conocimientos de VMware 83022.
  • Intención de dejar de utilizar SHA-1: El algoritmo de hash de cifrado SHA-1 se dejará de utilizar en una versión futura de vSphere. SHA-1 y MD5, que ya se dejó de utilizar, tienen debilidades conocidas. Asimismo, se demostró que se produjeron ataques prácticos contra estos.
  • Formatos estándar de archivos de registro y transmisiones de syslog: En una próxima versión principal de ESXi, VMware tiene pensado estandarizar los formatos de todos los archivos de registro de ESXi y las transmisiones de syslog. Esta estandarización afecta a los metadatos asociados con cada línea de archivos de registro o cada transmisión de syslog. Por ejemplo, la marca de tiempo, el identificador de origen programático, la gravedad del mensaje y los datos del identificador de operación. Para obtener más información, visite https://core.vmware.com/esxi-log-message-formats. 

Problemas resueltos

Los problemas resueltos se agrupan del siguiente modo:

Actualizaciones de microcódigo de Intel
  • ESXi 7.0 Update 2 incluye las siguientes actualizaciones de microcódigo de Intel:
    Nombre de código FMS ID de PLT Rev. de MCU Fecha de MCU Nombres de marcas
    Nehalem EP 0x106a5 0x03 0x0000001d 11/5/2018 Intel Xeon serie 35xx;
    Intel Xeon serie 55xx
    Lynnfield 0x106e5 0x13 0x0000000a 8/5/2018 Intel Xeon serie 34xx Lynnfield
    Clarkdale 0x20652 0x12 0x00000011 8/5/2018 Intel i3/i5 serie Clarkdale;
    Intel Xeon serie 34xx Clarkdale
    Arrandale 0x20655 0x92 0x00000007 23/4/2018 Procesador Intel Core i7-620LE
    Sandy Bridge DT 0x206a7 0x12 0x0000002f 17/2/2019 Intel Xeon serie E3-1100;
    Intel Xeon serie E3-1200;
    Intel serie i7-2655-LE;
    Intel serie i3-2100
    Westmere EP 0x206c2 0x03 0x0000001f 8/5/2018 Intel Xeon serie 56xx;
    Intel Xeon serie 36xx
    Sandy Bridge EP 0x206d6 0x6d 0x00000621 4/3/2020 Intel Pentium serie 1400;
    Intel Xeon serie E5-1400;
    Intel Xeon serie E5-1600;
    Intel Xeon serie E5-2400;
    Intel Xeon serie E5-2600;
    Intel Xeon serie E5-4600
    Sandy Bridge EP 0x206d7 0x6d 0x0000071a 24/3/2020 Intel Pentium serie 1400;
    Intel Xeon serie E5-1400;
    Intel Xeon serie E5-1600;
    Intel Xeon serie E5-2400;
    Intel Xeon serie E5-2600;
    Intel Xeon serie E5-4600
    Nehalem EX 0x206e6 0x04 0x0000000d 15/5/2018 Intel Xeon serie 65xx;
    Intel Xeon serie 75xx
    Westmere EX 0x206f2 0x05 0x0000003b 16/5/2018 Intel Xeon serie E7-8800;
    Intel Xeon serie E7-4800;
    Intel Xeon serie E7-2800
    Ivy Bridge DT 0x306a9 0x12 0x00000021 13/2/2019 Intel serie i3-3200;
    Intel i7-3500-LE/UE;
    Intel i7-3600-QE;
    Intel Xeon serie E3-1200-v2;
    Intel Xeon serie E3-1100-C-v2;
    Intel Pentium B925C
    Haswell DT 0x306c3 0x32 0x00000028 12/11/2019 Intel Xeon serie E3-1200-v3;
    Intel serie i7-4700-EQ;
    Intel serie i5-4500-TE;
    Intel serie i3-4300
    Ivy Bridge EP 0x306e4 0xed 0x0000042e 14/3/2019 Intel Xeon serie E5-4600-v2;
    Intel Xeon serie E5-2600-v2;
    Intel Xeon serie E5-2400-v2;
    Intel Xeon serie E5-1600-v2;
    Intel Xeon serie E5-1400-v2
    Ivy Bridge EX 0x306e7 0xed 0x00000715 14/3/2019 Intel Xeon serie E7-8800/4800/2800-v2
    Haswell EP 0x306f2 0x6f 0x00000044 27/5/2020 Intel Xeon serie E5-4600-v3;
    Intel Xeon serie E5-2600-v3;
    Intel Xeon serie E5-2400-v3;
    Intel Xeon serie E5-1600-v3;
    Intel Xeon serie E5-1400-v3
    Haswell EX 0x306f4 0x80 0x00000016 17/06/2019 Intel Xeon serie E7-8800/4800-v3
    Broadwell H 0x40671 0x22 0x00000022 12/11/2019 Intel Core i7-5700EQ;
    Intel Xeon serie E3-1200-v4
    Avoton 0x406d8 0x01 0x0000012d 16/9/2019 Intel Atom serie C2300;
    Intel Atom serie C2500;
    Intel Atom serie C2700
    Broadwell EP/EX 0x406f1 0xef 0x0b000038 18/6/2019 Intel Xeon serie E7-8800/4800-v4;
    Intel Xeon serie E5-4600-v4;
    Intel Xeon serie E5-2600-v4;
    Intel Xeon serie E5-1600-v4
    Skylake SP 0x50654 0xb7 0x02006a08 16/6/2020 Intel Xeon serie Platinum 8100;
    Intel Xeon serie Gold 6100/5100, Silver 4100, Bronze 3100;
    Intel Xeon serie D-2100;
    Intel Xeon serie D-1600;
    Intel Xeon serie W-3100;
    Intel Xeon serie W-2100
    Cascade Lake B-0 0x50656 0xbf 0x04003003 18/6/2020 Intel Xeon serie Platinum 9200/8200;
    Intel Xeon Gold 6200/5200;
    Intel Xeon Silver 4200/Bronze 3200;
    Intel Xeon W-3200
    Cascade Lake 0x50657 0xbf 0x05003003 18/6/2020 Intel Xeon serie Platinum 9200/8200;
    Intel Xeon Gold 6200/5200;
    Intel Xeon Silver 4200/Bronze 3200;
    Intel Xeon W-3200
    Cooper Lake 0x5065b 0xbf 0x0700001f 17/9/2020 Intel Xeon serie Platinum 8300;
    Intel Xeon Gold 6300/5300
    Broadwell DE 0x50662 0x10 0x0000001c 17/06/2019 Intel Xeon serie D-1500
    Broadwell DE 0x50663 0x10 0x07000019 17/06/2019 Intel Xeon serie D-1500
    Broadwell DE 0x50664 0x10 0x0f000017 17/06/2019 Intel Xeon serie D-1500
    Broadwell NS 0x50665 0x10 0x0e00000f 17/06/2019 Intel Xeon serie D-1600
    Skylake H/S 0x506e3 0x36 0x000000e2 14/7/2020 Intel Xeon serie E3-1500-v5;
    Intel Xeon serie E3-1200-v5
    Denverton 0x506f1 0x01 0x00000032 7/3/2020 Intel Atom serie C3000
    Snow Ridge 0x80665 0x01 0x0b000007 25/2/2020 Intel Atom serie P5000
    Kaby Lake H/S/X 0x906e9 0x2a 0x000000de 26/5/2020 Intel Xeon serie E3-1200-v6;
    Intel Xeon serie E3-1500-v6
    Coffee Lake 0x906ea 0x22 0x000000de 25/5/2020 Intel Xeon serie E-2100;
    Intel Xeon serie E-2200 (4 o 6 núcleos)
    Coffee Lake 0x906eb 0x02 0x000000de 25/5/2020 Intel Xeon serie E-2100
    Coffee Lake 0x906ec 0x22 0x000000de 3/6/2020 Intel Xeon serie E-2100
    Coffee Lake Refresh 0x906ed 0x22 0x000000de 24/5/2020 Intel Xeon serie E-2200 (8 núcleos)
Problemas de almacenamiento
  • Una vez resueltas las condiciones de APD o PDL, es posible que no se pueda acceder al almacén de datos de VMFS con compatibilidad habilitada para discos virtuales agrupados en clúster

    Este problema solo se puede producir en los almacenes de datos en los que se habilitó la compatibilidad con discos virtuales agrupados en clúster. Cuando el almacén de datos se recupera de una condición de todas las rutas desactivadas (All Paths Down, APD) o de pérdida de dispositivo permanente (PDL), no se puede acceder a él. Es posible que el registro de VMkernel muestre varios mensajes SCSI3 reservation conflict similares a los siguientes:

    2020-02-18T07:41:10.273Z cpu22:1001391219)ScsiDeviceIO: vm 1001391219: SCSIDeviceCmdCompleteCB:2972: Reservation conflict retries 544 for command 0x45ba814b8340 (op: 0x89) to device "naa.624a9370b97601e346f64ba900024d53"

    El problema puede ocurrir porque el host ESXi que participa en el clúster pierde las reservas de SCSI para el almacén de datos y no siempre puede volver a adquirirlas automáticamente después de que se recupera el almacén de datos.

    El problema está resuelto en esta versión.

Problemas de Auto Deploy
  • PR 2710383: Si implementa un host ESXi mediante la instalación con estado de vSphere Auto Deploy, las configuraciones de ESXi migradas a la base de datos de ConfigStore se pierden durante la actualización

    Si implementa un host ESXi mediante la función de instalación con estado de Auto Deploy, no se elimina una opción que indique el arranque de la instalación con estado en el archivo boot.cfg y entra en conflicto con el estado persistente de la base de datos de ConfigStore. Como resultado, las configuraciones de ESXi migradas a la base de datos de ConfigStore se pierden durante la actualización a ESXi 7.x.

    El problema está resuelto en esta versión.

Problemas de redes
  • PR 2696435: No puede usar el etiquetado de invitado virtual (virtual guest tagging, VGT) de forma predeterminada en un entorno de SR-IOV

    Con el controlador i40enu en ESXi 7.0 Update 2, no puede utilizar VGT de forma predeterminada para evitar funciones virtuales (virtual functions, VF) de SR-IOV que no sean de confianza para transmitir o recibir paquetes etiquetados con un identificador de VLAN diferente de la VLAN de puerto. 
    Debe establecer todas las funciones virtuales en modo de confianza mediante el siguiente parámetro de módulo:
    esxcli system module parameters set -a -m i40enu -p "trust_all_vfs=1,1,1,...

    El problema está resuelto en esta versión.

Problemas varios
  • NUEVO: Si el proceso Xorg no se reinicia mientras un host ESXi sale del modo de mantenimiento, es posible que el servicio hostd deje de responder

    Si el proceso Xorg no se reinicia mientras un host ESXi sale del modo de mantenimiento, es posible que el servicio hostd deje de responder, ya que no puede completar la operación de salida.

    El problema está resuelto en esta versión.

Problemas de actualización
  • NUEVO: Si un sistema vCenter Server es de la versión 7.0, se producirá un error en las actualizaciones de hosts ESXi a una versión posterior mediante vSphere Lifecycle Manager y una imagen ISO

    Si utiliza una imagen ISO para actualizar los hosts ESXi a una versión posterior a la 7.0 mediante vSphere Lifecycle Manager, y el sistema vCenter Server sigue teniendo la versión 7.0, se produce un error en la actualización. En vSphere Client, se muestra un error No se admite la actualización para el host.

    El problema está resuelto en esta versión.

Problemas conocidos

Los problemas conocidos se agrupan del siguiente modo:

Problemas de redes
  • NUEVO: Después de una actualización a ESXi 7.0 Update 2, los VIB de los controladores de red i40en asíncronos para ESXi se omiten o se revierten al controlador i40enu de la bandeja de entrada de VMware

    A partir de vSphere 7.0 Update 2, el nombre del controlador i40en de la bandeja de entrada se cambió a i40enu. Como resultado, si intenta instalar un controlador asíncrono de socio i40en, el VIB de i40en se omite o se revierte al controlador de la bandeja de entrada i40enu de VMware.

    Solución alternativa: Para completar la actualización a ESXi 7.0 Update 2, debe crear una imagen personalizada que reemplace la versión del componente i40en 1.8.1.136-1vmw.702.0.0.17630552 con la versión de componente i40en Intel-i40en_1.10.9.0-1OEM.700.1.0.15525992 o superior. Para obtener más información, consulte Personalizar instalaciones con vSphere ESXi Image Builder.

  • NUEVO: Cuando se establece la negociación automática en un adaptador de red, se puede producir un error en el dispositivo

    En algunos entornos, si establece la velocidad de vínculo en negociación automática para los adaptadores de red mediante el comando esxcli network nic set -a -n vmmicx, es posible que los dispositivos fallen y la conectividad no se recupere con un reinicio. El problema es específico de una combinación de algunos adaptadores de red Intel X710/X722, un módulo SFP+ y un conmutador físico, donde no se admite la negociación automática de escenarios de velocidad/dúplex.

    Solución alternativa: Asegúrese de utilizar un módulo SFP+ de la marca Intel. Como alternativa, use un cable de cobre de conexión directa (Direct Attach Copper, DAC).

  • Los adaptadores de red de RDMA paravirtual (PVRDMA) no admiten directivas de redes NSX

    Si configura un puerto virtual distribuido NSX para usarlo en el tráfico de PVRDMA, el tráfico del protocolo RDMA a través de los adaptadores de red de PVRDMA no cumple con las directivas de redes NSX.

    Solución alternativa: No configure los puertos virtuales distribuidos NSX para usarlos en el tráfico de PVRDMA.

  • Los adaptadores de red x2542 y x2541 de Solarflare configurados en el modo de puerto 1x100G alcanzan un rendimiento de hasta 70 Gbps en un entorno de vSphere

    vSphere 7.0 Update 2 admite adaptadores de red Solarflare x2542 y x2541 configurados en el modo de puerto 1x100G. Sin embargo, es posible que observe una limitación de hardware en los dispositivos que provoque que el rendimiento real sea de hasta 70 Gbps en un entorno de vSphere.

    Solución alternativa: Ninguna

  • Se puede producir un error en el tráfico de VLAN después de restablecer una NIC

    Una NIC con el identificador de dispositivo PCI 8086:1537 puede dejar de enviar y recibir paquetes etiquetados de VLAN después de un restablecimiento; por ejemplo, con un comando vsish -e set /net/pNics/vmnic0/reset 1.

    Solución alternativa: Evite restablecer la NIC. Si ya tiene este problema, use los siguientes comandos para restaurar la capacidad de VLAN; por ejemplo, en vmnic0:
    # esxcli network nic software set --tagging=1 -n vmnic0
    # esxcli network nic software set --tagging=0 -n vmnic0

  • Cualquier cambio que se haga en la configuración del equilibrador de NetQueue hace que NetQueue se deshabilite después de reiniciar el host ESXi

    Cualquier cambio en la configuración del equilibrador de NetQueue mediante el comando esxcli/localcli network nic queue loadbalancer set -n <nicname> --<lb_setting> hace que NetQueue, que está habilitado de forma predeterminada, se deshabilite después de reiniciar un host ESXi.

    Solución alternativa: Después de cambiar la configuración del equilibrador de NetQueue y reiniciar el host, use el comando configstorecli config current get -c esx -g network -k nics para recuperar los datos de ConfigStore y comprobar si /esx/network/nics/net_queue/load_balancer/enable funciona según lo esperado.

    Después de ejecutar el comando, verá un resultado similar al siguiente:
    {
    "mac": "02:00:0e:6d:14:3e",
    "name": "vmnic1",
    "net_queue": {
      "load_balancer": {
        "dynamic_pool": true,
          "enable": true
      }
     },
     "virtual_mac": "00:50:56:5a:21:11"
    }

    Si el resultado no es el esperado, por ejemplo, "load_balancer": "enable": false", ejecute el siguiente comando:
    esxcli/localcli network nic queue loadbalancer state set -n <nicname> -e true

Problemas de seguridad
  • Desactive el servicio del protocolo SLP (Service Location Protocol) en ESXi, slpd, para evitar vulnerabilidades de seguridad potenciales

    Algunos servicios de ESXi que se ejecutan en el sistema operativo del host, incluidos slpd, el agente de objetos CIM, sfcbd y el servicio openwsmand relacionado tienen vulnerabilidades de seguridad comprobadas. VMware ha solucionado todas las vulnerabilidades conocidas en VMSA-2019-0022 y VMSA-2020-0023 y las correcciones forman parte de la versión vSphere 7.0 Update 2. Si bien sfcbd y openwsmand están deshabilitados de forma predeterminada en ESXi, slpd está habilitado de forma predeterminada, por lo que tiene que desactivarlo si no es necesario para evitar quedar expuesto a una vulnerabilidad futura después de una actualización. 

    Solución alternativa: Para desactivar el servicio slpd, ejecute los comandos PowerCLI siguientes:
    $ Get-VMHost | Get-VmHostService | Where-Object {$_.key -eq “slpd”} | Set-VMHostService -policy “off”
    $ Get-VMHost | Get-VmHostService | Where-Object {$_.key -eq “slpd”} | Stop-VMHostService -Confirm:$false

    Como alternativa, puede usar el comando chkconfig slpd off && /etc/init.d/slpd stop.

    El servicio openwsmand no está en la lista de servicios ESXi y puede comprobar el estado del servicio con los siguientes comandos PowerCLI:
    $esx=(Get-EsxCli -vmhost xx.xx.xx.xx -v2)
    $esx.system.process.list.invoke() | where CommandLine -like '*openwsman*' | select commandline

    En la lista de servicios ESXi, el servicio sfcbd aparece como sfcbd-watchdog.

    Para obtener más información, consulte los artículos 76372 y 1025757 de la base de conocimientos de VMware.

Problemas varios
  • No puede crear instantáneas de máquinas virtuales debido a un error que genera un error en la operación de resumen

    Una condición de carrera inusual cuando se produce un estado de inactividad de todas las rutas (All-Paths-Down, APD) durante la actualización del archivo de resumen de la memoria caché de lectura basada en contenido puede provocar incoherencias en el archivo de resumen. Como resultado, no puede crear instantáneas de máquina virtual. Aparece un error similar a Se produjo un error al guardar la instantánea: Ha habido un error en una operación de resumen en el seguimiento inverso.

    Solución alternativa: Apague y vuelva a encender las máquinas virtuales para activar un nuevo cálculo de los hashes de CBRC y borrar las incoherencias del archivo de resumen.

  • Un host ESXi puede generar un error con una pantalla de diagnóstico de color púrpura debido a una condición de carrera inusual en el controlador qedentv

    Una condición de carrera inusual en el controlador qedentv puede provocar un error en un host ESXi con una pantalla de diagnóstico de color púrpura. El problema se produce cuando una interrupción completa de Rx llega justo después de que se destruya un par de colas (Queue Pair, QP) de la interfaz de servicios generales (General Services Interface, GSI), por ejemplo, durante la descarga de un controlador qedentv o el apagado del sistema. En tal caso, el controlador qedentv puede acceder a una dirección QP ya liberada, lo que provoca una excepción de PF. El problema puede ocurrir en hosts ESXi que están conectados a un conmutador físico ocupado con un gran volumen de tráfico no solicitado en la GSI. En el seguimiento inverso, se muestran mensajes similares al siguiente:

    cpu4:2107287)0x45389609bcb0:[0x42001d3e6f72]qedrntv_ll2_rx_cb@(qedrntv)#<None>+0x1be stack: 0x45b8f00a7740, 0x1e146d040, 0x432d65738d40, 0x0, 0x
    2021-02-11T03:31:53.882Z cpu4:2107287)0x45389609bd50:[0x42001d421d2a]ecore_ll2_rxq_completion@(qedrntv)#<None>+0x2ab stack: 0x432bc20020ed, 0x4c1e74ef0, 0x432bc2002000,
    2021-02-11T03:31:53.967Z cpu4:2107287)0x45389609bdf0:[0x42001d1296d0]ecore_int_sp_dpc@(qedentv)#<None>+0x331 stack: 0x0, 0x42001c3bfb6b, 0x76f1e5c0, 0x2000097, 0x14c2002
    2021-02-11T03:31:54.039Z cpu4:2107287)0x45389609be60:[0x42001c0db867]IntrCookieBH@vmkernel#nover+0x17c stack: 0x45389609be80, 0x40992f09ba, 0x43007a436690, 0x43007a43669
    2021-02-11T03:31:54.116Z cpu4:2107287)0x45389609bef0:[0x42001c0be6b0]BH_Check@vmkernel#nover+0x121 stack: 0x98ba, 0x33e72f6f6e20, 0x0, 0x8000000000000000, 0x430000000001
    2021-02-11T03:31:54.187Z cpu4:2107287)0x45389609bf70:[0x42001c28370c]NetPollWorldCallback@vmkernel#nover+0x129 stack: 0x61, 0x42001d0e0000, 0x42001c283770, 0x0, 0x0
    2021-02-11T03:31:54.256Z cpu4:2107287)0x45389609bfe0:[0x42001c380bad]CpuSched_StartWorld@vmkernel#nover+0x86 stack: 0x0, 0x42001c0c2b44, 0x0, 0x0, 0x0
    2021-02-11T03:31:54.319Z cpu4:2107287)0x45389609c000:[0x42001c0c2b43]Debug_IsInitialized@vmkernel#nover+0xc stack: 0x0, 0x0, 0x0, 0x0, 0x0
    2021-02-11T03:31:54.424Z cpu4:2107287)^[[45m^[[33;1mVMware ESXi 7.0.2 [Releasebuild-17435195 x86_64]^[[0m
    #PF Exception 14 in world 2107287:vmnic7-pollW IP 0x42001d3e6f72 addr 0x1c

    Solución alternativa: Ninguna

Problemas de almacenamiento
  • NUEVO: Si utiliza un USB como dispositivo de arranque, es posible que los hosts ESXi dejen de responder, que el host tampoco responda y que no se encuentren alertas del banco de arranque

    Los dispositivos USB tienen una profundidad de cola pequeña y, debido a una condición de carrera en la pila de almacenamiento ESXi, es posible que algunas operaciones de E/S no lleguen al dispositivo. Estas operaciones de E/S se ponen en cola en la pila de almacenamiento ESXi y, finalmente, se agota el tiempo de espera. Como resultado, los hosts ESXi dejan de responder. En la instancia de vSphere Client, aparecen alertas como Alert: /bootbank not to be found at path '/bootbank' y Host not-responding.
    En los registros de vmkernel, se muestran errores similares al siguiente:
    2021-04-12T04:47:44.940Z cpu0:2097441)ScsiPath: 8058: Cancelled Cmd(0x45b92ea3fd40) 0xa0, cmdId.initiator=0x4538c859b8f8 CmdSN 0x0 from world 0 to path "vmhba32:C0:T0:L0". Cmd count Active:0 Queued:1.
    2021-04-12T04:48:50.527Z cpu2:2097440)ScsiDeviceIO: 4315: Cmd(0x45b92ea76d40) 0x28, cmdId.initiator=0x4305f74cc780 CmdSN 0x1279 from world 2099370 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x5 D:0x0 P:0x0 Cancelled from path layer. Cmd count Active:1
    2021-04-12T04:48:50.527Z cpu2:2097440)Queued:4

    Solución alternativa: Ninguna.

  • Si un dispositivo NVMe se agrega en caliente y se elimina en caliente en un espacio de tiempo corto, el host ESXi puede generar un error con una pantalla de diagnóstico de color morado

    Si un dispositivo NVMe se agrega en caliente y se elimina en caliente en un espacio de tiempo corto, es posible que el controlador NVMe no pueda inicializar la controladora NVMe debido a que se haya agotado el tiempo de espera del comando. Como resultado, es posible que el controlador acceda a la memoria que ya se ha liberado durante un proceso de limpieza. En el seguimiento inverso, se muestra un mensaje como WARNING: NVMEDEV: NVMEInitializeController:4045: No se pudieron obtener los datos de identificación de la controladora. Estado: Tiempo de espera.
    Finalmente, se puede producir un error en el host ESXi con una pantalla de diagnóstico de color morado donde se muestre un error similar a #PF Exception ... in world ...:vmkdevmgr.

    Solución alternativa: Realice operaciones de conexión en caliente en una ranura solo después de que se haya completado la operación de conexión en caliente anterior en la ranura. Por ejemplo, si desea ejecutar una eliminación en caliente después de una operación de adición en caliente, espere hasta que se creen los HBA y se detecten los LUN. Para el escenario alternativo, agregar en caliente después de una operación de eliminación en caliente, espere hasta que se quiten todos los LUN y los HBA.

Problemas en la administración de máquinas virtuales
  • Se produce un error en el arranque HTTP de UEFI de las máquinas virtuales en hosts ESXi de una versión anterior a 7.0 Update 2

    El arranque HTTP de UEFI de las máquinas virtuales solo se admite en hosts con ESXi 7.0 Update 2 y versiones posteriores, y en máquinas virtuales con HW versión 19 o posterior.

    Solución alternativa: Utilice el arranque HTTP de UEFI solo en máquinas virtuales con HW versión 19 o posterior. El uso de HW versión 19 garantiza que las máquinas virtuales se coloquen solo en hosts con ESXi 7.0 Update 2 o versiones posteriores.

Problemas de vSAN
  • Si cambia el sitio preferido en un clúster ampliado de VMware vSAN, es posible que algunos objetos aparezcan incorrectamente como compatibles

    Si cambia el sitio preferido en un clúster ampliado, es posible que algunos objetos aparezcan incorrectamente como compatibles, ya que es posible que la configuración de la directiva no cambie automáticamente. Por ejemplo, si configura una máquina virtual para mantener los datos en el sitio preferido, al cambiar el sitio preferido, los datos pueden quedarse en el sitio no preferido.

    Solución alternativa: Antes de cambiar un sitio preferido, en Configuración avanzada, reduzca el valor de ClomMaxCrawlCycleMinutes a 15 minutos para asegurarse de que las directivas de objetos estén actualizadas. Después del cambio, revierta la opción ClomMaxCrawlCycleMinutes al valor anterior.

Problemas de instalación, actualización y migración
  • El arranque UEFI de los hosts ESXi puede detenerse con un error durante una actualización a ESXi 7.0 Update 2 desde una versión anterior de ESXi 7.0

    Si intenta actualizar el entorno a 7.0 Update 2 desde una versión anterior de ESXi 7.0 mediante líneas base de revisión de vSphere Lifecycle Manager, el arranque UEFI de los hosts ESXi podría detenerse con un error como el siguiente:
    Loading /boot.cfg
    Failed to load crypto64.efi
    Error irrecuperable: 15 (Not found)

    Solución alternativa: Para obtener más información, consulte los artículos 83063 y 83107 de la base de conocimientos de VMware.

  • Si VIB heredados están en uso en un host ESXi, vSphere Lifecycle Manager no puede extraer una especificación de software deseada para inicializar en un clúster nuevo

    Con vCenter Server 7.0 Update 2, puede crear un nuevo clúster importando la especificación de software deseada desde un único host de referencia.  Sin embargo, si VIB heredados están en uso en un host ESXi, vSphere Lifecycle Manager no puede extraer en la instancia de vCenter Server donde se crea el clúster una especificación de software de referencia de dicho host. En /var/log/lifecycle.log, se muestran mensajes similares al siguiente:
    020-11-11T06:54:03Z ciclo de vida: 1000082644: HostSeeding:499 ERROR Extract depot failed: Checksum doesn't match. Calculated 5b404e28e83b1387841bb417da93c8c796ef2497c8af0f79583fd54e789d8826, expected: 0947542e30b794c721e21fb595f1851b247711d0619c55489a6a8cae6675e796 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:366 ERROR Extract depot failed. 2020-11-11T06:54:04Z lifecycle: 1000082644: imagemanagerctl:145 ERROR [VibChecksumError]

    Solución alternativa: Siga los pasos descritos en el artículo 83042 de la base de conocimientos de VMware.

  • Ve una ráfaga corta de mensajes de registro en syslog.log después de cada arranque de ESXi

    Después de actualizar a ESXi 7.0 Update 2, es posible que vea una ráfaga corta de mensajes de registro después de cada arranque de ESXi.
    Estos registros no indican ningún problema con ESXi y se pueden ignorar estos mensajes. Por ejemplo:
    ​2021-01-19T22:44:22Z watchdog-vaai-nasd: '/usr/lib/vmware/nfs/bin/vaai-nasd -f' salió después de 0 segundos (error rápido 127) 1
    2021-01-19T22:44:22Z watchdog-vaai-nasd: Ejecutar '/usr/lib/vmware/nfs/bin/vaai-nasd -f'
    2021-01-19T22:44:22.990Z aainasd[1000051135]: Registro para el daemon de VAAI-NAS para NFS version=1.0 build=build-00000 option=DEBUG
    2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoadFile: No hay entradas cargadas por diccionario.
    2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: No se puede abrir el archivo "/usr/lib/vmware/config": no existe dicho archivo o directorio.
    2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: No se puede abrir el archivo "//.vmware/config": no existe dicho archivo o directorio.
    2021-01-19T22:44:22.990Z vaainasd[1000051135]: DictionaryLoad: No se puede abrir el archivo "//.vmware/preferences": no existe dicho archivo o directorio.
    2021-01-19T22:44:22.990Z vaainasd[1000051135]: Cambiar a extensiones syslog de VMware
    2021-01-19T22:44:22.992Z vaainasd[1000051135]: Cargar complementos VAAI-NAS.
    2021-01-19T22:44:22.992Z vaainasd[1000051135]: DISKLIB-PLUGIN : No se está cargando el complemento /usr/lib/vmware/nas_plugins/lib64: no es una biblioteca compartida.

    Solución alternativa: Ninguna

  • Aparecen mensajes de advertencia sobre la falta de VIB en los informes de comprobación de compatibilidad de vSphere Quick Boot

    Después de actualizar a ESXi 7.0 Update 2, si comprueba la compatibilidad con vSphere Quick Boot de su entorno mediante el comando /usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py, es posible que vea algunos mensajes de advertencia sobre la falta de VIB en el shell. Por ejemplo:
    No se encuentran VIB... en la recopilación de VIB especificada.
    Omitiendo VIB reservados ausentes..., se eliminan de los identificadores de VIB reservados.
    Estas advertencias no indican un problema de compatibilidad.

    Solución alternativa: Los mensajes de VIB que faltan se pueden omitir de forma segura y no afectan a la notificación de compatibilidad de vSphere Quick Boot. La línea de salida final del comando loadESXCheckCompat indica de forma inequívoca si el host es compatible.

  • Se produce un error al arrancar automáticamente un clúster que administra con una imagen de vSphere Lifecycle Manager

    Si intenta arrancar automáticamente un clúster que administra con una imagen de vSphere Lifecycle Manager para realizar una instalación con estado y sobrescribir las particiones de VMFS, se produce un error en la operación. En el paquete de soporte, se muestran mensajes similares al siguiente:
    2021-02-11T19:37:43Z Host Profiles[265671 opID=MainThread]: ERROR: EngineModule::ApplyHostConfig. Excepción: [Errno 30] Sistema de archivos de solo lectura

    Solución alternativa: Siga las instrucciones del proveedor para limpiar la partición de VMFS en el host de destino y vuelva a intentar la operación. Como alternativa, utilice un disco vacío. Para obtener más información sobre la utilidad de partición del disco en ESXi, consulte el artículo 1036609 de la base de conocimientos de VMware.

  • Se puede producir un error en las actualizaciones a ESXi 7.x desde las versiones 6.5.x y 6.7.0 mediante ESXCLI debido a una limitación de espacio

    Se puede producir un error en las actualizaciones a ESXi 7.x desde las versiones 6.5.x y 6.7.0 mediante el uso de los comandos de ESXCLI esxcli software profile update o esxcli software profile install, ya que la partición bootbank de ESXi puede ser menor que el tamaño del perfil de imagen. En ESXi Shell o en el shell de PowerCLI, se muestra un error como el siguiente:

    [InstallationError]
 La transacción pendiente requiere 244 MB de espacio libre; sin embargo, el tamaño máximo admitido es de 239 MB.
 Consulte el archivo de registro para obtener más detalles.

    El problema también se produce cuando se intenta realizar una actualización de host ESXi mediante los comandos de ESXCLI esxcli software vib update o esxcli software vib install.

    Solución alternativa: Puede realizar la actualización en dos pasos, si utiliza el comando esxcli software profile update para actualizar hosts ESXi a ESXi 6.7 Update 1 o una versión posterior y, a continuación, actualiza a 7.0 Update 1c. Como alternativa, puede ejecutar una actualización mediante una imagen ISO y vSphere Lifecycle Manager.

Problemas conocidos de versiones anteriores

Para ver una lista de los problemas conocidos anteriores, haga clic aquí.

check-circle-line exclamation-circle-line close-line
Scroll to top icon
check-circle-line exclamation-circle-line close-line
Scroll to top icon