Notas de la versión de VMware ESXi 7.0 Update 2c

ESXi 7.0 Update 2c | 24 de agosto de 2021 | Compilación 18426014 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
• Versiones anteriores de ESXi 7.0
• Revisiones incluidas en esta versión
• Avisos de compatibilidad con el producto
• Problemas resueltos
• Problemas conocidos

Novedades

• ESXi 7.0 Update 2c proporciona correcciones de errores y seguridad documentadas en la sección Problemas resueltos.

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:

• VMware ESXi 7.0, versión de revisión ESXi 7.0 Update 2a
• VMware ESXi 7.0, versión de revisión ESXi 7.0 Update 2
• VMware ESXi 7.0, versión de revisión ESXi 7.0 Update 1d
• VMware ESXi 7.0, versión de revisión ESXi 7.0 Update 1c
• VMware ESXi 7.0, versión de revisión ESXi 7.0 Update 1b
• VMware ESXi 7.0, versión de revisión ESXi 7.0 Update 1a
• VMware ESXi 7.0, versión de revisión ESXi 7.0 Update 1
• VMware ESXi 7.0, versión de revisión ESXi 7.0b

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.

Para obtener más información sobre las versiones de ESXi que admiten la actualización a ESXi 7.0 Update 2c, consulte el artículo 67077 de la base de conocimientos de VMware.

Revisiones incluidas en esta versión

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

Detalles de la compilación

Nombre de archivo de descarga:	VMware-ESXi-7.0U2c-18426014-depot
Compilación:	18426014
Tamaño de descarga:	580,8 MB
md5sum:	a6b2d1e3a1a071b8d93a55d7a7fc0b63
sha1checksum:	829da0330f765b4ae46c2fb5b90a8b60f90e4e5b
Reinicio requerido del host:	Sí
Migración de máquina virtual o apagado requeridos:	Sí

Componentes

Componente	Boletín	Categoría	Gravedad
Componente de ESXi: VIB principales ESXi	ESXi_7.0.2-0.20.18426014	Corrección de error	Crítico
Controlador Emulex FC	Broadcom-ELX-lpfc_12.8.298.3-2vmw.702.0.20.18426014	Corrección de error	Crítico
Controladores Broadcom NetXtreme-E Network y ROCE/RDMA para VMware ESXi	Broadcom-bnxt-Net-RoCE_216.0.0.0-1vmw.702.0.20.18426014	Corrección de error	Importante
Controladores RoCE/RDMA y Ethernet QLogic FastLinQ 10/25/40/50/100 GbE para VMware ESXi	MRVL-E4-CNA-Driver-Bundle_1.0.0.0-1vmw.702.0.20.18426014	Corrección de error	Importante
Componente de instalación/actualización de ESXi	esx-update_7.0.2-0.20.18426014	Corrección de error	Crítico
Controlador de red para adaptadores Intel(R) X710/XL710/XXV710/X722	Intel-i40en_1.8.1.137-1vmw.702.0.20.18426014	Corrección de error	Crítico
Controlador USB	VMware-vmkusb_0.1-4vmw.702.0.20.18426014	Corrección de error	Crítico
Componente de ESXi: VIB principales ESXi	ESXi_7.0.2-0.15.18295176	Seguridad	Crítico
Controlador USB	VMware-vmkusb_0.1-1vmw.702.0.15.18295176	Seguridad	Moderado
Componente de herramientas de ESXi	VMware-VM-Tools_11.2.6.17901274-18295176	Seguridad	Crítico
Componente de instalación/actualización de ESXi	esx-update_7.0.2-0.15.18295176	Seguridad	Crítico

IMPORTANTE:

• Para descargar el archivo ZIP del almacén sin conexión de revisión de ESXi 7.0 Update 2c desde VMware Customer Connect, desplácese a Productos and Accounts (Productos y cuentas) > Product Patches (Revisiones de productos). En el menú desplegable Select a Product (Seleccionar un producto), seleccione ESXi (Embedded and Installable) y, en el menú desplegable Select a Version (Seleccionar una versión), seleccione 7.0.
• 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	Detalles
ESXi-7.0U2c-18426014	Corrección de error	Crítico	Corrección de error y seguridad
ESXi-7.0U2sc-18295176	Seguridad	Crítico	Solo seguridad

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.0U2c-18426014-estándar

ESXi-7.0U2c-18426014-sin-herramientas

ESXi-7.0U2sc-18295176-estándar

ESXi-7.0U2sc-18295176-sin-herramientas

Imagen ESXi

Nombre y versión	Fecha de versión	Categoría	Detalles
ESXi70U2c-18426014	08/24/2021	Corrección de error	Imagen de corrección de error y seguridad
ESXi70U2sc-18295176	08/24/2021	Seguridad	Imagen de solo seguridad

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.0.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.0.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 Revisiones de 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

• La retirada del módulo de plataforma de confianza (Trusted Platform Module, TPM) 1.2 en una versión principal futura de vSphere: VMware pretende en una versión principal futura de vSphere interrumpir la compatibilidad con TPM 1.2 y las funciones asociadas, como TPM 1.2 con TXT. Para aprovechar al máximo las funciones de vSphere, puede utilizar TPM 2.0 en lugar de TPM 1.2. La compatibilidad con TPM 1.2 continúa en todas las versiones, actualizaciones y revisiones vSphere 7.0.x. Sin embargo, no verá una advertencia de desuso para TPM 1.2 durante la instalación o las actualizaciones de las versiones 7.0.x.

• El servicio del protocolo de ubicación de servicios (SLP) está deshabilitado de forma predeterminada: A partir de ESX 7.0 Update 2c, el servicio SLP está deshabilitado de forma predeterminada para evitar posibles vulnerabilidades de seguridad. El servicio SLP también se deshabilita automáticamente después de actualizar a ESX 7.0 Update 2c. Puede habilitar manualmente el servicio SLP mediante el comando esxcli system slp set --enable true. Para obtener más información, consulte el artículo 76372 de la base de conocimientos de VMware.

Problemas resueltos

Los problemas resueltos se agrupan del siguiente modo:

• ESXi_7.0.2-0.20.18426014
• esx-update_7.0.2-0.20.18426014
• Broadcom-bnxt-Net-RoCE_216.0.0.0-1vmw.702.0.20.18426014
• MRVL-E4-CNA-Driver-Bundle_1.0.0.0-1vmw.702.0.20.18426014
• Intel-i40en_1.8.1.137-1vmw.702.0.20.18426014
• Broadcom-ELX-lpfc_12.8.298.3-2vmw.702.0.20.18426014
• VMware-vmkusb_0.1-4vmw.702.0.20.18426014
• ESXi_7.0.2-0.15.18295176
• esx-update_7.0.2-0.15.18295176
• VMware-VM-Tools_11.2.6.17901274-18295176
• VMware-vmkusb_0.1-1vmw.702.0.15.18295176
• ESXi-7.0U2c-18426014-estándar
• ESXi-7.0U2c-18426014-sin-herramientas
• ESXi-7.0U2sc-18295176-estándar
• ESXi-7.0U2sc-18295176-sin-herramientas
• ESXi Image - ESXi70U2c-18426014
• ESXi image - ESXi70U2sc-18295176

ESXi_7.0.2-0.20.18426014

Categoría de revisión	Corrección de error
Gravedad de la revisión	Crítico
Reinicio de host requerido	Sí
Migración de máquina virtual o apagado requeridos	Sí
Hardware afectado	N/C
Software afectado	N/C
VIB que se incluyen	VMware_bootbank_vsanhealth_7.0.2-0.20.18426014 VMware_bootbank_vsan_7.0.2-0.20.18426014 VMware_bootbank_gc_7.0.2-0.20.18426014 VMware_bootbank_esx-xserver_7.0.2-0.20.18426014 VMware_bootbank_clusterstore_7.0.2-0.20.18426014 VMware_bootbank_vdfs_7.0.2-0.20.18426014 VMware_bootbank_native-misc-drivers_7.0.2-0.20.18426014 VMware_bootbank_cpu-microcode_7.0.2-0.20.18426014 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.20.18426014 VMware_bootbank_esx-base_7.0.2-0.20.18426014
PR corregidas	2717698, 2731446, 2515171, 2731306, 2751564, 2718934, 2755056, 2725886, 2725886, 2753231, 2728910, 2741111, 2759343, 2721379, 2751277, 2708326, 2755977, 2737934, 2777001, 2760932, 2731263, 2731142, 2760267, 2749688, 2763986, 2765534, 2766127, 2777003, 2778793, 2755807, 2760081, 2731644, 2749815, 2749962, 2738238, 2799408
Números CVE	N/C

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.

Actualiza los VIB crx, vsanhealth, vsan, gc, esx-xserver, clusterstore, vdfs, native-misc-drivers, cpu-microcode, esx-dvfilter-generic-fastpath y esx-base para resolver los siguientes problemas:

• PR 2717698: 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

  El problema está resuelto en esta versión.

• PR 2731446: Mientras el dispositivo de vSphere Replication se enciende, es posible que se produzca un error en el servicio hostd y que los hosts ESXi no respondan temporalmente a vCenter Server

  En raras ocasiones, mientras se enciende el dispositivo de vSphere Replication, se puede producir un error en el servicio hostd y provocar que los hosts ESXi no respondan temporalmente a vCenter Server. El servicio hostd se reinicia automáticamente y la conectividad se restaura.

  El problema está resuelto en esta versión.

• PR 2515171: Al editar un parámetro de opciones avanzadas en un perfil de host y establecer un valor como false, el valor se establece como true

  Cuando se intenta definir un valor como false para un parámetro de opción avanzada en un perfil de host, la interfaz de usuario crea un valor de cadena no vacío. Los valores que no están vacíos se interpretan como true y el parámetro de opción avanzada recibe el valor true en el perfil de host.

  El problema está resuelto en esta versión.

• PR 2731306: Los hosts ESXi dejan de responder a vCenter Server con mensajes repetidos para errores de admisión

  Los hosts ESXi podrían dejar de responder a vCenter Server incluso cuando los hosts están accesibles y en ejecución. El problema se produce en imágenes de proveedor con controladores personalizados en los que ImageConfigManager consume más RAM que la asignada. Como resultado, errores repetidos de ImageConfigManager hacen que los hosts ESXi se desconecten de vCenter Server.
  En los registros de VMkernel, aparecen errores repetidos como:
  Admission failure in path: host/vim/vmvisor/hostd-tmp/sh.<pid1>:python.<pid2>:uw.<pid2>.
  En los registros de hostd, aparecen mensajes como: Task Created : haTask-ha-host-vim.host.ImageConfigManager.fetchSoftwarePackages-<sequence>, followed by: ForkExec(/usr/bin/sh) <pid1>, donde <pid1> identifica un proceso ImageConfigManager .

  El problema está resuelto en esta versión.

• PR 2751564: Si disminuye el valor de la opción de configuración avanzada DiskMaxIOSize, se pueden producir errores en las operaciones de E/S de los hosts ESXi

  Si cambia la opción de configuración avanzada DiskMaxIOSize a un valor inferior, las operaciones de E/S con tamaños de bloque grandes pueden dividirse y colocarse en cola de forma incorrecta en la ruta de acceso de PSA. Como resultado, es posible que se agote el tiempo de espera de las operaciones de E/S de los hosts ESXi y se produzca un error.

  El problema está resuelto en esta versión.

• PR 2718934: Las operaciones de encendido o apagado de las máquinas virtuales tardan demasiado tiempo

  En determinadas condiciones, las operaciones de encendido o apagado de las máquinas virtuales pueden tardar hasta 20 minutos. El problema se produce cuando el almacenamiento subyacente de las máquinas virtuales ejecuta una operación en segundo plano, como volver a examinar HBA o eventos de APD, y algunos bloqueos se mantienen continuamente.

  El problema está resuelto en esta versión. La solución elimina los bloqueos innecesarios en los recursos de almacenamiento e introduce una exclusión mutua rápida para mejorar el rendimiento de la operación de energía de la máquina virtual.

• PR 2755056: se produce un error en los hosts ESXi con una pantalla de diagnóstico de color púrpura debido a la diferencia de tamaño de respuesta de la página de datos de producto vitales (VPD)

  En raras ocasiones, cuando el tamaño de respuesta de la página VPD del host ESXi de destino es diferente en rutas distintas al host, ESXi puede escribir más bytes que la longitud asignada para una ruta de acceso determinada. Como resultado, se produce un error en el host ESXi con una pantalla de diagnóstico de color púrpura y un mensaje como el siguiente:
  Panic Message: @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4878 - Corruption in dlmalloc

  El problema está resuelto en esta versión. La solución realiza un seguimiento del tamaño de las páginas de VPD mediante un campo independiente en lugar de depender del encabezado de respuesta de VPD.

• PR 2725886: Una contención de bloqueo inusual puede provocar errores en algunas operaciones de la máquina virtual

  Una contención de bloqueo inusual puede provocar errores en las operaciones de la máquina virtual, como la conmutación por error o la migración.
  Los mensajes de error de bloqueo son similares a los siguientes:
  vol 'VM_SYS_11', lock at 480321536: [Req mode 1] Checking liveness:
type 10c00003 offset 480321536 v 1940464, hb offset 3801088
  o
  Res3: 2496: Rank violation threshold reached: cid 0xc1d00002, resType 2, cnum 5 vol VM_SYS_11

  El problema está resuelto en esta versión.

• PR 2766036: En la instancia de vSphere Client, se ven números incorrectos para el espacio aprovisionado de las máquinas virtuales

  En flujos de trabajo complicados que provocan la creación de varias máquinas virtuales, al desplazarse hasta Máquinas virtuales > Máquinas virtuales, es posible que aparezcan grandes números en la columna Espacio aprovisionado de algunas máquinas virtuales. Por ejemplo, 2,95 TB en lugar del espacio aprovisionado real de 25 GB.

  El problema está resuelto en esta versión.

• PR 2753231: Se produce un error en un host ESXi con una pantalla de diagnóstico de color púrpura debido a un daño en la pila de llamadas en la pila de almacenamiento ESXi

  Al controlar el comando SCSI READ CAPACITY (10), es posible que ESXi copie el exceso de datos de la respuesta y dañe la pila de llamadas. Como resultado, se produce un error en el host ESXi con una pantalla de diagnóstico de color púrpura.

  El problema está resuelto en esta versión.

• PR 2728910: Es posible que los hosts ESX generen un error y aparezca una pantalla de diagnóstico de color púrpura cuando se enciendan las máquinas virtuales

  En muy raras ocasiones, es posible que no se bloqueen los clústeres de recursos de VMFS que se incluyen en una transacción de diario. Como resultado, durante el encendido de las máquinas virtuales, se puede producir un error en varios hosts ESXi con una pantalla de diagnóstico de color púrpura debido a la excepción 14 en la capa de VMFS. A continuación, se muestra un seguimiento típico de la pila y el mensaje que se ve en el registro de VMkernel:
  @BlueScreen: #PF Exception 14 in world 2097684:VSCSI Emulat IP 0x418014d06fca addr 0x0
  PTEs:0x16a47a027;0x600faa8007;0x0;
  2020-06-24T17:35:57.073Z cpu29:2097684)Inicio del código: 0x418013c00000 VMK uptime: 0:01:01:20.555
2020-06-24T17:35:57.073Z cpu29:2097684)0x451a50a1baa0:[0x418014d06fca]Res6MemUnlockTxnRCList@esx#nover+0x176 pila: 0x1 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb10:[0x418014c7cdb6]J3_DeleteTransaction@esx#nover+0x33f pila: 0xbad0003
2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb40:[0x418014c7db10]J3_AbortTransaction@esx#nover+0x105 pila: 0x0 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb80:[0x418014cbb752]Fil3_FinalizePunchFileHoleTxnVMFS6@esx#nover+0x16f pila: 0x430fe950e1f0
2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bbd0:[0x418014c7252b]Fil3UpdateBlocks@esx#nover+0x348 pila: 0x451a50a1bc78 2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bce0:[0x418014c731dc]Fil3_PunchFileHoleWithRetry@esx#nover+0x89 pila: 0x451a50a1bec8
2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bd90:[0x418014c739a5]Fil3_FileBlockUnmap@esx#nover+0x50e pila: 0x230eb5 2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be40:[0x418013c4c551]FSSVec_FileBlockUnmap@vmkernel#nover+0x6e pila: 0x230eb5
2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be90:[0x418013fb87b1]VSCSI_ExecFSSUnmap@vmkernel#nover+0x8e pila: 0x0 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf00:[0x418013fb71cb]VSCSIDoEmulHelperIO@vmkernel#nover+0x2c pila: 0x430145fbe070
2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf30:[0x418013ceadfa]HelperQueueFunc@vmkernel#nover+0x157 pila: 0x430aa05c9618 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bfe0:[0x418013f0eaa2]CpuSched_StartWorld@vmkernel#nover+0x77 pila: 0x0
2020-06-24T17:35:57.083Z cpu29:2097684)base fs=0x0 gs=0x418047400000 Kgs=0x0

  El problema está resuelto en esta versión.

• PR 2741111: Un error en algunas CPU Intel al reenviar capturas de excepción de depuración (#DB) puede provocar un error triple en la máquina virtual

  En raras ocasiones, es posible que algunas CPU Intel no puedan reenviar capturas de #DB y, si se produce una interrupción del temporizador durante la llamada del sistema Windows, la máquina virtual podría triplicar el error.

  El problema está resuelto en esta versión. La solución reenvía todas las capturas #DB de las CPU al sistema operativo invitado, excepto cuando la captura de la base de datos proviene de un depurador conectado a la máquina virtual.

• PR 2759343: El servicio sfcbd no se inicia al reiniciar agentes de administración de ESXi desde la interfaz de usuario de la consola directa (DCUI)

  Si reinicia agentes de administración de ESXi desde DCUI, el servicio sfcbd no se inicia. Debe iniciar manualmente el servicio SFCB.

  El problema está resuelto en esta versión.

• PR 2721379: El servicio hostd registra una advertencia de que no hay sensores de fuente de alimentación cada 2 minutos

  El servicio hostd registra el mensaje BuildPowerSupplySensorList found 0 power supply sensors cada 2 minutos. El problema se produce cuando se actualiza a ESXi 7.0 Update 1 o se instala nuevamente en un host ESXi.

  El problema está resuelto en esta versión.

• PR 2751277: Los hosts ESXi pueden generar un error con una pantalla de diagnóstico de color púrpura debido a un error de referencia de puntero NULL

  En raras ocasiones, el asignador de memoria del kernel puede devolver un puntero NULL que podría no anular la referencia correctamente. Como resultado, se puede producir un error en el host ESXi con una pantalla de diagnóstico de color púrpura, como #GP Exception 13 in world 2422594:vmm:overCom @ 0x42003091ede4. En el seguimiento inverso, aparecen errores similares a los siguientes:
  #1 Util_ZeroPageTable
#2 Util_ZeroPageTableMPN
#3 VmMemPfUnmapped
#4 VmMemPfInt
#5 VmMemPfGetMapping
#6 VmMemPf
#7 VmMemPfLockPageInt
#8 VMMVMKCall_Call
#9 VMKVMM_ArchEnterVMKernel

  El problema está resuelto en esta versión.

• PR 2708326: 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.

  El problema está resuelto en esta versión.

• PR 2755977: Los hosts ESXi pueden no aprovisionar VMDK grueso ni crear un archivo de intercambio durante el encendido de una máquina virtual

  Cuando un host ESXi no tiene bloques de archivos grandes libres (LFB) para asignar, el host cumple con el aprovisionamiento de VMDK grueso o la creación de un archivo de intercambio con bloques de archivos pequeños (SFB). Sin embargo, en raras ocasiones, es posible que el host no pueda asignar también SFB. Como resultado, se produce un error en el aprovisionamiento de VMDK grueso o en la creación de un archivo de intercambio. Cuando las máquinas virtuales intentan encenderse, se muestra un error en los registros de VMkernel como el siguiente:
   vmkernel.1:2021-01-08T19:13:28.341Z cpu20:2965260)Fil3: 10269: Max no space retries (10) exceeded for caller Fil3_SetFileLength (status 'No space left on device')

  El problema está resuelto en esta versión.

• PR 2737934: Si utiliza almacenes de datos de VMFS6 muy grandes, es posible que vea errores de bloqueo de CPU repetidos o que se produzcan errores de forma intermitente en los hosts ESXi

  Cuando se utilizan almacenes de datos de VMFS6 muy grandes, el proceso de asignación de bloques de archivos para VMDK finos en un clúster de recursos puede provocar un bloqueo de CPU. Como resultado, se ven mensajes de bloqueo de CPU y, en casos excepcionales, es posible que se produzca un error en hosts ESXi. En el seguimiento inverso, se muestran mensajes similares al siguiente:
  2021-04-07T02:18:08.730Z cpu31:2345212)ADVERTENCIA: Heartbeat: 849: PCPU 10 didn't have a heartbeat for 7 seconds; *may* be locked up.
  El seguimiento inverso asociado relacionado con funciones Res6AffMgr tiene un aspecto similar al siguiente:
  2021-01-06T02:16:16.073Z cpu0:2265741)ALERTA: NMI: 694: NMI IPI: RIPOFF(base):RBP:CS [0x121d74d(0x42001a000000):0x50d0:0xf48] (Src 0x1, CPU0)
2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b320:[0x42001b21d74c]Res6AffMgrComputeSortIndices@esx#nover+0x369 pila: 0x43119125a000
2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b3b0:[0x42001b224e46]Res6AffMgrGetCluster@esx#nover+0xb1f pila: 0xd 2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b4b0:[0x42001b226491]Res6AffMgr_AllocResourcesInt@esx#nover+0x40a pila: 0x4311910f4890
2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b680:[0x42001b2270e2]Res6AffMgr_AllocResources@esx#nover+0x1b pila: 0x0

  El problema está resuelto en esta versión. Para obtener más información, consulte el artículo 83473 de la base de conocimientos de VMware.

• PR 2777001: Los hosts ESXi con un gran recuento de CPU físicas pueden generar un error con una pantalla de diagnóstico de color púrpura durante una actualización a ESXi 7.0 Update 2 o después de ella

  Durante una actualización a ESXi 7.0 Update 2 o después de ella, es posible que la capa de almacenamiento de ESX no asigne suficientes recursos de memoria para los hosts ESXi con un gran número de CPU físicas y muchos dispositivos de almacenamiento o rutas de acceso conectados a los hosts. Como resultado, se puede producir un error en dichos hosts ESXi con una pantalla de diagnóstico de color púrpura.

  El problema está resuelto en esta versión. La solución corrige la asignación de memoria de la capa de almacenamiento ESX.

• PR 2760932: Las máquinas virtuales con hardware versión 18 pueden generar errores de forma intermitente durante las operaciones de vSphere vMotion

  Las máquinas virtuales con hardware versión 18 y VMware Tools 11.2.0 o versiones posteriores pueden generar errores debido a un problema de dispositivo de gráficos virtuales en el lado de destino durante una instancia de vSphere vMotion o Storage vMotion.
  En vmkernel.log se muestra una línea como la siguiente:
  PF failed to handle a fault on mmInfo at va 0x114f5ae0: Out of memory. Terminating...

  El problema está resuelto en esta versión.

• PR 2731263: Después de actualizar a la versión de hardware 18, se produce un pánico en el kernel del sistema operativo invitado en las máquinas virtuales

  Después de actualizar a la versión de hardware 18, algunos sistemas operativos invitados, como CentOS 7, en las CPU AMD pueden generar un error de detención del kernel al arrancar la máquina virtual. Aparece el mensaje de pánico del kernel cuando abre una consola web para la máquina virtual.

  El problema está resuelto en esta versión.

• PR 2731142: Los paquetes con la opción de límite de encapsulación de túnel IPv6 se pierden en el tráfico entre máquinas virtuales

  Algunos kernels de Linux agregan la opción Límite de encapsulación de túnel de IPv6 a paquetes de túnel IPv6, como se describe en RFC 2473, par. 5.1. Como resultado, los paquetes de túnel IPv6 se descartan en el tráfico entre las máquinas virtuales, debido al encabezado de extensión IPv6.

  El problema está resuelto en esta versión. La solución analiza correctamente los paquetes con la opción Límite de encapsulación de túnel IPv6.

• PR 2760267: En los registros de VMkernel, se muestran varias advertencias que indican un cambio a la ruta de acceso preferida XXX en estado EN ESPERA para el dispositivo XXX

  Cuando los medios virtuales, como una unidad de CD, se conectan al entorno de vSphere mediante una instancia integrada de Dell Remote Access Controller (iDRAC) y no se asigna ningún archivo de medios a la unidad, es posible que aparezcan varios mensajes de advertencia en el registro de vmkernel como los siguientes:
  vmw_psp_fixed: psp_fixedSelectPathToActivateInt:439: Switching to preferred path vmhba32:C0:T0:L1 in STANDBY state for device mpx.vmhba32:C0:T0:L1.WARNING: vmw_psp_fixed: psp_fixedSelectPathToActivateInt:464: Selected current STANDBY path vmhba32:C0:T0:L1 for device mpx.vmhba32:C0:T0:L1 to activate. This may lead to path thrashing.

  El problema está resuelto en esta versión.

• PR 2749688: vCenter Server puede quitar de forma intermitente puertos virtuales distribuidos controlados por NSX internos de los hosts ESXi

  Durante los flujos de trabajo de sincronización de 24 horas de vSphere Distributed Switch, es posible que vCenter Server quite de forma intermitente puertos virtuales distribuidos controlados NSX, como el puerto de reenvío de plano de servicio (SPF), de hosts ESXi. Por ello, es posible que se produzcan errores en operaciones de vSphere vMotion de máquinas virtuales. Se muestra un error como Could not connect SPF port: Not found en los registros.

  El problema está resuelto en esta versión.

• PR 2763986: Si configura la partición temporal en el directorio raíz de un volumen VMFS, se produce un error en la actualización a ESXi 7.0.x y es posible que se pierdan datos en el volumen VMFS

  ESXi 7.0 introdujo la partición ESX-OSData basada en VMFS-L, que asume la función de la partición desde cero heredada, la partición del bloqueador para VMware Tools y el destino del volcado de núcleo. Si configura la partición desde cero en el directorio raíz de un volumen VMFS durante una actualización a ESXi 7.0.x, el sistema intenta convertir los archivos VMFS en formato VMFS-L para que coincidan con los requisitos de partición de OS-Data. Como resultado, es posible que la partición OS-Data sobrescriba el volumen VMFS y cause la pérdida de datos.

  El problema está resuelto en esta versión. La solución agrega una comprobación si el sistema de archivos es VFAT antes de convertirlo en OS-DATA. Para obtener más información, consulte el artículo 83647 de la base de conocimientos de VMware.

• PR 2765534: El estado de mantenimiento del canal de comunicación de los hosts ESXi en clústeres NSX Data Center for vSphere está inactivo después de actualizar a ESXi 7.0 Update 2a

  Debido a un problema de control de registros, después de una actualización a ESXi 7.0 Update 2a, cuando se comprueba el estado de mantenimiento del canal de comunicación, se ven todos los hosts ESXi con el estado inactivo, ya que NSX Manager no puede conectarse al agente de firewall.

  El problema está resuelto en esta versión. Si ya se enfrenta a este problema, detenga el servicio vsfwd y vuelva a intentar la operación de actualización.

• PR 2766127: Si actualiza los hosts ESXi mediante vSphere Quick Boot en un entorno de FCoE, se puede producir un error en el servidor físico con una pantalla de diagnóstico de color púrpura

  Si se instala un host ESXi versión 7.0 Update 2 en un LUN FCoE y utiliza el modo de arranque UEFI, cuando se intenta actualizar el host mediante vSphere QuickBoot, se puede producir un error en el servidor físico con una pantalla de diagnóstico de color púrpura debido a un error de memoria.

  El problema está resuelto en esta versión.

• PR 2777003: Si utiliza un USB como dispositivo de arranque para ESXi 7.0 Update 2a, es posible que los hosts ESXi dejen de responder y vea que el host no responde y que no se encuentran 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

  El problema está resuelto en esta versión.

• PR 2778793: El tiempo de arranque de los hosts ESXi se ralentiza después de la actualización a ESXi Update 2a

  Es posible que se produzca una ralentización de hasta 60 minutos en el tiempo de arranque de los hosts ESXi después de una actualización a ESXi Update 2a.
  Este problema no afecta a las actualizaciones a ESXi Update 2a de versiones anteriores de ESXi 7.0.x.
  El problema solo se produce cuando se utiliza una línea base o imagen de vSphere Lifecycle Manager, o bien el comando esxcli software profile update para realizar la operación de actualización. Si utiliza una imagen ISO o una instalación generada por script, no se produce el problema.
  Es más probable que el problema afecte a las configuraciones de iSCSI, pero está relacionado con el algoritmo de ESXi para la detección de banco de arranque, no con destinos de almacenamiento externo lentos.

  El problema está resuelto en esta versión. La solución aumenta los límites de tolerancia cuando no se proporcionan de inmediato un archivo boot.cfg o almacenamiento.

• PR 2755807: se produce un error de memoria agotada en las operaciones de vSphere vMotion en un host ESXi

  Debido a una fuga de memoria en la pila del conjunto de puertos, las operaciones de vSphere vMotion en un host ESXi pueden generar un error de memoria agotada. En vSphere Client, se muestra un error, como:
  Failed to reserve port. DVSwitch 50 18 34 d1 76 81 ec 9e-03 62 e2 d4 6f 23 30 ba port 1 39.
Failed with error status: Out of memory.

  El problema está resuelto en esta versión.

• PR 2760081: advertencia de estado del motor de recomendación de compilación vSAN después de actualizar a vSAN 7.0 Update 2

  Si vCenter Server no puede resolver vcsa.vmware.com a una dirección IP, no se puede cargar el catálogo de versiones de vSAN. La siguiente comprobación de estado de vSAN muestra una advertencia: Estado del motor de recomendación de compilación de vSAN.
  Es posible que se muestre un mensaje de error similar al siguiente:
  2021-04-12T11:40:59.435Z ERROR vsan-mgmt[32221] [VsanHttpRequestWrapper::urlopen opID=noOpId] Exception while sending request : Cannot resolve localhost or Internet websites.
2021-04-12T11:40:59.435Z WARNING vsan-mgmt[32221] [VsanVumCoreUtil::CheckVumServiceStatus opID=noOpId] Failed to connect VUM service: Cannot resolve localhost or Internet websites.
2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumIntegration::VumStatusCallback opID=noOpId] VUM is not installed or not responsive ​
2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumSystemUtil::HasConfigIssue opID=noOpId] Config issue health.test.vum.vumDisabled exists on entity None

  El problema está resuelto en esta versión.

• PR 2731644: Se observa una actividad de limpieza superior a la habitual en vSAN

  Un error de desbordamiento de enteros puede provocar que vSAN DOM emita limpiezas con más frecuencia que la configuración establecida.

  El problema está resuelto en esta versión.

• PR 2749815: Los hosts ESXi generan un error con una pantalla de diagnóstico de color púrpura cuando se anula una resincronización con escrituras de invitado activas

  Cuando una resincronización se ejecuta en paralelo con escrituras de invitado en objetos que son propiedad de un host ESXi, se puede producir un error en el host con una pantalla de diagnóstico de color púrpura.

  El problema está resuelto en esta versión.

• PR 2749962: Aparece un error de syslog Failed to write header on rotate

  Cuando el archivo cmmdstimemachineDump.log alcanza un límite máximo de 10 MB, se produce la rotación y se crea un nuevo archivo cmmdstimemachineDump. Sin embargo, durante la rotación, en los registros vmsyslogd.err es posible que aparezca un error como el siguiente:
  2021-04-08T03:15:53.719Z vmsyslog.loggers.file : ERROR ] Failed to write header on rotate. Exception: [Errno 2] No such file or directory: '/var/run/cmmdstimemachineDumpHeader.txt'

  El problema está resuelto en esta versión.

• PR 2738238: La tarea de cambio de formato de objeto tarda mucho en responder

  En algunos casos, el servicio de supervisión, pertenencia y directorio (CMMDS) del clúster no proporciona una entrada correcta a la tarea de cambio de formato de objeto y la tarea tarda mucho en responder.

  El problema está resuelto en esta versión.

• PR 2799408: La actualización de un clúster ampliado a la versión ESXi 7.0 Update 2 o posterior puede provocar un error en varios hosts ESX con una pantalla de diagnóstico de color púrpura

  En raras ocasiones, si se reemplaza el host testigo durante el proceso de actualización y se ejecuta una tarea de conversión de formato de disco poco después del reemplazo, se puede producir un error en varios hosts ESX en un clúster ampliado con una pantalla de diagnóstico de color púrpura.

  El problema está resuelto en esta versión.

• PR 2949777: Si la configuración LargeBAR de un dispositivo vmxnet3 está habilitada en ESX 7.0 Update 3 y versiones posteriores, es posible que las máquinas virtuales pierdan conectividad

  La configuración LargeBAR que extiende el registro de direcciones base (BAR) en un dispositivo vmxnet3 admite el acceso directo uniforme (UNIFORM Passthrough, UPT). Sin embargo, UPT no es compatible con ESX 7.0 Update 3 y versiones posteriores, y si el controlador vmxnet3 se degrada a una versión anterior a 7.0 y la configuración de LargeBAR está habilitada, es posible que las máquinas virtuales pierdan conectividad.

  El problema está resuelto en esta versión.

esx-update_7.0.2-0.20.18426014

Categoría de revisión	Corrección de error
Gravedad de la revisión	Crítico
Reinicio de host requerido	Sí
Migración de máquina virtual o apagado requeridos	Sí
Hardware afectado	N/C
Software afectado	N/C
VIB que se incluyen	VMware_bootbank_loadesx_7.0.2-0.20.18426014 VMware_bootbank_esx-update_7.0.2-0.20.18426014
PR corregidas	2722263, 2812906
Números CVE	N/C

Actualiza los VIB loadesx y esx-update para resolver el siguiente problema:

• PR 2722263: No se pueden eliminar componentes de una imagen de ESXi personalizada después de actualizar a ESXi 7.0 Update 2a

  Si crea una imagen personalizada de 7.0 Update 2a mediante el kit de empaquetado de ESXi, reemplace algunos de los componentes de la imagen base, por ejemplo, Intel-ixgben:1.8.9.0-1OEM.700.1.0.15525992 y, a continuación, actualice los hosts ESXi 7.0.x, no podrá eliminar el componente personalizado después de la actualización. Además, es posible que falten algunos VIB de los componentes personalizados.

  El problema está resuelto en esta versión.

• PR 2812906: Los metadatos de los almacenes de datos de VMFS pueden dañarse en ciertos escenarios de implementación de ESXi debido a la duplicación de los identificadores únicos universales (UUID) del sistema

  Ciertos escenarios de implementación, como la clonación de bancos de arranque de ESXi, pueden derivar parcialmente en UUID completamente idénticos para varios hosts ESXi. Dado que los UUID se utilizan para las operaciones de latido y diario de VMFS, cuando se duplican los UUID, después de las operaciones de instalación o actualización, varios hosts ESXi pueden intentar acceder a regiones de metadatos en el mismo almacén de datos de VMFS. Como resultado, es posible que se produzcan daños en los metadatos en algunos almacenes de datos de VMFS.
  En los registros de vmkernel, aparecen mensajes como:
  VMkernel 608: VMFS volume DCS_HCFA_TEDS_Regulated_10032/5ba2905b-ac11166d-b145-0025b5920a02 on naa.60060e8012a34f005040a34f00000d64:1 has been detected corrupted.
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 319: FS3RCMeta 2245 200 21 105 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 326: 0 0 0 0 0 0 0 0 0 0 0 7 0 254 1 4 0 248 3 96 0 0 0 0 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 332: 0 0 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 338: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

  Algunos escenarios de implementación afectados son la reutilización de perfiles de hardware; por ejemplo, sistemas Blade que utilizan el mismo MAC para implementar una nueva instancia y mover discos de arranque entre servidores.
  

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

Broadcom-bnxt-Net-RoCE_216.0.0.0-1vmw.702.0.20.18426014

Categoría de revisión	Corrección de error
Gravedad de la revisión	Importante
Reinicio de host requerido	Sí
Migración de máquina virtual o apagado requeridos	Sí
Hardware afectado	N/C
Software afectado	N/C
VIB que se incluyen	VMW_bootbank_bnxtroce_216.0.58.0-20vmw.702.0.20.18426014 VMW_bootbank_bnxtnet_216.0.50.0-34vmw.702.0.20.18426014
PR corregidas	N/C
Números CVE	N/C

Actualiza el VIB bnxtroce.

MRVL-E4-CNA-Driver-Bundle_1.0.0.0-1vmw.702.0.20.18426014

Categoría de revisión	Corrección de error
Gravedad de la revisión	Importante
Reinicio de host requerido	Sí
Migración de máquina virtual o apagado requeridos	Sí
Hardware afectado	N/C
Software afectado	N/C
VIB que se incluyen	VMW_bootbank_qedrntv_3.40.5.53-17vmw.702.0.20.18426014 VMW_bootbank_qedentv_3.40.5.53-20vmw.702.0.20.18426014
PR corregidas	N/C
Números CVE	N/C

Actualiza el VIB qedrntv.

Intel-i40en_1.8.1.137-1vmw.702.0.20.18426014

Categoría de revisión	Corrección de error
Gravedad de la revisión	Crítico
Reinicio de host requerido	Sí
Migración de máquina virtual o apagado requeridos	Sí
Hardware afectado	N/C
Software afectado	N/C
VIB que se incluyen	VMW_bootbank_i40enu_1.8.1.137-1vmw.702.0.20.18426014
PR corregidas	2750390
Números CVE	N/C

Actualiza el VIB i40enu para resolver el siguiente problema:

• PR 2750390: Después de una actualización a ESXi 7.0 Update 2a, 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.

  El problema está resuelto en esta versión.

Broadcom-ELX-lpfc_12.8.298.3-2vmw.702.0.20.18426014

Categoría de revisión	Corrección de error
Gravedad de la revisión	Crítico
Reinicio de host requerido	Sí
Migración de máquina virtual o apagado requeridos	Sí
Hardware afectado	N/C
Software afectado	N/C
VIB que se incluyen	VMW_bootbank_lpfc_12.8.298.3-2vmw.702.0.20.18426014
PR corregidas	2715138
Números CVE	N/C

Actualiza el VIB lpfc para resolver el siguiente problema:

• PR 2715138: Los hosts ESXi pueden generar un error con una pantalla de diagnóstico de color púrpura durante la instalación del complemento Dell EMC PowerPath

  Un error inusual de Page Fault puede provocar un error en los hosts ESXi con una pantalla de diagnóstico de color púrpura durante la instalación del complemento Dell EMC PowerPath.

  El problema está resuelto en esta versión.

VMware-vmkusb_0.1-4vmw.702.0.20.18426014

Categoría de revisión	Corrección de error
Gravedad de la revisión	Crítico
Reinicio de host requerido	Sí
Migración de máquina virtual o apagado requeridos	Sí
Hardware afectado	N/C
Software afectado	N/C
VIB que se incluyen	VMW_bootbank_vmkusb_0.1-4vmw.702.0.20.18426014
PR corregidas	2753546
Números CVE	N/C

Actualiza el VIB vmkusb para resolver los siguientes problemas

• PR 2753546: Si utiliza un dispositivo de arranque USB, la conexión a la partición /bootbank puede interrumpirse o dañar la partición VMFS-L LOCKER

  Si la controladora del host USB se desconecta del sistema vSphere y cualquier recurso del dispositivo, como los archivos de volcado, sigue en uso por ESXi, la ruta de acceso del dispositivo no se podrá liberar cuando el dispositivo se vuelva a conectar. Como resultado, ESXi proporciona una nueva ruta de acceso al dispositivo USB, lo que interrumpe la conexión con la partición /bootbank o daña la partición VMFS-L LOCKER.

  El problema está resuelto en esta versión. La solución mejora el controlador de la controladora del host USB para que tolere errores de tiempo de espera del comando para permitir el tiempo suficiente a ESXi para liberar recursos de dispositivos USB.
  Como práctica recomendada, no establezca la partición de volcado en el dispositivo de almacenamiento USB. Para obtener más información, consulte los artículos 2077516 y 2149257 de la base de conocimientos de VMware.

ESXi_7.0.2-0.15.18295176

Categoría de revisión	Seguridad
Gravedad de la revisión	Crítico
Reinicio de host requerido	Sí
Migración de máquina virtual o apagado requeridos	Sí
Hardware afectado	N/C
Software afectado	N/C
VIB que se incluyen	VMware_bootbank_vdfs_7.0.2-0.15.18295176 VMware_bootbank_esx-xserver_7.0.2-0.15.18295176 VMware_bootbank_esx-base_7.0.2-0.15.18295176 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.15.18295176 VMware_bootbank_crx_7.0.2-0.15.18295176 VMware_bootbank_native-misc-drivers_7.0.2-0.15.18295176 VMware_bootbank_cpu-microcode_7.0.2-0.15.18295176 VMware_bootbank_gc_7.0.2-0.15.18295176 VMware_bootbank_vsanhealth_7.0.2-0.15.18295176 VMware_bootbank_clusterstore_7.0.2-0.15.18295176 VMware_bootbank_vsan_7.0.2-0.15.18295176
PR corregidas	2738816, 2738857, 2735594
Números CVE	N/C

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.

Actualiza los VIB vdfs, esx-xserver, esx-base, esx-dvfilter-generic-fastpath, crx, native-misc-drivers, cpu-microcode, gc, vsanhealth, clusterstore, vsan, y esx-base para resolver los siguientes problemas:

• Actualización de OpenSSH

  OpenSSH se actualizó a la versión 8.5p1.

• Actualización de la biblioteca OpenSSL

  La biblioteca OpenSSL se actualizó a la versión openssl-1.0.2y.

• Actualización de la biblioteca Libarchive

  La biblioteca Libarchive se actualizó a la versión 3.5.1.

esx-update_7.0.2-0.15.18295176

Categoría de revisión	Seguridad
Gravedad de la revisión	Crítico
Reinicio de host requerido	Sí
Migración de máquina virtual o apagado requeridos	Sí
Hardware afectado	N/C
Software afectado	N/C
VIB que se incluyen	VMware_bootbank_loadesx_7.0.2-0.15.18295176 VMware_bootbank_esx-update_7.0.2-0.15.18295176
PR corregidas	N/C
Números CVE	N/C

Actualiza los VIB loadesx y esx-update.

VMware-VM-Tools_11.2.6.17901274-18295176

Categoría de revisión	Seguridad
Gravedad de la revisión	Crítico
Reinicio de host requerido	No
Migración de máquina virtual o apagado requeridos	No
Hardware afectado	N/C
Software afectado	N/C
VIB que se incluyen	VMware_locker_tools-light_11.2.6.17901274-18295176
PR corregidas	2761942
Números CVE	N/C

Actualiza el VIB tools-light para resolver el siguiente problema:

• ESXi incluye las siguientes imágenes ISO de VMware Tools 11.2.6:

  • windows.iso: Imagen de VMware Tools para Windows 7 SP1 o Windows Server 2008 R2 SP1 o posterior
  • linux.iso: Imagen de VMware Tools 10.3.23 para versiones anteriores del sistema operativo Linux con una versión de glibc 2.5 o posterior

  Las siguientes imágenes ISO de VMware Tools 10.3.10 están disponibles para la descarga:

  • solaris.iso: imagen de VMware Tools para Solaris
  • darwin.iso: Imagen de VMware Tools para Mac OS X versiones 10.11 y posteriores.

  Siga los procedimientos enumerados en los siguientes documentos para descargar VMware Tools para las plataformas que no se incluyen en ESXi:

  • Notas de la versión de VMware Tools 11.2.6
  • Qué debe saber cada administrador de vSphere acerca de VMware Tools
  • VMware Tools para hosts aprovisionados mediante Auto Deploy
  • Actualización de VMware Tools

VMware-vmkusb_0.1-1vmw.702.0.15.18295176

Categoría de revisión	Seguridad
Gravedad de la revisión	Moderado
Reinicio de host requerido	Sí
Migración de máquina virtual o apagado requeridos	Sí
Hardware afectado	N/C
Software afectado	N/C
VIB que se incluyen	VMW_bootbank_vmkusb_0.1-1vmw.702.0.15.18295176
PR corregidas	N/C
Números CVE	N/C

Actualiza el VIB vmkusb.

ESXi-7.0U2c-18426014-estándar

Nombre del perfil	ESXi-7.0U2c-18426014-estándar
Compilación	Para obtener información sobre la compilación, consulte Revisiones incluidas en esta versión.
Proveedor	VMware, Inc.
Fecha de versión	24 de agosto de 2021
Nivel de aceptación	PartnerSupported
Hardware afectado	N/C
Software afectado	N/C
VIB afectados	VMware_bootbank_vsanhealth_7.0.2-0.20.18426014 VMware_bootbank_vsan_7.0.2-0.20.18426014 VMware_bootbank_gc_7.0.2-0.20.18426014 VMware_bootbank_esx-xserver_7.0.2-0.20.18426014 VMware_bootbank_clusterstore_7.0.2-0.20.18426014 VMware_bootbank_vdfs_7.0.2-0.20.18426014 VMware_bootbank_native-misc-drivers_7.0.2-0.20.18426014 VMware_bootbank_cpu-microcode_7.0.2-0.20.18426014 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.20.18426014 VMware_bootbank_esx-base_7.0.2-0.20.18426014 VMware_bootbank_loadesx_7.0.2-0.20.18426014 VMware_bootbank_esx-update_7.0.2-0.20.18426014 VMW_bootbank_bnxtroce_216.0.58.0-20vmw.702.0.20.18426014 VMW_bootbank_bnxtnet_216.0.50.0-34vmw.702.0.20.18426014 VMW_bootbank_qedrntv_3.40.5.53-17vmw.702.0.20.18426014 VMW_bootbank_qedentv_3.40.5.53-20vmw.702.0.20.18426014 VMW_bootbank_i40enu_1.8.1.137-1vmw.702.0.20.18426014 VMW_bootbank_lpfc_12.8.298.3-2vmw.702.0.20.18426014 VMW_bootbank_vmkusb_0.1-4vmw.702.0.20.18426014
PR corregidas	2717698, 2731446, 2515171, 731306, 2751564, 2718934, 2755056, 2725886, 2725886, 2753231, 2728910, 2741111, 2759343, 2721379, 2751277, 2708326, 2755977, 2737934, 2777001, 2760932, 2731263, 2731142, 2760267, 2749688, 2763986, 2765534, 2766127, 2777003, 2778793, 2755807, 2760081, 2731644, 2749815, 2749962, 2738238, 2799408, 2722263, 2812906, 2750390, 2715138, 2753546
Números de CVE relacionados	N/C

Esta revisión actualiza los siguientes problemas:

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

  • En raras ocasiones, mientras se enciende el dispositivo de vSphere Replication, se puede producir un error en el servicio hostd y provocar que los hosts ESXi no respondan temporalmente a vCenter Server. El servicio hostd se reinicia automáticamente y la conectividad se restaura.

  • Cuando se intenta definir un valor como false para un parámetro de opción avanzada en un perfil de host, la interfaz de usuario crea un valor de cadena no vacío. Los valores que no están vacíos se interpretan como true y el parámetro de opción avanzada recibe el valor true en el perfil de host.

  • Los hosts ESXi podrían dejar de responder a vCenter Server incluso cuando los hosts están accesibles y en ejecución. El problema se produce en imágenes de proveedor con controladores personalizados en los que ImageConfigManager consume más RAM que la asignada. Como resultado, errores repetidos de ImageConfigManager hacen que los hosts ESXi se desconecten de vCenter Server.
    En los registros de VMkernel, aparecen errores repetidos como:
    Admission failure in path: host/vim/vmvisor/hostd-tmp/sh.<pid1>:python.<pid2>:uw.<pid2>.
    En los registros de hostd, aparecen mensajes como: Task Created : haTask-ha-host-vim.host.ImageConfigManager.fetchSoftwarePackages-<sequence>, followed by: ForkExec(/usr/bin/sh) <pid1>, donde <pid1> identifica un proceso ImageConfigManager .

  • Si cambia la opción de configuración avanzada DiskMaxIOSize a un valor inferior, las operaciones de E/S con tamaños de bloque grandes pueden dividirse y colocarse en cola de forma incorrecta en la ruta de acceso de PSA. Como resultado, es posible que se agote el tiempo de espera de las operaciones de E/S de los hosts ESXi y se produzca un error.

  • En determinadas condiciones, las operaciones de encendido o apagado de las máquinas virtuales pueden tardar hasta 20 minutos. El problema se produce cuando el almacenamiento subyacente de las máquinas virtuales ejecuta una operación en segundo plano, como volver a examinar HBA o eventos de APD, y algunos bloqueos se mantienen continuamente.

  • En raras ocasiones, cuando el tamaño de respuesta de la página VPD del host ESXi de destino es diferente en rutas distintas al host, ESXi puede escribir más bytes que la longitud asignada para una ruta de acceso determinada. Como resultado, se produce un error en el host ESXi con una pantalla de diagnóstico de color púrpura y un mensaje como el siguiente:
    Panic Message: @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4878 - Corruption in dlmalloc

  • Una contención de bloqueo inusual puede provocar errores en las operaciones de la máquina virtual, como la conmutación por error o la migración.
    Los mensajes de error de bloqueo son similares a los siguientes:
    vol 'VM_SYS_11', lock at 480321536: [Req mode 1] Checking liveness:
type 10c00003 offset 480321536 v 1940464, hb offset 3801088
    o
    Res3: 2496: Rank violation threshold reached: cid 0xc1d00002, resType 2, cnum 5 vol VM_SYS_11

  • En flujos de trabajo complicados que provocan la creación de varias máquinas virtuales, al desplazarse hasta Máquinas virtuales > Máquinas virtuales, es posible que aparezcan grandes números en la columna Espacio aprovisionado de algunas máquinas virtuales. Por ejemplo, 2,95 TB en lugar del espacio aprovisionado real de 25 GB.

  • Al controlar el comando SCSI READ CAPACITY (10), es posible que ESXi copie el exceso de datos de la respuesta y dañe la pila de llamadas. Como resultado, se produce un error en el host ESXi con una pantalla de diagnóstico de color púrpura.

  • En muy raras ocasiones, es posible que no se bloqueen los clústeres de recursos de VMFS que se incluyen en una transacción de diario. Como resultado, durante el encendido de las máquinas virtuales, se puede producir un error en varios hosts ESXi con una pantalla de diagnóstico de color púrpura debido a la excepción 14 en la capa de VMFS. A continuación, se muestra un seguimiento típico de la pila y el mensaje que se ve en el registro de VMkernel:
    @BlueScreen: #PF Exception 14 in world 2097684:VSCSI Emulat IP 0x418014d06fca addr 0x0
    PTEs:0x16a47a027;0x600faa8007;0x0;
    2020-06-24T17:35:57.073Z cpu29:2097684)Inicio del código: 0x418013c00000 VMK uptime: 0:01:01:20.555
2020-06-24T17:35:57.073Z cpu29:2097684)0x451a50a1baa0:[0x418014d06fca]Res6MemUnlockTxnRCList@esx#nover+0x176 pila: 0x1 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb10:[0x418014c7cdb6]J3_DeleteTransaction@esx#nover+0x33f pila: 0xbad0003
2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb40:[0x418014c7db10]J3_AbortTransaction@esx#nover+0x105 pila: 0x0 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb80:[0x418014cbb752]Fil3_FinalizePunchFileHoleTxnVMFS6@esx#nover+0x16f pila: 0x430fe950e1f0
2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bbd0:[0x418014c7252b]Fil3UpdateBlocks@esx#nover+0x348 pila: 0x451a50a1bc78 2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bce0:[0x418014c731dc]Fil3_PunchFileHoleWithRetry@esx#nover+0x89 pila: 0x451a50a1bec8
2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bd90:[0x418014c739a5]Fil3_FileBlockUnmap@esx#nover+0x50e pila: 0x230eb5 2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be40:[0x418013c4c551]FSSVec_FileBlockUnmap@vmkernel#nover+0x6e pila: 0x230eb5
2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be90:[0x418013fb87b1]VSCSI_ExecFSSUnmap@vmkernel#nover+0x8e pila: 0x0 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf00:[0x418013fb71cb]VSCSIDoEmulHelperIO@vmkernel#nover+0x2c pila: 0x430145fbe070
2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf30:[0x418013ceadfa]HelperQueueFunc@vmkernel#nover+0x157 pila: 0x430aa05c9618 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bfe0:[0x418013f0eaa2]CpuSched_StartWorld@vmkernel#nover+0x77 pila: 0x0
2020-06-24T17:35:57.083Z cpu29:2097684)base fs=0x0 gs=0x418047400000 Kgs=0x0

  • En raras ocasiones, es posible que algunas CPU Intel no puedan reenviar capturas de #DB y, si se produce una interrupción del temporizador durante la llamada del sistema Windows, la máquina virtual podría triplicar el error.

  • Si reinicia agentes de administración de ESXi desde DCUI, el servicio sfcbd no se inicia. Debe iniciar manualmente el servicio SFCB.

  • El servicio hostd registra el mensaje BuildPowerSupplySensorList found 0 power supply sensors cada 2 minutos. El problema se produce cuando se actualiza a ESXi 7.0 Update 1 o se instala nuevamente en un host ESXi.

  • En raras ocasiones, el asignador de memoria del kernel puede devolver un puntero NULL cuya referencia no podría anularse correctamente. Como resultado, se puede producir un error en el host ESXi con una pantalla de diagnóstico de color púrpura, como #GP Exception 13 in world 2422594:vmm:overCom @ 0x42003091ede4. En el seguimiento inverso, aparecen errores similares a los siguientes:
    #1 Util_ZeroPageTable
#2 Util_ZeroPageTableMPN
#3 VmMemPfUnmapped
#4 VmMemPfInt
#5 VmMemPfGetMapping
#6 VmMemPf
#7 VmMemPfLockPageInt
#8 VMMVMKCall_Call
#9 VMKVMM_ArchEnterVMKernel

  • 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 púrpura donde se muestre un error similar a #PF Exception ... in world ...:vmkdevmgr.

  • Cuando un host ESXi no tiene bloques de archivos grandes libres (LFB) para asignar, el host cumple con el aprovisionamiento de VMDK grueso o la creación de un archivo de intercambio con bloques de archivos pequeños (SFB). Sin embargo, en raras ocasiones, es posible que el host no pueda asignar también SFB. Como resultado, se produce un error en el aprovisionamiento de VMDK grueso o en la creación de un archivo de intercambio. Cuando las máquinas virtuales intentan encenderse, se muestra un error en los registros de VMkernel como el siguiente:
     vmkernel.1:2021-01-08T19:13:28.341Z cpu20:2965260)Fil3: 10269: Max no space retries (10) exceeded for caller Fil3_SetFileLength (status 'No space left on device')

  • Cuando se utilizan almacenes de datos de VMFS6 muy grandes, el proceso de asignación de bloques de archivos para VMDK finos en un clúster de recursos puede provocar un bloqueo de CPU. Como resultado, se ven mensajes de bloqueo de CPU y, en casos excepcionales, es posible que se produzca un error en hosts ESXi. En el seguimiento inverso, se muestran mensajes similares al siguiente:
    2021-04-07T02:18:08.730Z cpu31:2345212)ADVERTENCIA: Heartbeat: 849: PCPU 10 didn't have a heartbeat for 7 seconds; *may* be locked up.
    El seguimiento inverso asociado relacionado con funciones Res6AffMgr tiene un aspecto similar al siguiente:
    2021-01-06T02:16:16.073Z cpu0:2265741)ALERTA: NMI: 694: NMI IPI: RIPOFF(base):RBP:CS [0x121d74d(0x42001a000000):0x50d0:0xf48] (Src 0x1, CPU0)
2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b320:[0x42001b21d74c]Res6AffMgrComputeSortIndices@esx#nover+0x369 pila: 0x43119125a000
2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b3b0:[0x42001b224e46]Res6AffMgrGetCluster@esx#nover+0xb1f pila: 0xd 2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b4b0:[0x42001b226491]Res6AffMgr_AllocResourcesInt@esx#nover+0x40a pila: 0x4311910f4890
2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b680:[0x42001b2270e2]Res6AffMgr_AllocResources@esx#nover+0x1b pila: 0x0

  • Durante una actualización a ESXi 7.0 Update 2 o después de ella, es posible que la capa de almacenamiento de ESX no asigne suficientes recursos de memoria para los hosts ESXi con un gran número de CPU físicas y muchos dispositivos de almacenamiento o rutas de acceso conectados a los hosts. Como resultado, se puede producir un error en dichos hosts ESXi con una pantalla de diagnóstico de color púrpura.

  • Las máquinas virtuales con hardware versión 18 y VMware Tools 11.2.0 o versiones posteriores pueden generar errores debido a un problema de dispositivo de gráficos virtuales en el lado de destino durante una instancia de vSphere vMotion o Storage vMotion.
    En vmkernel.log se muestra una línea como la siguiente:
    PF failed to handle a fault on mmInfo at va 0x114f5ae0: Out of memory. Terminating...

  • Después de actualizar a la versión de hardware 18, algunos sistemas operativos invitados, como CentOS 7, en las CPU AMD pueden generar un error de detención del kernel al arrancar la máquina virtual. Aparece el mensaje de pánico del kernel cuando abre una consola web para la máquina virtual.

  • Algunos kernels de Linux agregan la opción Límite de encapsulación de túnel de IPv6 a paquetes de túnel IPv6, como se describe en RFC 2473, par. 5.1. Como resultado, los paquetes de túnel IPv6 se descartan en el tráfico entre las máquinas virtuales, debido al encabezado de extensión IPv6.

  • Cuando los medios virtuales, como una unidad de CD, se conectan al entorno de vSphere mediante una instancia integrada de Dell Remote Access Controller (iDRAC) y no se asigna ningún archivo de medios a la unidad, es posible que aparezcan varios mensajes de advertencia en el registro de vmkernel como los siguientes:
    vmw_psp_fixed: psp_fixedSelectPathToActivateInt:439: Switching to preferred path vmhba32:C0:T0:L1 in STANDBY state for device mpx.vmhba32:C0:T0:L1.WARNING: vmw_psp_fixed: psp_fixedSelectPathToActivateInt:464: Selected current STANDBY path vmhba32:C0:T0:L1 for device mpx.vmhba32:C0:T0:L1 to activate. This may lead to path thrashing.

  • Durante los flujos de trabajo de sincronización de 24 horas de vSphere Distributed Switch, es posible que vCenter Server quite de forma intermitente puertos virtuales distribuidos controlados NSX, como el puerto de reenvío de plano de servicio (SPF), de hosts ESXi. Por ello, es posible que se produzcan errores en operaciones de vSphere vMotion de máquinas virtuales. Se muestra un error como Could not connect SPF port : Not found en los registros.

  • ESXi 7.0 introdujo la partición ESX-OSData basada en VMFS-L, que asume la función de la partición desde cero heredada, la partición del bloqueador para VMware Tools y el destino del volcado de núcleo. Si configura la partición desde cero en el directorio raíz de un volumen VMFS durante una actualización a ESXi 7.0.x, el sistema intenta convertir los archivos VMFS en formato VMFS-L para que coincidan con los requisitos de partición de OS-Data. Como resultado, es posible que la partición OS-Data sobrescriba el volumen VMFS y cause la pérdida de datos.

  • Debido a un problema de control de registros, después de una actualización a ESXi 7.0 Update 2a, cuando se comprueba el estado de mantenimiento del canal de comunicación, se ven todos los hosts ESXi con el estado inactivo, ya que NSX Manager no puede conectarse al agente de firewall.

  • Si se instala un host ESXi versión 7.0 Update 2 en un LUN FCoE y utiliza el modo de arranque UEFI, cuando se intenta actualizar el host mediante vSphere QuickBoot, se puede producir un error en el servidor físico con una pantalla de diagnóstico de color púrpura debido a un error de memoria.

  • 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

  • Es posible que se produzca una ralentización de hasta 60 minutos en el tiempo de arranque de los hosts ESXi después de una actualización a ESXi Update 2a.
    Este problema no afecta a las actualizaciones a ESXi Update 2a de versiones anteriores de ESXi 7.0.x.
    El problema solo se produce cuando se utiliza una línea base o imagen de vSphere Lifecycle Manager, o bien el comando esxcli software profile update para realizar la operación de actualización. Si utiliza una imagen ISO o una instalación generada por script, no se produce el problema.
    Es más probable que el problema afecte a las configuraciones de iSCSI, pero está relacionado con el algoritmo de ESXi para la detección de banco de arranque, no con destinos de almacenamiento externo lentos.

  • Debido a una fuga de memoria en la pila del conjunto de puertos, las operaciones de vSphere vMotion en un host ESXi pueden generar un error de memoria agotada. En vSphere Client, se muestra un error, como:
    Failed to reserve port. DVSwitch 50 18 34 d1 76 81 ec 9e-03 62 e2 d4 6f 23 30 ba port 1 39.
Failed with error status: Out of memory.

  • Si vCenter Server no puede resolver vcsa.vmware.com a una dirección IP, no se puede cargar el catálogo de versiones de vSAN. La siguiente comprobación de estado de vSAN muestra una advertencia: Estado del motor de recomendación de compilación de vSAN.
    Es posible que se muestre un mensaje de error similar al siguiente:
    2021-04-12T11:40:59.435Z ERROR vsan-mgmt[32221] [VsanHttpRequestWrapper::urlopen opID=noOpId] Exception while sending request : Cannot resolve localhost or Internet websites.
2021-04-12T11:40:59.435Z WARNING vsan-mgmt[32221] [VsanVumCoreUtil::CheckVumServiceStatus opID=noOpId] Failed to connect VUM service: Cannot resolve localhost or Internet websites.
2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumIntegration::VumStatusCallback opID=noOpId] VUM is not installed or not responsive ​
2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumSystemUtil::HasConfigIssue opID=noOpId] Config issue health.test.vum.vumDisabled exists on entity None

  • Un error de desbordamiento de enteros puede provocar que vSAN DOM emita limpiezas con más frecuencia que la configuración establecida.

  • Cuando una resincronización se ejecuta en paralelo con escrituras de invitado en objetos que son propiedad de un host ESXi, se puede producir un error en el host con una pantalla de diagnóstico de color púrpura.

  • Cuando el archivo cmmdstimemachineDump.log alcanza un límite máximo de 10 MB, se produce la rotación y se crea un nuevo archivo cmmdstimemachineDump. Sin embargo, durante la rotación, en los registros vmsyslogd.err es posible que aparezca un error como el siguiente:
    2021-04-08T03:15:53.719Z vmsyslog.loggers.file : ERROR ] Failed to write header on rotate. Exception: [Errno 2] No such file or directory: '/var/run/cmmdstimemachineDumpHeader.txt'

  • En algunos casos, el servicio de supervisión, pertenencia y directorio (CMMDS) del clúster no proporciona una entrada correcta a la tarea de cambio de formato de objeto y la tarea tarda mucho en responder.

  • En raras ocasiones, si se reemplaza el host testigo durante el proceso de actualización y se ejecuta una tarea de conversión de formato de disco poco después del reemplazo, se puede producir un error en varios hosts ESX en un clúster ampliado con una pantalla de diagnóstico de color púrpura.

  • Si crea una imagen personalizada de 7.0 Update 2a mediante el kit de empaquetado de ESXi, reemplace algunos de los componentes de la imagen base, por ejemplo, Intel-ixgben:1.8.9.0-1OEM.700.1.0.15525992 y, a continuación, actualice los hosts ESXi 7.0.x, no podrá eliminar el componente personalizado después de la actualización. Además, es posible que falten algunos VIB de los componentes personalizados.

  • Al clonar un dispositivo de arranque ESXi, se crean instancias con UUID idénticos. Dado que los UUID se utilizan para las operaciones de latido y diario de VMFS, cuando se duplican los UUID, después de las operaciones de instalación o actualización, varios hosts ESXi intentan acceder a regiones de metadatos en el mismo almacén de datos de VMFS. Como resultado, es posible que vea daños masivos en los metadatos de los almacenes de datos de VMFS en varios hosts ESXi.
    En los registros de vmkernel, aparecen mensajes como:
    VMkernel 608: VMFS volume DCS_HCFA_TEDS_Regulated_10032/5ba2905b-ac11166d-b145-0025b5920a02 on naa.60060e8012a34f005040a34f00000d64:1 has been detected corrupted.
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 319: FS3RCMeta 2245 200 21 105 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 326: 0 0 0 0 0 0 0 0 0 0 0 7 0 254 1 4 0 248 3 96 0 0 0 0 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 332: 0 0 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 338: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

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

  • Un error inusual de Page Fault puede provocar un error en los hosts ESXi con una pantalla de diagnóstico de color púrpura durante la instalación del complemento Dell EMC PowerPath.

  • Si la controladora del host USB se desconecta del sistema vSphere y cualquier recurso del dispositivo, como los archivos de volcado, sigue en uso por ESXi, la ruta de acceso del dispositivo no se podrá liberar cuando el dispositivo se vuelva a conectar. Como resultado, ESXi proporciona una nueva ruta de acceso al dispositivo USB, lo que interrumpe la conexión con la partición /bootbank o daña la partición VMFS-L LOCKER.

ESXi-7.0U2c-18426014-sin-herramientas

Nombre del perfil	ESXi-7.0U2c-18426014-sin-herramientas
Compilación	Para obtener información sobre la compilación, consulte Revisiones incluidas en esta versión.
Proveedor	VMware, Inc.
Fecha de versión	24 de agosto de 2021
Nivel de aceptación	PartnerSupported
Hardware afectado	N/C
Software afectado	N/C
VIB afectados	VMware_bootbank_vsanhealth_7.0.2-0.20.18426014 VMware_bootbank_vsan_7.0.2-0.20.18426014 VMware_bootbank_gc_7.0.2-0.20.18426014 VMware_bootbank_esx-xserver_7.0.2-0.20.18426014 VMware_bootbank_clusterstore_7.0.2-0.20.18426014 VMware_bootbank_vdfs_7.0.2-0.20.18426014 VMware_bootbank_native-misc-drivers_7.0.2-0.20.18426014 VMware_bootbank_cpu-microcode_7.0.2-0.20.18426014 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.20.18426014 VMware_bootbank_esx-base_7.0.2-0.20.18426014 VMware_bootbank_loadesx_7.0.2-0.20.18426014 VMware_bootbank_esx-update_7.0.2-0.20.18426014 VMW_bootbank_bnxtroce_216.0.58.0-20vmw.702.0.20.18426014 VMW_bootbank_bnxtnet_216.0.50.0-34vmw.702.0.20.18426014 VMW_bootbank_qedrntv_3.40.5.53-17vmw.702.0.20.18426014 VMW_bootbank_qedentv_3.40.5.53-20vmw.702.0.20.18426014 VMW_bootbank_i40enu_1.8.1.137-1vmw.702.0.20.18426014 VMW_bootbank_lpfc_12.8.298.3-2vmw.702.0.20.18426014 VMW_bootbank_vmkusb_0.1-4vmw.702.0.20.18426014
PR corregidas	2717698, 2731446, 2515171, 731306, 2751564, 2718934, 2755056, 2725886, 2725886, 2753231, 2728910, 2741111, 2759343, 2721379, 2751277, 2708326, 2755977, 2737934, 2777001, 2760932, 2731263, 2731142, 2760267, 2749688, 2763986, 2765534, 2766127, 2777003, 2778793, 2755807, 2760081, 2731644, 2749815, 2749962, 2738238, 2799408, 2722263, 2812906, 2750390, 2715138, 2753546
Números de CVE relacionados	N/C

Esta revisión actualiza los siguientes problemas:

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

  • En raras ocasiones, mientras se enciende el dispositivo de vSphere Replication, se puede producir un error en el servicio hostd y provocar que los hosts ESXi no respondan temporalmente a vCenter Server. El servicio hostd se reinicia automáticamente y la conectividad se restaura.

  • Cuando se intenta definir un valor como false para un parámetro de opción avanzada en un perfil de host, la interfaz de usuario crea un valor de cadena no vacío. Los valores que no están vacíos se interpretan como true y el parámetro de opción avanzada recibe el valor true en el perfil de host.

  • Los hosts ESXi podrían dejar de responder a vCenter Server incluso cuando los hosts están accesibles y en ejecución. El problema se produce en imágenes de proveedor con controladores personalizados en los que ImageConfigManager consume más RAM que la asignada. Como resultado, errores repetidos de ImageConfigManager hacen que los hosts ESXi se desconecten de vCenter Server.
    En los registros de VMkernel, aparecen errores repetidos como:
    Admission failure in path: host/vim/vmvisor/hostd-tmp/sh.<pid1>:python.<pid2>:uw.<pid2>.
    En los registros de hostd, aparecen mensajes como: Task Created : haTask-ha-host-vim.host.ImageConfigManager.fetchSoftwarePackages-<sequence>, followed by: ForkExec(/usr/bin/sh) <pid1>, donde <pid1> identifica un proceso ImageConfigManager .

  • Si cambia la opción de configuración avanzada DiskMaxIOSize a un valor inferior, las operaciones de E/S con tamaños de bloque grandes pueden dividirse y colocarse en cola de forma incorrecta en la ruta de acceso de PSA. Como resultado, es posible que se agote el tiempo de espera de las operaciones de E/S de los hosts ESXi y se produzca un error.

  • En determinadas condiciones, las operaciones de encendido o apagado de las máquinas virtuales pueden tardar hasta 20 minutos. El problema se produce cuando el almacenamiento subyacente de las máquinas virtuales ejecuta una operación en segundo plano, como volver a examinar HBA o eventos de APD, y algunos bloqueos se mantienen continuamente.

  • En raras ocasiones, cuando el tamaño de respuesta de la página VPD del host ESXi de destino es diferente en rutas distintas al host, ESXi puede escribir más bytes que la longitud asignada para una ruta de acceso determinada. Como resultado, se produce un error en el host ESXi con una pantalla de diagnóstico de color púrpura y un mensaje como el siguiente:
    Panic Message: @BlueScreen: PANIC bora/vmkernel/main/dlmalloc.c:4878 - Corruption in dlmalloc

  • Una contención de bloqueo inusual puede provocar errores en las operaciones de la máquina virtual, como la conmutación por error o la migración.
    Los mensajes de error de bloqueo son similares a los siguientes:
    vol 'VM_SYS_11', lock at 480321536: [Req mode 1] Checking liveness:
type 10c00003 offset 480321536 v 1940464, hb offset 3801088
    o
    Res3: 2496: Rank violation threshold reached: cid 0xc1d00002, resType 2, cnum 5 vol VM_SYS_11

  • En flujos de trabajo complicados que provocan la creación de varias máquinas virtuales, al desplazarse hasta Máquinas virtuales > Máquinas virtuales, es posible que aparezcan grandes números en la columna Espacio aprovisionado de algunas máquinas virtuales. Por ejemplo, 2,95 TB en lugar del espacio aprovisionado real de 25 GB.

  • Al controlar el comando SCSI READ CAPACITY (10), es posible que ESXi copie el exceso de datos de la respuesta y dañe la pila de llamadas. Como resultado, se produce un error en el host ESXi con una pantalla de diagnóstico de color púrpura.

  • En muy raras ocasiones, es posible que no se bloqueen los clústeres de recursos de VMFS que se incluyen en una transacción de diario. Como resultado, durante el encendido de las máquinas virtuales, se puede producir un error en varios hosts ESXi con una pantalla de diagnóstico de color púrpura debido a la excepción 14 en la capa de VMFS. A continuación, se muestra un seguimiento típico de la pila y el mensaje que se ve en el registro de VMkernel:
    @BlueScreen: #PF Exception 14 in world 2097684:VSCSI Emulat IP 0x418014d06fca addr 0x0
    PTEs:0x16a47a027;0x600faa8007;0x0;
    2020-06-24T17:35:57.073Z cpu29:2097684)Inicio del código: 0x418013c00000 VMK uptime: 0:01:01:20.555
2020-06-24T17:35:57.073Z cpu29:2097684)0x451a50a1baa0:[0x418014d06fca]Res6MemUnlockTxnRCList@esx#nover+0x176 pila: 0x1 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb10:[0x418014c7cdb6]J3_DeleteTransaction@esx#nover+0x33f pila: 0xbad0003
2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb40:[0x418014c7db10]J3_AbortTransaction@esx#nover+0x105 pila: 0x0 2020-06-24T17:35:57.074Z cpu29:2097684)0x451a50a1bb80:[0x418014cbb752]Fil3_FinalizePunchFileHoleTxnVMFS6@esx#nover+0x16f pila: 0x430fe950e1f0
2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bbd0:[0x418014c7252b]Fil3UpdateBlocks@esx#nover+0x348 pila: 0x451a50a1bc78 2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bce0:[0x418014c731dc]Fil3_PunchFileHoleWithRetry@esx#nover+0x89 pila: 0x451a50a1bec8
2020-06-24T17:35:57.075Z cpu29:2097684)0x451a50a1bd90:[0x418014c739a5]Fil3_FileBlockUnmap@esx#nover+0x50e pila: 0x230eb5 2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be40:[0x418013c4c551]FSSVec_FileBlockUnmap@vmkernel#nover+0x6e pila: 0x230eb5
2020-06-24T17:35:57.076Z cpu29:2097684)0x451a50a1be90:[0x418013fb87b1]VSCSI_ExecFSSUnmap@vmkernel#nover+0x8e pila: 0x0 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf00:[0x418013fb71cb]VSCSIDoEmulHelperIO@vmkernel#nover+0x2c pila: 0x430145fbe070
2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bf30:[0x418013ceadfa]HelperQueueFunc@vmkernel#nover+0x157 pila: 0x430aa05c9618 2020-06-24T17:35:57.077Z cpu29:2097684)0x451a50a1bfe0:[0x418013f0eaa2]CpuSched_StartWorld@vmkernel#nover+0x77 pila: 0x0
2020-06-24T17:35:57.083Z cpu29:2097684)base fs=0x0 gs=0x418047400000 Kgs=0x0

  • En raras ocasiones, es posible que algunas CPU Intel no puedan reenviar capturas de #DB y, si se produce una interrupción del temporizador durante la llamada del sistema Windows, la máquina virtual podría triplicar el error.

  • Si reinicia agentes de administración de ESXi desde DCUI, el servicio sfcbd no se inicia. Debe iniciar manualmente el servicio SFCB.

  • El servicio hostd registra el mensaje BuildPowerSupplySensorList found 0 power supply sensors cada 2 minutos. El problema se produce cuando se actualiza a ESXi 7.0 Update 1 o se instala nuevamente en un host ESXi.

  • En raras ocasiones, el asignador de memoria del kernel puede devolver un puntero NULL cuya referencia no podría anularse correctamente. Como resultado, se puede producir un error en el host ESXi con una pantalla de diagnóstico de color púrpura, como #GP Exception 13 in world 2422594:vmm:overCom @ 0x42003091ede4. En el seguimiento inverso, aparecen errores similares a los siguientes:
    #1 Util_ZeroPageTable
#2 Util_ZeroPageTableMPN
#3 VmMemPfUnmapped
#4 VmMemPfInt
#5 VmMemPfGetMapping
#6 VmMemPf
#7 VmMemPfLockPageInt
#8 VMMVMKCall_Call
#9 VMKVMM_ArchEnterVMKernel

  • 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 púrpura donde se muestre un error similar a #PF Exception ... in world ...:vmkdevmgr.

  • Cuando un host ESXi no tiene bloques de archivos grandes libres (LFB) para asignar, el host cumple con el aprovisionamiento de VMDK grueso o la creación de un archivo de intercambio con bloques de archivos pequeños (SFB). Sin embargo, en raras ocasiones, es posible que el host no pueda asignar también SFB. Como resultado, se produce un error en el aprovisionamiento de VMDK grueso o en la creación de un archivo de intercambio. Cuando las máquinas virtuales intentan encenderse, se muestra un error en los registros de VMkernel como el siguiente:
     vmkernel.1:2021-01-08T19:13:28.341Z cpu20:2965260)Fil3: 10269: Max no space retries (10) exceeded for caller Fil3_SetFileLength (status 'No space left on device')

  • Cuando se utilizan almacenes de datos de VMFS6 muy grandes, el proceso de asignación de bloques de archivos para VMDK finos en un clúster de recursos puede provocar un bloqueo de CPU. Como resultado, se ven mensajes de bloqueo de CPU y, en casos excepcionales, es posible que se produzca un error en hosts ESXi. En el seguimiento inverso, se muestran mensajes similares al siguiente:
    2021-04-07T02:18:08.730Z cpu31:2345212)ADVERTENCIA: Heartbeat: 849: PCPU 10 didn't have a heartbeat for 7 seconds; *may* be locked up.
    El seguimiento inverso asociado relacionado con funciones Res6AffMgr tiene un aspecto similar al siguiente:
    2021-01-06T02:16:16.073Z cpu0:2265741)ALERTA: NMI: 694: NMI IPI: RIPOFF(base):RBP:CS [0x121d74d(0x42001a000000):0x50d0:0xf48] (Src 0x1, CPU0)
2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b320:[0x42001b21d74c]Res6AffMgrComputeSortIndices@esx#nover+0x369 pila: 0x43119125a000
2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b3b0:[0x42001b224e46]Res6AffMgrGetCluster@esx#nover+0xb1f pila: 0xd 2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b4b0:[0x42001b226491]Res6AffMgr_AllocResourcesInt@esx#nover+0x40a pila: 0x4311910f4890
2021-01-06T02:16:16.073Z cpu0:2265741)0x4538d261b680:[0x42001b2270e2]Res6AffMgr_AllocResources@esx#nover+0x1b pila: 0x0

  • Durante una actualización a ESXi 7.0 Update 2 o después de ella, es posible que la capa de almacenamiento de ESX no asigne suficientes recursos de memoria para los hosts ESXi con un gran número de CPU físicas y muchos dispositivos de almacenamiento o rutas de acceso conectados a los hosts. Como resultado, se puede producir un error en dichos hosts ESXi con una pantalla de diagnóstico de color púrpura.

  • Las máquinas virtuales con hardware versión 18 y VMware Tools 11.2.0 o versiones posteriores pueden generar errores debido a un problema de dispositivo de gráficos virtuales en el lado de destino durante una instancia de vSphere vMotion o Storage vMotion.
    En vmkernel.log se muestra una línea como la siguiente:
    PF failed to handle a fault on mmInfo at va 0x114f5ae0: Out of memory. Terminating...

  • Después de actualizar a la versión de hardware 18, algunos sistemas operativos invitados, como CentOS 7, en las CPU AMD pueden generar un error de detención del kernel al arrancar la máquina virtual. Aparece el mensaje de pánico del kernel cuando abre una consola web para la máquina virtual.

  • Algunos kernels de Linux agregan la opción Límite de encapsulación de túnel de IPv6 a paquetes de túnel IPv6, como se describe en RFC 2473, par. 5.1. Como resultado, los paquetes de túnel IPv6 se descartan en el tráfico entre las máquinas virtuales, debido al encabezado de extensión IPv6.

  • Cuando los medios virtuales, como una unidad de CD, se conectan al entorno de vSphere mediante una instancia integrada de Dell Remote Access Controller (iDRAC) y no se asigna ningún archivo de medios a la unidad, es posible que aparezcan varios mensajes de advertencia en el registro de vmkernel como los siguientes:
    vmw_psp_fixed: psp_fixedSelectPathToActivateInt:439: Switching to preferred path vmhba32:C0:T0:L1 in STANDBY state for device mpx.vmhba32:C0:T0:L1.WARNING: vmw_psp_fixed: psp_fixedSelectPathToActivateInt:464: Selected current STANDBY path vmhba32:C0:T0:L1 for device mpx.vmhba32:C0:T0:L1 to activate. This may lead to path thrashing.

  • Durante los flujos de trabajo de sincronización de 24 horas de vSphere Distributed Switch, es posible que vCenter Server quite de forma intermitente puertos virtuales distribuidos controlados NSX, como el puerto de reenvío de plano de servicio (SPF), de hosts ESXi. Por ello, es posible que se produzcan errores en operaciones de vSphere vMotion de máquinas virtuales. Se muestra un error como Could not connect SPF port : Not found en los registros.

  • ESXi 7.0 introdujo la partición ESX-OSData basada en VMFS-L, que asume la función de la partición desde cero heredada, la partición del bloqueador para VMware Tools y el destino del volcado de núcleo. Si configura la partición desde cero en el directorio raíz de un volumen VMFS durante una actualización a ESXi 7.0.x, el sistema intenta convertir los archivos VMFS en formato VMFS-L para que coincidan con los requisitos de partición de OS-Data. Como resultado, es posible que la partición OS-Data sobrescriba el volumen VMFS y cause la pérdida de datos.

  • Debido a un problema de control de registros, después de una actualización a ESXi 7.0 Update 2a, cuando se comprueba el estado de mantenimiento del canal de comunicación, se ven todos los hosts ESXi con el estado inactivo, ya que NSX Manager no puede conectarse al agente de firewall.

  • Si se instala un host ESXi versión 7.0 Update 2 en un LUN FCoE y utiliza el modo de arranque UEFI, cuando se intenta actualizar el host mediante vSphere QuickBoot, se puede producir un error en el servidor físico con una pantalla de diagnóstico de color púrpura debido a un error de memoria.

  • 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

  • Es posible que se produzca una ralentización de hasta 60 minutos en el tiempo de arranque de los hosts ESXi después de una actualización a ESXi Update 2a.
    Este problema no afecta a las actualizaciones a ESXi Update 2a de versiones anteriores de ESXi 7.0.x.
    El problema solo se produce cuando se utiliza una línea base o imagen de vSphere Lifecycle Manager, o bien el comando esxcli software profile update para realizar la operación de actualización. Si utiliza una imagen ISO o una instalación generada por script, no se produce el problema.
    Es más probable que el problema afecte a las configuraciones de iSCSI, pero está relacionado con el algoritmo de ESXi para la detección de banco de arranque, no con destinos de almacenamiento externo lentos.

  • Debido a una fuga de memoria en la pila del conjunto de puertos, las operaciones de vSphere vMotion en un host ESXi pueden generar un error de memoria agotada. En vSphere Client, se muestra un error, como:
    Failed to reserve port. DVSwitch 50 18 34 d1 76 81 ec 9e-03 62 e2 d4 6f 23 30 ba port 1 39.
Failed with error status: Out of memory.

  • Si vCenter Server no puede resolver vcsa.vmware.com a una dirección IP, no se puede cargar el catálogo de versiones de vSAN. La siguiente comprobación de estado de vSAN muestra una advertencia: Estado del motor de recomendación de compilación de vSAN.
    Es posible que se muestre un mensaje de error similar al siguiente:
    2021-04-12T11:40:59.435Z ERROR vsan-mgmt[32221] [VsanHttpRequestWrapper::urlopen opID=noOpId] Exception while sending request : Cannot resolve localhost or Internet websites.
2021-04-12T11:40:59.435Z WARNING vsan-mgmt[32221] [VsanVumCoreUtil::CheckVumServiceStatus opID=noOpId] Failed to connect VUM service: Cannot resolve localhost or Internet websites.
2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumIntegration::VumStatusCallback opID=noOpId] VUM is not installed or not responsive ​
2021-04-12T11:40:59.435Z INFO vsan-mgmt[32221] [VsanVumSystemUtil::HasConfigIssue opID=noOpId] Config issue health.test.vum.vumDisabled exists on entity None

  • Un error de desbordamiento de enteros puede provocar que vSAN DOM emita limpiezas con más frecuencia que la configuración establecida.

  • Cuando una resincronización se ejecuta en paralelo con escrituras de invitado en objetos que son propiedad de un host ESXi, se puede producir un error en el host con una pantalla de diagnóstico de color púrpura.

  • Cuando el archivo cmmdstimemachineDump.log alcanza un límite máximo de 10 MB, se produce la rotación y se crea un nuevo archivo cmmdstimemachineDump. Sin embargo, durante la rotación, en los registros vmsyslogd.err es posible que aparezca un error como el siguiente:
    2021-04-08T03:15:53.719Z vmsyslog.loggers.file : ERROR ] Failed to write header on rotate. Exception: [Errno 2] No such file or directory: '/var/run/cmmdstimemachineDumpHeader.txt'

  • En algunos casos, el servicio de supervisión, pertenencia y directorio (CMMDS) del clúster no proporciona una entrada correcta a la tarea de cambio de formato de objeto y la tarea tarda mucho en responder.

  • En raras ocasiones, si se reemplaza el host testigo durante el proceso de actualización y se ejecuta una tarea de conversión de formato de disco poco después del reemplazo, se puede producir un error en varios hosts ESX en un clúster ampliado con una pantalla de diagnóstico de color púrpura.

  • Si crea una imagen personalizada de 7.0 Update 2a mediante el kit de empaquetado de ESXi, reemplace algunos de los componentes de la imagen base, por ejemplo, Intel-ixgben:1.8.9.0-1OEM.700.1.0.15525992 y, a continuación, actualice los hosts ESXi 7.0.x, no podrá eliminar el componente personalizado después de la actualización. Además, es posible que falten algunos VIB de los componentes personalizados.

  • Al clonar un dispositivo de arranque ESXi, se crean instancias con UUID idénticos. Dado que los UUID se utilizan para las operaciones de latido y diario de VMFS, cuando se duplican los UUID, después de las operaciones de instalación o actualización, varios hosts ESXi intentan acceder a regiones de metadatos en el mismo almacén de datos de VMFS. Como resultado, es posible que vea daños masivos en los metadatos de los almacenes de datos de VMFS en varios hosts ESXi.
    En los registros de vmkernel, aparecen mensajes como:
    VMkernel 608: VMFS volume DCS_HCFA_TEDS_Regulated_10032/5ba2905b-ac11166d-b145-0025b5920a02 on naa.60060e8012a34f005040a34f00000d64:1 has been detected corrupted.
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 319: FS3RCMeta 2245 200 21 105 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 326: 0 0 0 0 0 0 0 0 0 0 0 7 0 254 1 4 0 248 3 96 0 0 0 0 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 332: 0 0 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 338: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2021-06-08T15:58:22.126Z cpu1:2097600)FS3: 346: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

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

  • Un error inusual de Page Fault puede provocar un error en los hosts ESXi con una pantalla de diagnóstico de color púrpura durante la instalación del complemento Dell EMC PowerPath.

  • Si la controladora del host USB se desconecta del sistema vSphere y cualquier recurso del dispositivo, como los archivos de volcado, sigue en uso por ESXi, la ruta de acceso del dispositivo no se podrá liberar cuando el dispositivo se vuelva a conectar. Como resultado, ESXi proporciona una nueva ruta de acceso al dispositivo USB, lo que interrumpe la conexión con la partición /bootbank o daña la partición VMFS-L LOCKER.

ESXi-7.0U2sc-18295176-estándar

Nombre del perfil	ESXi-7.0U2sc-18295176-estándar
Compilación	Para obtener información sobre la compilación, consulte Revisiones incluidas en esta versión.
Proveedor	VMware, Inc.
Fecha de versión	24 de agosto de 2021
Nivel de aceptación	PartnerSupported
Hardware afectado	N/C
Software afectado	N/C
VIB afectados	VMware_bootbank_vdfs_7.0.2-0.15.18295176 VMware_bootbank_esx-xserver_7.0.2-0.15.18295176 VMware_bootbank_esx-base_7.0.2-0.15.18295176 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.15.18295176 VMware_bootbank_crx_7.0.2-0.15.18295176 VMware_bootbank_native-misc-drivers_7.0.2-0.15.18295176 VMware_bootbank_cpu-microcode_7.0.2-0.15.18295176 VMware_bootbank_gc_7.0.2-0.15.18295176 VMware_bootbank_vsanhealth_7.0.2-0.15.18295176 VMware_bootbank_clusterstore_7.0.2-0.15.18295176 VMware_bootbank_vsan_7.0.2-0.15.18295176 VMware_bootbank_loadesx_7.0.2-0.15.18295176 VMware_bootbank_esx-update_7.0.2-0.15.18295176 VMware_locker_tools-light_11.2.6.17901274-18295176 VMW_bootbank_vmkusb_0.1-1vmw.702.0.15.18295176
PR corregidas	2738816, 2738857, 2735594 y 2761942
Números de CVE relacionados	N/C

Esta revisión actualiza los siguientes problemas:

• • OpenSSH se actualizó a la versión 8.5p1.

  • La biblioteca OpenSSL se actualizó a la versión openssl-1.0.2y.

  • La biblioteca Libarchive se actualizó a la versión 3.5.1.

  • ESXi incluye las siguientes imágenes ISO de VMware Tools 11.2.6:

    • windows.iso: Imagen de VMware Tools para Windows 7 SP1 o Windows Server 2008 R2 SP1 o posterior
    • linux.iso: Imagen de VMware Tools 10.3.23 para versiones anteriores del sistema operativo Linux con una versión de glibc 2.5 o posterior

    Las siguientes imágenes ISO de VMware Tools 10.3.10 están disponibles para la descarga:

    • solaris.iso: imagen de VMware Tools para Solaris
    • darwin.iso: Imagen de VMware Tools para Mac OS X versiones 10.11 y posteriores.

    Siga los procedimientos enumerados en los siguientes documentos para descargar VMware Tools para las plataformas que no se incluyen en ESXi:

    • Notas de la versión de VMware Tools 11.2.6
    • Qué debe saber cada administrador de vSphere acerca de VMware Tools
    • VMware Tools para hosts aprovisionados mediante Auto Deploy
    • Actualización de VMware Tools

ESXi-7.0U2sc-18295176-sin-herramientas

Nombre del perfil	ESXi-7.0U2sc-18295176-sin-herramientas
Compilación	Para obtener información sobre la compilación, consulte Revisiones incluidas en esta versión.
Proveedor	VMware, Inc.
Fecha de versión	24 de agosto de 2021
Nivel de aceptación	PartnerSupported
Hardware afectado	N/C
Software afectado	N/C
VIB afectados	VMware_bootbank_vdfs_7.0.2-0.15.18295176 VMware_bootbank_esx-xserver_7.0.2-0.15.18295176 VMware_bootbank_esx-base_7.0.2-0.15.18295176 VMware_bootbank_esx-dvfilter-generic-fastpath_7.0.2-0.15.18295176 VMware_bootbank_crx_7.0.2-0.15.18295176 VMware_bootbank_native-misc-drivers_7.0.2-0.15.18295176 VMware_bootbank_cpu-microcode_7.0.2-0.15.18295176 VMware_bootbank_gc_7.0.2-0.15.18295176 VMware_bootbank_vsanhealth_7.0.2-0.15.18295176 VMware_bootbank_clusterstore_7.0.2-0.15.18295176 VMware_bootbank_vsan_7.0.2-0.15.18295176 VMware_bootbank_loadesx_7.0.2-0.15.18295176 VMware_bootbank_esx-update_7.0.2-0.15.18295176 VMware_locker_tools-light_11.2.6.17901274-18295176 VMW_bootbank_vmkusb_0.1-1vmw.702.0.15.18295176
PR corregidas	2738816, 2738857, 2735594 y 2761942
Números de CVE relacionados	N/C

Esta revisión actualiza los siguientes problemas:

• • OpenSSH se actualizó a la versión 8.5p1.

  • La biblioteca OpenSSL se actualizó a la versión openssl-1.0.2y.

  • La biblioteca Libarchive se actualizó a la versión 3.5.1.

  • ESXi incluye las siguientes imágenes ISO de VMware Tools 11.2.6:

    • windows.iso: Imagen de VMware Tools para Windows 7 SP1 o Windows Server 2008 R2 SP1 o posterior
    • linux.iso: Imagen de VMware Tools 10.3.23 para versiones anteriores del sistema operativo Linux con una versión de glibc 2.5 o posterior

    Las siguientes imágenes ISO de VMware Tools 10.3.10 están disponibles para la descarga:

    • solaris.iso: imagen de VMware Tools para Solaris
    • darwin.iso: Imagen de VMware Tools para Mac OS X versiones 10.11 y posteriores.

    Siga los procedimientos enumerados en los siguientes documentos para descargar VMware Tools para las plataformas que no se incluyen en ESXi:

    • Notas de la versión de VMware Tools 11.2.6
    • Qué debe saber cada administrador de vSphere acerca de VMware Tools
    • VMware Tools para hosts aprovisionados mediante Auto Deploy
    • Actualización de VMware Tools

ESXi Image - ESXi70U2c-18426014

Nombre	ESXi
Versión	ESXi70U2c-18426014
Fecha de versión	24 de agosto de 2020
Categoría	Corrección de error
Componentes afectados	Componente de ESXi: VIB principales ESXi Controlador Emulex FC Controladores Broadcom NetXtreme-E Network y ROCE/RDMA para VMware ESXi Controladores RoCE/RDMA y Ethernet QLogic FastLinQ 10/25/40/50/100 GbE para VMware ESXi Componente de instalación/actualización de ESXi Controlador de red para adaptadores Intel(R) X710/XL710/XXV710/X722 Controlador USB
PR corregidas	2717698, 2731446, 2515171, 731306, 2751564, 2718934, 2755056, 2725886, 2725886, 2753231, 2728910, 2741111, 2759343, 2721379, 2751277, 2708326, 2755977, 2737934, 2777001, 2760932, 2731263, 2731142, 2760267, 2749688, 2763986, 2765534, 2766127, 2777003, 2778793, 2755807, 2760081, 2731644, 2749815, 2749962, 2738238, 2799408, 2722263, 2812906, 2750390, 2715138, 2753546
Números de CVE relacionados	N/C

ESXi image - ESXi70U2sc-18295176

Nombre	ESXi
Versión	ESXi70U2sc-18295176
Fecha de versión	24 de agosto de 2020
Categoría	Seguridad
Componentes afectados	Componente de ESXi: VIB principales ESXi Controlador USB Componente de herramientas de ESXi Componente de instalación/actualización de ESXi
PR corregidas	2738816, 2738857, 2735594 y 2761942
Números de CVE relacionados	N/C

Problemas conocidos

Los problemas conocidos se agrupan del siguiente modo:

• Problemas varios
• Problemas de instalación, actualización y migración
• Problemas conocidos de versiones anteriores

Problemas varios

• El daemon sensord no puede informar el estado de hardware del host ESXi.

  Un error lógico en la validación de SDR de IPMI puede provocar que sensord no pueda identificar un origen para la información de la fuente de alimentación. Como resultado, al ejecutar el comando vsish -e get /power/hostStats, es posible que no vea ningún resultado.

  Solución alternativa: Ninguna

Problemas de instalación, actualización y migración

• Los hosts ESXi podrían perder conectividad después de actualizar el controlador brcmfcoe en matrices de almacenamiento Hitachi

  Después de actualizar el controlador brcmfcoe en matrices de almacenamiento Hitachi, es posible que los hosts ESXi no arranquen y pierdan conectividad.

  Solución alternativa: Ninguna.

Problemas conocidos de versiones anteriores

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

Los problemas conocidos anteriores se agrupan del siguiente modo.

• Problemas de vSAN
• Problemas de instalación, actualización y migración
• Problemas con funciones de seguridad
• Problemas de redes
• Problemas de almacenamiento
• Problemas en vCenter Server y vSphere Client
• Problemas en la administración de máquinas virtuales
• Problemas con vSphere HA y Fault Tolerance
• Problemas en vSphere Lifecycle Manager
• Problemas varios

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

• Se produce un error en las comprobaciones previas a la actualización o la migración de vCenter con el mensaje "Unexpected error 87"

  Se produce un error en las comprobaciones previas a la actualización o la migración de vCenter Server cuando el certificado del servicio de token de seguridad (Security Token Service, STS) no contiene un campo de nombre alternativo del firmante (Subject Alternative Name, SAN). Esta situación se produce cuando se reemplaza el certificado de Single Sign-On para vCenter 5.5 por un certificado personalizado que no tiene un campo de SAN y se intenta actualizar a vCenter Server 7.0. La actualización considera que el certificado de STS no es válido y las comprobaciones previas evitan que continúe el proceso de actualización.

  Solución alternativa: Reemplace el certificado de STS por un certificado válido que contenga un campo de SAN y, a continuación, continúe con la actualización o la migración a vCenter Server 7.0.

• Problemas de actualización a vSphere 7.0 con proveedores de CIM preexistentes

  Después de la actualización, los proveedores de CIM de 32 bits instalados anteriormente dejan de funcionar debido a que ESXi requiere proveedores de CIM de 64 bits. Los clientes pueden perder las funciones de la API de administración relacionadas con CIMPDK, DDK nativo (Native DDK, NDDK), HEXDK y VAIODK (filtros de E/S), y ver errores relacionados con la dependencia uwglibc.
  El servidor syslog informa de la ausencia de un módulo: "No se cargaron las bibliotecas compartidas de 32 bits".

  Solución alternativa: No existe una solución alternativa. La solución es descargar los nuevos proveedores de CIM de 64 bits del proveedor.

• Se puede producir un error en la instalación de los controladores de 7.0 Update 1 en los hosts de ESXi 7.0

  No se pueden instalar controladores aplicables a ESXi 7.0 Update 1 en hosts que ejecutan ESXi 7.0 o 7.0b.
  Se produce un error en la operación, como:
  VMW_bootbank_qedrntv_3.40.4.0-12vmw.701.0.0.xxxxxxx requiere vmkapi_2_7_0_0, pero no se puede cumplir el requisito dentro de ImageProfile. ​
Consulte el archivo de registro para obtener más detalles.

  Solución alternativa: Actualice el host ESXi a 7.0 Update 1. Vuelva a intentar la instalación del controlador.

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

• Es posible que la autenticación de tarjeta inteligente y de RSA SecurID deje de funcionar después de actualizar a vCenter Server 7.0

  Si configuró vCenter Server para la autenticación de tarjeta inteligente o de RSA SecurID, consulte el artículo de la base de conocimientos de VMware en https://kb.vmware.com/s/article/78057 antes de iniciar el proceso de actualización de vSphere 7.0. Si no implementa la solución alternativa como se describe en la base de conocimientos, es posible que vea los siguientes mensajes de error y que la autenticación de RSA SecurID o de tarjeta inteligente no funcione.

  "Smart card authentication may stop working. Smart card settings may not be preserved, and smart card authentication may stop working."

  o

  "RSA SecurID authentication may stop working. RSA SecurID settings may not be preserved, and RSA SecurID authentication may stop working."

  Solución alternativa: Antes de actualizar a vSphere 7.0, consulte el artículo de la base de conocimientos de VMware en https://kb.vmware.com/s/article/78057.

• Se produce un error de VMAFD al actualizar una implementación de vCenter Server con una instancia externa de Platform Services Controller de 6.7 U3 a 7.0

  Cuando se actualiza una implementación de vCenter Server mediante una instancia externa de Platform Services Controller, la instancia de Platform Services Controller converge en un dispositivo de vCenter Server Appliance. Si durante la actualización aparece el error install.vmafd.vmdir_vdcpromo_error_21, se produjo un error en el proceso de primer arranque de VMAFD. El proceso de primer arranque de VMAFD copia la instancia de VMware Directory Service Database (data.mdb) desde la instancia de origen de Platform Services Controller y el dispositivo de vCenter Server Appliance del socio de replicación.

  Solución alternativa: Deshabilite la descarga de segmentación de TCP (TCP Segmentation Offload, TSO) y la descarga de segmentación genérica (Generic Segmentation Offload, GSO) en el adaptador Ethernet de la instancia de origen de Platform Services Controller o el dispositivo de vCenter Server Appliance del socio de replicación antes de actualizar una implementación de vCenter Server con una instancia externa de Platform Services Controller. Consulte el artículo de la base de conocimientos: https://kb.vmware.com/s/article/74678

• Es posible que no se conserve la configuración de la tarjeta inteligente y RSA SecurID durante la actualización de vCenter Server

  La autenticación con RSA SecurID no funcionará después de actualizar a vCenter Server 7.0. Se mostrará un mensaje de error para notificar este problema cuando se intente iniciar sesión mediante RSA SecurID.

  Solución alternativa: Vuelva a configurar la tarjeta inteligente o RSA SecureID.

• Se produce un error en la migración de vCenter Server para Windows a vCenter Server Appliance 7.0 con un mensaje de error de red

  Se produce un error en la migración de vCenter Server para Windows a vCenter Server Appliance 7.0 y aparece el mensaje La IP ya existe en la red. Esto evita que el proceso de migración configure los parámetros de red en el nuevo dispositivo de vCenter Server Appliance. Para obtener más información, examine el archivo de registro: /var/log/vmware/upgrade/UpgradeRunner.log

  Solución alternativa:

  1. Compruebe que se hayan completado todas las actualizaciones de Windows en la instancia de origen de vCenter Server para Windows, o deshabilite las actualizaciones automáticas de Windows hasta que se complete la migración.
  2. Vuelva a intentar la migración de vCenter Server para Windows a vCenter Server Appliance 7.0.

   

• Cuando se configura el número de funciones virtuales para un dispositivo de SR-IOV mediante el parámetro de módulo max_vfs, es posible que no se apliquen los cambios

  En vSphere 7.0, es posible configurar el número de funciones virtuales para un dispositivo de SR-IOV mediante la API de administración de infraestructuras virtuales (Virtual Infrastructure Management, VIM), por ejemplo, a través de vSphere Client. La tarea no requiere el reinicio del host ESXi. Después de usar la configuración de la API de VIM, si se intenta configurar el número de funciones virtuales de SR-IOV mediante el parámetro de módulo max_vfs, es posible que no se apliquen los cambios debido a que la configuración de la API de VIM los reemplaza.

  Solución alternativa: Ninguna. Si desea configurar el número de funciones virtuales para un dispositivo de SR-IOV, utilice siempre el mismo método. Utilice la API de VIM o el parámetro de módulo max_vfs y reinicie el host ESXi.

• La instancia actualizada de vCenter Server Appliance no conserva todas las redes secundarias (NIC) de la instancia de origen

  Durante una actualización importante, si la instancia de origen de vCenter Server Appliance se configura con varias redes secundarias que no son NIC de VCHA, la instancia de destino de vCenter Server no conservará las redes secundarias que no sean NIC de VCHA. Si la instancia de origen se configura con varias NIC que forman parte de grupos de puertos DVS, no se conservará la configuración de las NIC durante la actualización. Se conservarán las configuraciones de las instancias de vCenter Server Appliance que forman parte del grupo de puertos estándar.

  Solución alternativa: Ninguna. Configure manualmente la red secundaria en la instancia de destino de vCenter Server Appliance.

• Después de actualizar o migrar una instancia de vCenter Server con una instancia externa de Platform Services Controller, los usuarios que se autentican con Active Directory pierden el acceso a la instancia de vCenter Server recientemente actualizada

  Después de actualizar o migrar una instancia de vCenter Server con una instancia externa de Platform Services Controller, si la instancia de vCenter Server recientemente actualizada no se une a un dominio de Active Directory, los usuarios que se autentiquen con Active Directory perderán el acceso a la instancia de vCenter Server.

  Solución alternativa: Compruebe que la nueva instancia de vCenter Server se unió a un dominio de Active Directory. Consulte el artículo de la base de conocimientos: https://kb.vmware.com/s/article/2118543

• Se produce un error al migrar una instancia de vCenter Server para Windows con una instancia externa de Platform Services Controller mediante una base de datos de Oracle

  Si existen cadenas que no son ASCII en la tabla de eventos y tareas de Oracle, se puede producir un error en la migración al exportar los datos de eventos y tareas. Se proporciona el siguiente mensaje de error: UnicodeDecodeError

  Solución alternativa: Ninguna.

• Tras actualizar un host ESXi, una comprobación de cumplimiento del perfil de host muestra el estado no conforme cuando se produce un error en las tareas de corrección del host

  El estado no conforme indica una incoherencia entre el perfil y el host.

  Esta incoherencia puede producirse debido a que ESXi 7.0 no permite reglas de notificación duplicadas, pero el perfil que usted utiliza las contiene. Por ejemplo, es posible que experimente problemas si intenta utilizar el perfil de host que extrajo del host antes de actualizar ESXi 6.5 o 6.7 a la versión 7.0, y dicho perfil de host contiene reglas de notificación que son duplicados de las reglas predeterminadas del sistema.

  Solución alternativa:

  1. Elimine del documento del perfil de host todas las reglas de notificación que sean duplicados de las reglas predeterminadas del sistema.
  2. Compruebe el estado de cumplimiento.
  3. Corrija el host.
  4. Si los pasos anteriores no resuelven el problema, reinicie el host.

   

• Aparece un mensaje de error en la interfaz de administración de vCenter Server

  Tras instalar vCenter Server 7.0 o realizar la actualización a esta versión, al desplazarse hasta el panel Actualizar en la interfaz de administración de vCenter Server, aparece el mensaje de error "Compruebe la URL e inténtelo de nuevo". El mensaje de error no le impide usar las funciones del panel Actualizar, y puede ver e instalar las actualizaciones disponibles, así como realizar copias intermedias de ellas.

  Solución alternativa: Ninguna.

Problemas con funciones 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.

• La máquina virtual cifrada no se enciende cuando el clúster de confianza habilitado para HA contiene un host no atestado

  En VMware® vSphere Trust Authority™, si se habilitó HA en el clúster de confianza y uno o varios hosts del clúster generan errores de atestación, no se puede encender una máquina virtual cifrada.

  Solución alternativa: Elimine del clúster de confianza todos los hosts en los que se produjo un error de atestación o corríjalos.

• La máquina virtual cifrada no se enciende cuando el clúster de confianza habilitado para DRS contiene un host no atestado

  En VMware® vSphere Trust Authority™, si se habilitó DRS en el clúster de confianza y uno o varios hosts del clúster generan errores de atestación, DRS podría intentar encender una máquina virtual cifrada en un host no atestado del clúster. Esta operación coloca la máquina virtual en un estado bloqueado.

  Solución alternativa: Elimine del clúster de confianza todos los hosts en los que se produjo un error de atestación o corríjalos.

• Se produce un error en la migración o la clonación de máquinas virtuales cifradas en todas las instancias de vCenter Server cuando se intenta hacerlo mediante vSphere Client

  Si se intenta migrar o clonar una máquina virtual cifrada en todas las instancias de vCenter Server mediante vSphere Client, se produce un error en la operación con el siguiente mensaje: "The operation is not allowed in the current state."

  Solución alternativa: Se deben usar las API de vSphere para migrar o clonar máquinas virtuales cifradas en las instancias de vCenter Server.

Problemas de redes

• Rendimiento reducido de redes en las NIC 82599/X540/X550 de Intel

  La nueva función de par de cola que se agrega al controlador ixgben para mejorar el rendimiento de las redes en las NIC serie 82599EB/X540/X550 de Intel puede reducir la capacidad de proceso con algunas cargas de trabajo en vSphere 7.0 en comparación con vSphere 6.7.

  Solución alternativa: Para lograr el mismo rendimiento de red que vSphere 6.7, puede deshabilitar el par de cola con un parámetro de módulo. Para deshabilitar el par de cola, ejecute el siguiente comando:

  # esxcli system module parameters set -p "QPair=0,0,0,0..." -m ixgben

  Después de ejecutar el comando, reinicie.

• Uno o más dispositivos de I/O no generan interrupciones cuando el IOMMU de AMD está en uso

  Si los dispositivos de I/O en el host ESXi ofrecen más de un total de 512 orígenes de interrupción diferentes, a algunos orígenes se les asigna de forma errónea un índice de entradas de tabla de reasignación de interrupción (IRTE) en la IOMMU de AMD que es mayor que el valor máximo. Se pierden las interrupciones de este tipo de origen, por lo que el dispositivo de I/O correspondiente se comporta como si se deshabilitan las interrupciones.

  Solución alternativa: Use el comando ESXCLI esxcli system settings kernel set -s iovDisableIR -v true para deshabilitar el reasignador de interrupciones de AMD IOMMU. Reinicie el host ESXi para que el comando tenga efecto.

• 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

• Las máquinas virtuales de alto rendimiento pueden experimentar un deterioro del rendimiento de red cuando se habilita Network I/O Control (NetIOC)

  Las máquinas virtuales que requieren un alto rendimiento de red pueden experimentar un deterioro del rendimiento al actualizar vSphere 6.7 a vSphere 7.0 con NetIOC habilitado.

  Solución alternativa: Configure el ajuste ethernetx.ctxPerDev para habilitar varios ámbitos.

• El tráfico IPv6 no puede pasar por los puertos de VMkernel mediante IPsec

  Cuando se migran puertos de VMkernel de un grupo de puertos a otro, el tráfico IPv6 no pasa a través de los puertos de VMkernel mediante IPsec.

  Solución alternativa: Elimine la asociación de seguridad (Security Association, SA) de IPsec del servidor afectado y, a continuación, vuelva a aplicar la SA. Para obtener información sobre cómo establecer y eliminar una asociación de seguridad de IPsec, consulte la documentación Seguridad de vSphere.

• Mayor rendimiento de red de ESX con un aumento en la porción de uso de CPU

  El rendimiento de red de ESX puede aumentar con una porción del uso de CPU.

  Solución alternativa: Elimine y agregue la interfaz de red con solo 1 cola de envío de rx. Por ejemplo:

  esxcli network ip interface remove --interface-name=vmk1

  esxcli network ip interface add --interface-name=vmk1 --num-rxqueue=1

• Es posible que la máquina virtual pierda tráfico Ethernet después de una operación de adición en caliente, eliminación en caliente o Storage vMotion

  Una máquina virtual puede dejar de recibir tráfico Ethernet después de una operación de adición en caliente, eliminación en caliente o Storage vMotion. Este problema afecta a las máquinas virtuales en las que el vínculo superior de la VNIC tiene SR-IOV habilitado. La NIC virtual de PVRDMA exhibe este problema cuando el vínculo superior de la red virtual es una NIC con capacidad RDMA de Mellanox y se configuran espacios de nombres de RDMA.

  Solución alternativa: Puede eliminar en caliente las NIC de Ethernet afectadas de la máquina virtual y agregarlas en caliente para restaurar el tráfico. En los sistemas operativos invitados Linux, el reinicio de la red también puede resolver el problema. Si estas soluciones alternativas no surten efecto, puede reiniciar la máquina virtual para restaurar la conectividad de red.

• El cambio de la dirección IP de una instancia de VCSA implementada con una dirección IP estática requiere que se creen los registros de DNS por adelantado

  Con la introducción de DDNS, la actualización de registros de DNS solo funciona para las instancias de VCSA implementadas con redes configuradas por DHCP. Al cambiar la dirección IP de vCenter Server a través de VAMI, se muestra el siguiente error:

  La dirección IP especificada no se resuelve en el nombre de host especificado.

  Solución alternativa: Existen dos soluciones alternativas posibles.

  1. Cree una entrada de DNS adicional con el mismo FQDN y la dirección IP deseada. Inicie sesión en VAMI y siga los pasos para cambiar la dirección IP.
  2. Inicie sesión en VCSA mediante SSH. Ejecute el siguiente script:

     ./opt/vmware/share/vami/vami_config_net

     Utilice la opción 6 para cambiar la dirección IP de eth0. Una vez cambiada la dirección, ejecute el siguiente script:

     ./opt/likewise/bin/lw-update-dns

     Reinicie todos los servicios de VCSA para actualizar la información de IP en el servidor DNS.

• La eliminación del grupo de puertos virtuales distribuidos de NSX (NSX Distributed Virtual Port Group, NSX DVPG) puede demorar varios segundos después de que se elimina el conmutador lógico correspondiente en NSX Manager.

  Si el número de conmutadores lógicos aumenta, es posible que la eliminación del NSX DVPG en vCenter Server demore más tiempo después de la eliminación del conmutador lógico correspondiente en NSX Manager. En un entorno con 12.000 conmutadores lógicos, se requieren aproximadamente 10 segundos para eliminar un DVPG NSX de vCenter Server.

  Solución alternativa: Ninguna.

• Si se crea una gran cantidad de grupos de puertos virtuales distribuidos de NSX, hostd se queda sin memoria y genera un error

  En vSphere 7.0, los grupos de puertos virtuales distribuidos de NSX consumen una cantidad de memoria significativamente mayor que las redes opacas. Por esta razón, los grupos de puertos virtuales distribuidos de NSX no pueden admitir la misma escala que una red opaca con la misma cantidad de memoria.

  Solución alternativa: Para admitir el uso de grupos de puertos virtuales distribuidos de NSX, aumente la cantidad de memoria en los hosts ESXi. Si comprueba que el sistema tiene suficiente memoria para admitir las máquinas virtuales, puede aumentar directamente la memoria de hostd mediante el siguiente comando.

  localcli --plugin-dir /usr/lib/vmware/esxcli/int/ sched group setmemconfig --group-path host/vim/vmvisor/hostd --units mb --min 2048 --max 2048

  Tenga en cuenta que esto hará que hostd use memoria que normalmente está reservada para las máquinas virtuales del entorno. Esto puede reducir el número de máquinas virtuales que el host ESXi puede admitir.

• DRS puede iniciar vMotion de forma incorrecta si la reserva de red está configurada en una máquina virtual

  Si la reserva de red está configurada en una máquina virtual, se espera que DRS solo migre la máquina virtual a un host que cumpla con los requisitos especificados. En un clúster con nodos de transporte de NSX, si algunos de los nodos de transporte se unen a la zona de transporte mediante NSX-T Virtual Distributed Switch (N-VDS) y otros mediante vSphere Distributed Switch (VDS) 7.0, DRS puede iniciar vMotion de forma incorrecta. Es posible que se produzca este problema cuando ocurre lo siguiente:

  • La máquina virtual se conecta a un conmutador lógico de NSX configurado con una reserva de red.
  • Algunos nodos de transporte se unen a la zona de transporte mediante N-VDS y otros mediante VDS 7.0, o bien los nodos de transporte se unen a la zona de transporte a través de diferentes instancias de VDS 7.0.

  Solución alternativa: Haga que todos los nodos de transporte se unan a la zona de transporte mediante N-VDS o la misma instancia de VDS 7.0.

• Al agregar una NIC de VMkernel (vmknic) a un grupo de puertos de NSX, vCenter Server muestra el error "Conectar el adaptador de VMKernel a un grupo de puertos de NSX en un host sin estado no es una operación admitida. En su lugar, utilice el grupo de puertos distribuidos".
  • Para una instancia de ESXi sin estado en un conmutador distribuido virtual (Distributed Virtual Switch, DVS), la vmknic en un grupo de puertos de NSX está bloqueada. En su lugar, debe utilizar un grupo de puertos distribuidos.
  • Para una instancia de ESXi con estado en un DVS, a pesar de que se admiten las vmknic en un grupo de puertos de NSX, vSAN puede presentar problemas si las emplea.

  Solución alternativa: Utilice un grupo de puertos distribuidos en el mismo DVS.

• Se puede producir un error al habilitar SR-IOV desde vCenter para QLogic 4x10GE QL41164HFCU CNA

  Si se desplaza hasta el cuadro de diálogo Editar configuración de los adaptadores de red física e intenta habilitar SR-IOV, puede que se produzca un error en la operación cuando se utilice QLogic 4x10GE QL41164HFCU CNA. Si se intenta habilitar SR-IOV, se puede producir una interrupción de la red del host ESXi.

  Solución alternativa: Utilice el siguiente comando en el host ESXi para habilitar SR-IOV:

  esxcfg-module

• Se produce un error en vCenter Server si los hosts de un clúster que utiliza Distributed Resource Scheduler (DRS) se unen a las redes de NSX-T mediante un conmutador virtual distribuido (Virtual Distributed Switch, VDS) diferente, o bien mediante una combinación de NSX-T Virtual Distributed Switch (NVDS) y el VDS

  En vSphere 7.0, cuando se utilizan redes de NSX-T en un VDS de vSphere con un clúster de DRS, se puede producir un error en vCenter Server si los hosts no se unen a la zona de transporte de NSX mediante las mismas instancias de VDS o NVDS.

  Solución alternativa: Haga que los hosts de un clúster de DRS se unan a la zona de transporte de NSX mediante las mismas instancias de VDS o NVDS. 

Problemas de almacenamiento

• Los almacenes de datos de VMFS no se montan automáticamente después de la eliminación en caliente y la inserción en caliente de un disco en servidores HPE Gen10 con controladoras SmartPQI

  En ocasiones, cuando se eliminan en caliente discos SATA en servidores HPE Gen10 con controladoras SmartPQI sin ampliadores y se insertan en caliente en una bahía de disco diferente del mismo equipo, o cuando se eliminan en caliente varios discos y se insertan en caliente en un orden diferente, se asigna un nuevo nombre local a los discos. El almacén de datos de VMFS en ese disco se muestra como una instantánea y no se vuelve a montar automáticamente debido a que el nombre del dispositivo se modificó.

  Solución alternativa: Ninguna. La controladora SmartPQI no admite operaciones desordenadas de eliminación en caliente e inserción en caliente.

• Es posible que ESXi finalice las operaciones de E/S en los dispositivos NVMeOF debido a errores en todas las rutas de acceso activas

  En ocasiones, todas las rutas de acceso activas a dispositivos NVMeOF registran errores de E/S debido a problemas de vínculo o al estado de las controladoras. Si el estado de una de las rutas de acceso cambia a inactivo, es posible que el complemento de alto rendimiento (High-Performance Plug-in, HPP) no seleccione otra ruta de acceso si esta muestra un gran volumen de errores. Como resultado, se produce un error en la operación de E/S.

  Solución alternativa: Deshabilite la opción de configuración /Misc/HppManageDegradedPaths para desbloquear las operaciones de E/S.

• Se produce un error en la comprobación de VOMA sobre los almacenes de datos VMFS basados en NVMe

  La comprobación de VOMA no es compatible con los almacenes de datos de VMFS basados en NVMe y generará el siguiente error:

  ERROR: Failed to reserve device. Function not implemented 

  Ejemplo:

  # voma -m vmfs -f check -d /vmfs/devices/disks/: <partition#>
  Running VMFS Checker version 2.1 in check mode
  Initializing LVM metadata, Basic Checks will be done
  
  Checking for filesystem activity
  Performing filesystem liveness check..|Scanning for VMFS-6 host activity (4096 bytes/HB, 1024 HBs).
  ERROR: Failed to reserve device. Function not implemented
  Aborting VMFS volume check
  VOMA failed to check device : General Error

  Solución alternativa: Ninguna. Si necesita analizar metadatos de VMFS, puede recopilarlos con la opción -l y recurrir al soporte al cliente de VMware. El comando para recopilar el volcado es el siguiente:

  voma -l -f dump -d /vmfs/devices/disks/:<partition#> 

• El uso de la API de reconfiguración de máquinas virtuales para asociar un disco de primera clase cifrado a una máquina virtual cifrada puede generar un error

  Si un FCD y una máquina virtual se cifran con diferentes claves de cifrado, los intentos por asociar el FCD cifrado a la máquina virtual cifrada mediante VM reconfigure API pueden generar un error y mostrar el siguiente mensaje:

  No se puede descifrar el disco porque la clave o la contraseña son incorrectas.

  Solución alternativa: Utilice attachDisk API en lugar de VM reconfigure API para asociar un FCD cifrado a una máquina virtual cifrada.

• El host ESXi puede obtener un estado sin respuesta si una extensión no principal de su almacén de datos de VMFS distribuido entra en el estado de pérdida de dispositivo permanente (Permanent Device Loss, PDL)

  Este problema no se presenta cuando una extensión no principal del almacén de datos de VMFS distribuido genera un error junto con la extensión principal. En este caso, no se puede acceder a ninguna porción del almacén de datos y ya no se permiten las operaciones de E/S.

  En cambio, cuando solo una extensión no principal genera un error, pero se sigue teniendo acceso a la extensión principal, el latido del almacén de datos parece normal, y las operaciones de E/S entre el host y el almacén de datos prosiguen. Sin embargo, también comienzan a generar errores las operaciones de E/S que dependen de la extensión no principal con el error. Es posible que se acumulen otras transacciones de E/S mientras se espera que se resuelva el error de E/S y que el host entre en un estado sin respuesta.

  Solución alternativa: Solucione la condición de PDL de la extensión no principal para resolver este problema.

• La controladora virtual NVMe es la controladora de disco predeterminada para los sistemas operativos invitados Windows 10

  La controladora virtual NVMe es la controladora de disco predeterminada para los siguientes sistemas operativos invitados cuando se utiliza la versión de hardware 15 o posterior:

  Windows 10
  Windows Server 2016
  Windows Server 2019

  Es posible que algunas funciones no estén disponibles cuando se utiliza una controladora virtual NVMe. Para obtener más información, consulte https://kb.vmware.com/s/article/2147714.

  Nota: Algunos clientes utilizan la opción predeterminada anterior de LSI Logic SAS. Esto incluye ESXi Host Client y PowerCLI.

  Solución alternativa: Si necesita funciones que no están disponibles en NVMe virtual, cambie a VMware Paravirtual SCSI (PVSCSI) o LSI Logic SAS. Para obtener información sobre el uso de VMware Paravirtual SCSI (PVSCSI), consulte https://kb.vmware.com/s/article/1010398.

• Después de la actualización de un host ESXi a vSphere 7.0, la presencia de reglas de notificación de núcleo duplicadas puede provocar un comportamiento inesperado

  Las reglas de notificación determinan qué complemento de múltiples rutas (como NMP, HPP, etc.) posee rutas de acceso a un dispositivo de almacenamiento en particular. ESXi 7.0 no admite reglas de notificación duplicadas. Sin embargo, el host ESXi 7.0 no muestra alertas si se agregan reglas duplicadas a las reglas de notificación existentes que se heredaron mediante una actualización a partir de una versión anterior. Como consecuencia del uso de reglas duplicadas, es posible que complementos no deseados recuperen dispositivo de almacenamiento, lo que puede provocar un resultado inesperado.

  Solución alternativa: No utilice reglas de notificación de núcleo duplicadas. Antes de agregar una nueva regla de notificación, elimine cualquier regla de notificación coincidente que exista.

• Una consulta de CNS con el filtro de estado de cumplimiento establecido puede demorar un tiempo inusualmente largo en completarse

  La API QueryVolume de CNS permite obtener información sobre los volúmenes de CNS, como el estado del volumen y el estado de cumplimiento. Al comprobar el estado de cumplimiento de volúmenes individuales, los resultados se obtienen rápidamente. Sin embargo, cuando se invoca la API QueryVolume de CNS para comprobar el estado de cumplimiento de varios volúmenes (varias decenas o cientos), la consulta puede procesarse lentamente.

  Solución alternativa: Evite usar consultas en masa. Cuando necesite obtener el estado de cumplimiento, consulte un volumen a la vez o limite la cantidad de volúmenes en la API de consulta a 20 o menos. Mientras realiza la consulta, evite ejecutar otras operaciones de CNS para obtener el mejor rendimiento.

• Un almacén de datos de VMFS respaldado por un espacio de nombres o dispositivo de NVMe por Fabrics, puede quedar inaccesible de forma permanente tras recuperarse de un error de APD o PDL

  Si un almacén de datos de VMFS en un host ESXi está respaldado por un espacio de nombres o un dispositivo de NVMe por Fabrics, en caso de que se produzca un error en todas las rutas de acceso (APD) o en un error de pérdida permanente de un dispositivo (PDL), es posible que no se pueda acceder al almacén de datos incluso después de la recuperación. No se puede acceder al almacén de datos desde el host ESXi o el sistema de vCenter Server.

  Solución alternativa: Para recuperarse de este estado, vuelva a realizar un examen en el nivel de host o de clúster. Para obtener más información, consulte Realizar un nuevo examen de almacenamiento.

• Los volúmenes de CNS eliminados se pueden mostrar como existentes de manera temporal en la interfaz de usuario de CNS

  Tras eliminar un disco de FCD que respalda un volumen de CNS, es posible que el volumen se siga mostrando como existente en la interfaz de usuario de CNS. Sin embargo, se produce un error si se intenta eliminar el volumen. Es posible que se muestre un mensaje de error similar al siguiente:
  No se pudieron encontrar el objeto o el artículo a los que se hace referencia.

  Solución alternativa: La siguiente sincronización completa resolverá la incoherencia y actualizará correctamente la interfaz de usuario de CNS.

• Puede que a veces se produzca un error al intentar asociar varios volúmenes de CNS al mismo pod

  Al asociar varios volúmenes al mismo pod de forma simultánea, en algunas ocasiones es posible que la operación de asociación elija la misma ranura de controladora. Por ello, solo una de las operaciones se realiza correctamente, mientras que se producen errores en otros montajes de volúmenes.

  Solución alternativa: Después de que Kubernetes reintente realizar la operación que generó errores, la operación se completa correctamente si hay una ranura de controladora disponible en la máquina virtual del nodo.

• En determinadas circunstancias, a pesar de que se produce un error en una operación de CNS, el estado de la tarea se muestra como correcto en vSphere Client

  Esto puede ocurrir cuando, por ejemplo, se utiliza una directiva de almacenamiento que no cumple los requisitos para crear un volumen de CNS. Se produce un error en la operación, pero vSphere Client muestra el estado de la tarea como correcto.

  Solución alternativa: Aunque el estado de la tarea aparezca como correcto en vSphere Client, no hay ninguna garantía de que la operación de CNS se haya realizado correctamente. Para asegurarse de que la operación se realizó correctamente, compruebe los resultados.

• Una operación de eliminación incorrecta para un volumen persistente de CNS puede dejar sin eliminar el volumen en el almacén de datos de vSphere

  Este problema puede producirse cuando la API de eliminación de CNS intenta eliminar un volumen persistente que aún está asociado a un pod. Por ejemplo, cuando se elimina el espacio de nombres de Kubernetes donde se ejecuta el pod. Como resultado, el volumen se borra de CNS y la operación de consulta de CNS no devuelve el volumen. Sin embargo, el volumen continuará residiendo en el almacén de datos y no podrá eliminarse a través de sucesivas operaciones de la API de eliminación de CNS.

  Solución alternativa: Ninguna.

Problemas en vCenter Server y vSphere Client

• Los proveedores se desconectan después de un cambio de PNID

  Cuando se cambia la dirección IP de vCenter (cambio de PNID), los proveedores registrados se desconectan.

  Solución alternativa: Vuelva a registrar los proveedores.

• Se produce un error en la migración de una máquina virtual entre instancias de vCenter

  Cuando se usa vMotion entre instancias de vCenter para mover el almacenamiento y el host de una máquina virtual a otra instancia de vCenter Server, es posible que se muestre el error La operación no se permite en el estado actual. 

  Este error aparece en el asistente de la interfaz de usuario después del paso de selección del host y antes del paso de selección del almacén de datos, en casos en los que la máquina virtual tiene una directiva de almacenamiento asignada con reglas basadas en host, como el cifrado u otra regla de filtro de E/S.

  Solución alternativa: Asigne la máquina virtual y sus discos a una directiva de almacenamiento sin reglas basadas en host. Es posible que deba descifrar la máquina virtual si la máquina virtual de origen está cifrada. A continuación, vuelva a intentar la acción de vMotion entre instancias de vCenter.

• La información sobre sensores de almacenamiento de la pestaña Estado del hardware muestra valores incorrectos en la interfaz de usuario de vCenter, la interfaz de usuario del host y el explorador MOB

  Al desplazarse hasta Host > Supervisar > Estado del hardware > Sensores de almacenamiento en la interfaz de usuario de vCenter, la información de almacenamiento muestra valores incorrectos o desconocidos. Se observa el mismo problema en la interfaz de usuario del host y la ruta de acceso de MOB “runtime.hardwareStatusInfo.storageStatusInfo”.

  Solución alternativa: Ninguna.

• La configuración avanzada de hosts de la interfaz de usuario de vSphere muestra la ubicación actual del bloqueador de productos como vacía con un valor predeterminado vacío

  La configuración avanzada de hosts de la interfaz de usuario de vSphere muestra la ubicación actual del bloqueador de productos como vacía con un valor predeterminado vacío. Esto no es coherente, ya que la ubicación real del producto symlink se creó y es válida. Esto provoca confusión en el usuario. El valor predeterminado no se puede corregir desde la interfaz de usuario.

  Solución alternativa: El usuario puede utilizar el comando esxcli en el host para corregir la ubicación actual del bloqueador de productos predeterminada como se indica a continuación.

  1. Elimine la configuración existente de ubicación del bloqueador de productos con: "esxcli system settings advanced remove -o ProductLockerLocation"

  2. Vuelva a agregar la configuración de ubicación del bloqueador de productos con el valor predeterminado apropiado:

        2.a.  Si ESXi es una instalación completa, el valor predeterminado es "/locker/packages/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/locker/packages/vmtoolsRepo"

        2.b. Si ESXi es una configuración de PXEboot, por ejemplo, autodeploy, el valor predeterminado es el siguiente: "/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/vmtoolsRepo"

        Ejecute el siguiente comando para determinar automáticamente la ubicación: export PRODUCT_LOCKER_DEFAULT=`readlink /productLocker`

        Agregue la configuración: esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s $PRODUCT_LOCKER_DEFAULT

  Para combinar todos los pasos anteriores en el paso 2, puede emitir el siguiente comando único:

  esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s `readlink /productLocker`

• Las instancias vinculadas de vCenter Server del centro de datos definido por software (Software-Defined Data Center, SDDC) aparecen en la instancia local de vSphere Client si una puerta de enlace de vCenter Cloud está vinculada al SDDC.

  Cuando se implementa una puerta de enlace de vCenter Cloud en el mismo entorno que una instancia local de vCenter Server y se la vincula a un SDDC, la instancia de vCenter Server del SDDC aparecerá en la instancia local de vSphere Client. Este es un comportamiento inesperado y la instancia vinculada de vCenter Server del SDDC debe ignorarse. Todas las operaciones que involucren a la instancia vinculada de vCenter Server del SDDC deben realizarse en la instancia de vSphere Client en ejecución dentro de la puerta de enlace de vCenter Cloud.

  Solución alternativa: Ninguna.

Problemas en la administración de máquinas virtuales

• Las máquinas virtuales con virtualización cifrada segura de AMD: estado cifrado (SEV-ES) habilitado no pueden crear conectores de la interfaz de comunicación de máquinas virtuales (VMCI)

  El rendimiento y la funcionalidad de las funciones que requiere VMCI pueden verse afectados en las máquinas virtuales con AMD SEV-ES habilitado, ya que tales máquinas virtuales no pueden crear sockets VMCI.

  Solución alternativa: Ninguna.

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

• La sección postcustomization del script de personalización se ejecuta antes que la personalización de invitado

  Cuando se ejecuta el script de personalización de invitado para un sistema operativo invitado Linux, la sección precustomization del script de personalización que se define en la especificación de personalización se ejecuta antes que la personalización de invitado y, a continuación, se ejecuta la sección postcustomization. Si se habilita Cloud-Init en el sistema operativo invitado de una máquina virtual, la sección postcustomization se ejecuta antes que la personalización debido a un problema conocido de Cloud-Init.

  Solución alternativa: Deshabilite Cloud-Init y utilice la personalización de invitado estándar. 

• Las operaciones de migración de grupos en vSphere vMotion, Storage vMotion y vMotion sin almacenamiento compartido generan un error

  Cuando se realizan operaciones de migración de grupos en máquinas virtuales con varios discos e instantáneas de múltiples niveles, se puede producir el siguiente error en las operaciones: com.vmware.vc.GenericVmConfigFault Se produjo un error durante la espera de datos. Error 195887167. El host remoto cerró la conexión, posiblemente debido a que se agotó el tiempo de espera.

  Solución alternativa: Vuelva a intentar la operación de migración de a una máquina virtual con errores a la vez.

• La implementación de una plantilla de OVF o de OVA desde una URL genera un error 403 Forbidden

  No se admiten las URL que contienen un parámetro de consulta HTTP. Por ejemplo, http://webaddress.com?file=abc.ovf o las direcciones URL S3 previamente firmadas por Amazon.

  Solución alternativa: Descargue los archivos e impleméntelos desde el sistema de archivos local.

• No puede verse el tercer nivel de objetos anidados en una carpeta de máquina virtual

  Realice los pasos siguientes:

  1. Desplácese hasta un centro de datos y cree una carpeta de máquina virtual.
  2. En la carpeta de la máquina virtual, cree una carpeta de máquina virtual anidada.
  3. En la segunda carpeta, cree una máquina virtual, una carpeta de máquina virtual, una vApp o una plantilla de máquina virtual anidadas adicionales.

  Como resultado, no se pueden ver los objetos de la tercera carpeta anidada en el árbol de inventario de Máquinas virtuales y plantillas.

  Solución alternativa: Para ver los objetos de la tercera carpeta anidada, desplácese hasta la segunda carpeta anidada y seleccione la pestaña Máquinas virtuales.

Problemas con vSphere HA y Fault Tolerance

• Las máquinas virtuales de un clúster pueden quedar huérfanas después de recuperarse de una inaccesibilidad de almacenamiento, como una condición APD en todo el clúster

  Es posible que algunas máquinas virtuales queden en un estado huérfano después de recuperarse de una condición APD en todo el clúster, incluso si se habilitaron HA y VMCP en el clúster.

  Este problema puede ocurrir cuando se presentan las siguientes condiciones de forma simultánea:

  • Todos los hosts del clúster experimentan APD y no se recuperan hasta que se agota el tiempo de espera de VMCP.
  • El principal de HA inicia la conmutación por error debido a una condición APD en un host.
  • Se produce un error en la API de encendido durante la conmutación por error de HA debido a una de las siguientes condiciones:
    • APD en el mismo host
    • APD en cascada en todo el clúster
    • Problemas de almacenamiento
    • Recursos no disponibles
  • Es posible que se inicie la cancelación del registro de FDM y la lógica de robo de máquina virtual de VC durante un período en el que FDM no canceló el registro de la máquina virtual con errores y la sincronización de hosts de VC responde que varios hosts informan la misma máquina virtual. Tanto FDM como VC eliminan del registro las diferentes copias registradas de la misma máquina virtual desde diferentes hosts, lo que provoca que la máquina virtual quede huérfana.

   

  Solución alternativa: Debe eliminar del registro a las máquinas virtuales huérfanas y volver a registrarlas manualmente en el clúster después de que se recupere la condición de APD.

  Si no se vuelven a registrar manualmente las máquinas virtuales huérfanas, HA intenta la conmutación por error de estas máquinas virtuales, pero esto puede tardar entre 5 y 10 horas, según el momento en que se recupere la condición de APD.

  En estos casos, la funcionalidad general del clúster no se ve afectada, y HA continúa protegiendo las máquinas virtuales. Se trata de una anomalía en cuanto a lo que se muestra en VC durante el transcurso del problema.

Problemas en vSphere Lifecycle Manager

• No se puede habilitar NSX-T en un clúster que ya está habilitado para administrar la configuración y la actualización de imágenes en todos los hosts de forma colectiva

  NSX-T no es compatible con la funcionalidad de administración de imágenes de vSphere Lifecycle Manager. Cuando se habilita un clúster para la configuración y la actualización de imágenes en todos los hosts del clúster de forma colectiva, no se puede habilitar NSX-T en ese clúster. Sin embargo, es posible implementar instancias de NSX Edge en este clúster.

  Solución alternativa: Mueva los hosts a un nuevo clúster que pueda administrar con líneas base y habilite NSX-T en ese nuevo clúster.

• vSphere Lifecycle Manager y los servicios de archivos de vSAN no pueden habilitarse al mismo tiempo en un clúster de vSAN de vSphere 7.0

  Si se habilita vSphere Lifecycle Manager en un clúster, no se pueden habilitar los servicios de archivos de vSAN en el mismo clúster y viceversa. Para habilitar vSphere Lifecycle Manager en un clúster en el que ya estén habilitados los servicios de archivos de vSAN, primero deshabilite los servicios de archivos de vSAN y vuelva a intentar la operación. Tenga en cuenta que si realiza una transición a un clúster que se administra con una sola imagen, vSphere Lifecycle Manager no se puede deshabilitar en dicho clúster.

  Solución alternativa: Ninguna.

• Cuando un administrador de soporte de hardware no está disponible, se ve afectada la funcionalidad de vSphere High Availability (HA)

  La funcionalidad de vSphere HA se ve afectada si un administrador de soporte de hardware no está disponible para un clúster que se administra con una sola imagen en el que se habilita vSphere HA y en el que se selecciona un complemento de firmware y controladores. Es posible que se produzcan los siguientes errores.

  • Se produce un error al configurar vSphere HA en un clúster.
  • No se puede completar la configuración del agente de vSphere HA en un host: Se produjo un error al aplicar los VIB de HA en el clúster.
  • Se produce un error al corregir vSphere HA: Error general del sistema: No se pudo obtener el mapa de componentes efectivos.
  • Se produce un error al deshabilitar vSphere HA: Se produjo un error en la tarea de eliminación de soluciones. Error general del sistema: No se puede encontrar el paquete de soporte de hardware del depósito o el administrador de soporte de hardware.

   

  Solución alternativa:

  • Si el administrador de soporte de hardware no está disponible de forma temporal, realice los siguientes pasos.
  1. Vuelva a conectar el administrador de soporte de hardware a vCenter Server.
  2. Seleccione un clúster en el menú Hosts y clústeres.
  3. Seleccione la pestaña Configurar.
  4. En Servicios, haga clic en vSphere Availability.
  5. Vuelva a habilitar vSphere HA.
  • Si el administrador de soporte de hardware no está disponible de forma permanente, realice los siguientes pasos.
  1. Elimine el administrador de soporte de hardware y el paquete de soporte de hardware de la especificación de imagen.
  2. Vuelva a habilitar vSphere HA.
  3. Seleccione un clúster en el menú Hosts y clústeres.
  4. Seleccione la pestaña Actualizaciones.
  5. Haga clic en Editar.
  6. Elimine el complemento de firmware y controlador, y haga clic en Guardar.
  7. Seleccione la pestaña Configurar.
  8. En Servicios, haga clic en vSphere Availability.
  9. Vuelva a habilitar vSphere HA.

   

• No se elimina el elemento iofilter de un clúster después de un proceso de corrección en vSphere Lifecycle Manager

  Se produce un error al eliminar el elemento filtro de E/S de un clúster mediante la corrección del clúster en vSphere Lifecycle Manager, y se muestra el siguiente mensaje: El filtro de E/S XXX ya existe. El elemento filtro de E/S permanece en la lista como instalado.

  Solución alternativa:

  1. Llame a la API del filtro de E/S UninstallIoFilter_Task desde el objeto administrado de vCenter Server (IoFilterManager).
  2. Corrija el clúster en vSphere Lifecycle Manager.
  3. Llame a la API del filtro de E/S ResolveInstallationErrorsOnCluster_Task desde el objeto administrado de vCenter Server (IoFilterManager) para actualizar la base de datos.

   

• Durante la corrección de un clúster habilitado para vSphere HA en vSphere Lifecycle Manager, la adición de hosts genera un estado de error en vSphere HA

  Si se agregan uno o varios hosts ESXi durante el proceso de corrección de un clúster habilitado para vSphere HA, se genera el siguiente mensaje de error: Se produjo un error al aplicar los VIB de HA en el clúster.

  Solución alternativa: Una vez completada la operación de corrección del clúster, realice una de las siguientes tareas.

  • Haga clic con el botón derecho en el host de ESXi con errores y seleccione Volver a configurar para vSphere HA.
  • Deshabilite y vuelva a habilitar vSphere HA para el clúster.

   

• Durante la corrección de un clúster habilitado para vSphere HA en vSphere Lifecycle Manager, si se deshabilita y se vuelve a habilitar vSphere HA, se genera un estado de error en vSphere HA

  Al deshabilitar y volver a habilitar vSphere HA durante la corrección de un clúster, es posible que se produzca un error en el proceso de corrección debido a que las comprobaciones de estado de vSphere HA indican que los hosts no tienen paquetes VIB de vSphere HA instalados. Es posible que se muestre el siguiente mensaje de error: Error al establecer la especificación de imagen deseada para el clúster.

  Solución alternativa: Una vez completada la operación de corrección del clúster, deshabilite y vuelva a habilitar vSphere HA para el clúster.

• La búsqueda de imágenes recomendadas en vSphere Lifecycle Manager es lenta en los clústeres de gran tamaño

  En los clústeres grandes con más de 16 hosts, la tarea de generación de recomendaciones puede tardar más de una hora en completarse o puede parecer que se bloquea. El tiempo de finalización de la tarea de recomendación depende de la cantidad de dispositivos configurados en cada host y de la cantidad de candidatos de imagen del almacén que vSphere Lifecycle Manager debe procesar antes de obtener una imagen válida para recomendar.

  Solución alternativa: Ninguna.

• La comprobación de la compatibilidad de hardware en vSphere Lifecycle Manager es lenta en los clústeres de gran tamaño

  En los clústeres grandes con más de 16 hosts, la tarea de generación de informes de validación puede tardar hasta 30 minutos en completarse o puede parecer que se bloquea. El tiempo de finalización depende de la cantidad de dispositivos configurados en cada host y de la cantidad de hosts configurados en el clúster.

  Solución alternativa: Ninguna

• Se muestran mensajes de error incompletos en idiomas distintos del inglés al corregir un clúster en vSphere Lifecycle Manager

  Es posible encontrar mensajes de error incompletos para los idiomas localizados en la interfaz de usuario de vCenter Server. Estos mensajes se muestran después de que se produce un error en el proceso de corrección de un clúster en vSphere Lifecycle Manager. Por ejemplo, se puede observar el siguiente mensaje de error.
  
  El mensaje de error en inglés: Virtual machine 'VMC on DELL EMC -FileServer' that runs on cluster 'Cluster-1' reported an issue which prevents entering maintenance mode: Unable to access the virtual machine configuration: Unable to access file[local-0] VMC on Dell EMC - FileServer/VMC on Dell EMC - FileServer.vmx
  
  El mensaje de error en francés: La VM « VMC on DELL EMC -FileServer », située sur le cluster « {Cluster-1} », a signalé un problème empêchant le passage en mode de maintenance : Unable to access the virtual machine configuration: Unable to access file[local-0] VMC on Dell EMC - FileServer/VMC on Dell EMC - FileServer.vmx

  Solución alternativa: Ninguna.

• Al importar una imagen sin complemento de proveedor, componentes ni complemento de firmware y controlador a un clúster con una imagen que contiene esos elementos, no se eliminan los elementos de imagen de la imagen existente

  Solo la imagen base de ESXi se reemplaza por la que se encuentra en la imagen importada.

  Solución alternativa: Una vez completado el proceso de importación, edite la imagen y, si es necesario, elimine el complemento de proveedor, los componentes, y el complemento de firmware y controlador.

• Cuando se convierte un clúster que utiliza líneas base en un clúster que utiliza una sola imagen, se muestra una advertencia que indica que se eliminarán los VIB de vSphere HA

  Al convertir un clúster habilitado para vSphere HA que utiliza líneas base en un clúster que utiliza una sola imagen, se puede mostrar un mensaje de advertencia en el que se indica que se eliminará el componente vmware-fdm.

  Solución alternativa: Este mensaje se puede ignorar. El proceso de conversión instala el componente vmware-fdm.

• Si se configuró vSphere Update Manager para descargar actualizaciones de revisión de Internet a través de un servidor proxy, después de una actualización a vSphere 7.0 donde Update Manager se convierte en vSphere Lifecycle Manager, es posible que se produzca un error al descargar revisiones del repositorio de revisiones de VMware

  En las versiones anteriores de vCenter Server, se podían configurar ajustes de proxy independientes para vCenter Server y vSphere Update Manager. Después de una actualización a vSphere 7.0, el servicio vSphere Update Manager se convierte en parte del servicio Lifecycle Manager vSphere. En el servicio vSphere Lifecycle Manager, los ajustes de proxy se configuran en la configuración de vCenter Server Appliance. Si se configuró Update Manager para descargar actualizaciones de revisión de Internet a través de un servidor proxy, pero el dispositivo de vCenter Server Appliance no incluye ajustes de proxy, después de una actualización de vCenter Server a la versión 7.0, el servicio vSphere Lifecycle Manager no se puede conectar al almacén de VMware y no puede descargar revisiones ni actualizaciones.

  Solución alternativa: Inicie sesión en la interfaz de administración de vCenter Server Appliance (https://dirección-IP-o-FQDN-de-vCenter-Server-Appliance:5480) para configurar los ajustes de proxy de vCenter Server Appliance y habilitar vSphere Lifecycle Manager para utilizar el proxy.

Problemas varios

• Cuando se aplica un perfil de host con la versión 6.5 a un host ESXi con la versión 7.0, se produce un error en la comprobación de cumplimiento

  Al aplicar un perfil de host con la versión 6.5 a un host ESXi con la versión 7.0, se informa que el perfil de archivo de volcado de núcleo no cumple con las normas del host.

  Solución alternativa: Existen dos soluciones alternativas posibles.

  1. Al crear un perfil de host con la versión 6.5, establezca la opción de configuración avanzada VMkernel.Boot.autoCreateDumpFile en false en el host ESXi.
  2. Al aplicar un perfil de host existente con la versión 6.5, agregue la opción de configuración avanzada VMkernel.Boot.autoCreateDumpFile al perfil de host, configure la opción en una directiva fija y establezca el valor en false.

   

• Los controladores de ESXi nativos Mellanox ConnectX-4 o ConnectX-5 pueden mostrar un deterioro menor del rendimiento cuando se activa la función de ajuste de escala en lado de recepción (Dynamic Receive Side Scaling, DYN_RSS) o la función de ajuste de escala en lado de recepción genérico (Generic Receive Side Scaling, GEN_RSS)

  Los controladores de ESXi nativos Mellanox ConnectX-4 o ConnectX-5 pueden mostrar un deterioro de menos del 5 % en el rendimiento cuando se activan las funciones DYN_RSS y GEN_RSS, pero es improbable que esto afecte a las cargas de trabajo normales.

  Solución alternativa: Puede deshabilitar las funciones DYN_RSS y GEN_RSS con los siguientes comandos:

  # esxcli system module parameters set -m nmlx5_core -p "DYN_RSS=0 GEN_RSS=0"

  # reboot

• Se puede producir un error en el tráfico de RDMA entre dos máquinas virtuales en el mismo host en el entorno de PVRDMA

  En una implementación de vSphere 7.0 en un entorno de PVRDMA, las máquinas virtuales pasan el tráfico a través de HCA para la comunicación local si existe un HCA. Sin embargo, el bucle invertido del tráfico de RDMA no funciona en el controlador qedrntv.  Por ejemplo, los pares de cola de RDMA que se ejecutan en máquinas virtuales configuradas en el mismo puerto de vínculo superior no pueden comunicarse unos con otros.

  En vSphere 6.7 y las versiones anteriores, se usaba un HCA para el tráfico de RDMA local si SRQ se encontraba habilitado. vSphere 7.0 utiliza el bucle invertido de HCA con las máquinas virtuales que utilizan versiones de PVRDMA con SRQ habilitado y una versión de hardware mínima de 14 mediante RoCE v2.

  La versión de firmware actual del adaptador de Marvell FastLinQ no admite el tráfico de bucle invertido entre QP de un mismo puerto o PF.

  Solución alternativa: Se está agregando la compatibilidad requerida al controlador no incluido certificado para vSphere 7.0. Si utiliza el controlador qedrntv incluido, debe usar una configuración de 3 hosts y migrar las máquinas virtuales al tercer host.

• Limitaciones de QP para el tráfico de datagramas no confiables en el controlador qedrntv

  Existen limitaciones en el controlador RoCE qedrntv de Marvell FastLinQ y el tráfico de datagramas no confiables (Unreliable Datagram, UD). Es posible que se produzcan errores en las aplicaciones de UD con tráfico en masa a través del controlador qedrntv. Por otra parte, los QP de UD solo pueden funcionar con las regiones de memoria (Memory Regions, MR) de DMA. No se admiten MR o FRMR físicas. Las aplicaciones que intentan utilizar MR o FRMR físicas junto con QP de UD no pueden pasar el tráfico a través de un controlador qedrntv. Los ejemplos conocidos de estas aplicaciones de prueba son ibv_ud_pingpong y ib_send_bw.

  Los casos prácticos de RoCE y RoCEv2 estándar en un entorno de VMware ESXi, como iSER, NVMe-oF (RoCE) y PVRDMA, no se ven afectados por este problema. Los casos prácticos de tráfico de UD son limitados y este problema afecta a un pequeño conjunto de aplicaciones que requieren tráfico de UD en masa.

  El hardware de Marvell FastLinQ no admite la descarga de tráfico de UD de RDMA. Para cumplir con el requisito de PVRDMA de VMware y admitir QP de GSI, se agregó al controlador qedrntv una implementación exclusiva de software restringido para admitir QP de UD. El objetivo de la implementación es proporcionar compatibilidad con la comunicación GSI de rutas de control; no es una implementación completa de QP de UD para admitir el tráfico en masa y las funciones avanzadas.

  Como la compatibilidad con UD se encuentra implementada en el software, es posible que la implementación no aguante un tráfico intenso y se descarten paquetes. Esto puede provocar errores en el tráfico de UD en masa.

  Solución alternativa: No se admite el tráfico de QP de UD en masa con el controlador qedrntv y no existe ninguna solución alternativa en este momento. Los casos prácticos de RDMA de VMware ESXi (RoCE), como iSER, NVMe, RDMA y PVRDMA, no se ven afectados por este problema.

• Es posible que se produzcan errores en los servidores equipados con NIC 578xx de QLogic al conectar o desconectar LUN de iSCSI con frecuencia

  Si se activa la conexión o la desconexión iSCSI de una NIC 578xx de QLogic con frecuencia, se puede producir un error en el servidor debido a un problema con el controlador qfle3. Esto se debe a un defecto conocido en el firmware del dispositivo.

  Solución alternativa: Ninguna.

• Es posible que se produzca un error en ESXi durante la operación de descarga del controlador o desconexión de la controladora en el entorno NVMe over FC de Broadcom

  En el entorno NVMe over FC de Broadcom, se puede producir un error en ESXi durante la operación de descarga del controlador o de desconexión de la controladora, y se puede mostrar un mensaje como el siguiente: @BlueScreen: #PF Exception 14 in world 2098707:vmknvmeGener IP 0x4200225021cc addr 0x19

  Solución alternativa: Ninguna.

• ESXi no muestra el número de versión de firmware de OEM de las NIC i350/X550 en algunos servidores Dell

  El controlador ixgben incluido solo reconoce la firma o la versión de los datos de firmware de las NIC i350/X550. En algunos servidores Dell, el número de versión de firmware de OEM se encuentra programado en la región de versión del paquete OEM y el controlador ixgben incluido no lee esta información. Solo se muestra la firma de firmware de 8 dígitos.

  Solución alternativa: Para mostrar el número de versión de firmware de OEM, instale la versión 1.7.15 o posterior del controlador ixgben asíncrono.

• Es posible que las NIC X710 o XL710 generen errores en ESXi

  Cuando se inician ciertas operaciones destructivas en las NIC X710 o XL710, como restablecer la NIC o manipular el árbol de dispositivos internos de VMKernel, el hardware de la NIC puede leer datos de una memoria no empaquetada.

  Solución alternativa: No restablezca la NIC ni manipule el estado del dispositivo interno de VMkernel.

• NVMe-oF no garantiza un nombre de VMHBA persistente después del reinicio del sistema

  NVMe-oF es una función nueva en vSphere 7.0. Si el servidor tiene una instalación de almacenamiento USB que utiliza vmhba30+ y también tiene una configuración de NVMe over RDMA, el nombre de VMHBA puede cambiar después de reiniciar el sistema. Esto se debe a que la asignación de nombres de VMHBA para NVMe over RDMA es diferente de los dispositivos PCIe. ESXi no garantiza la persistencia.

  Solución alternativa: Ninguna.

• Se produce un error en la copia de seguridad si el tamaño de la base de datos de vCenter es 300 GB o superior

  Si el tamaño de la base de datos de vCenter es 300 GB o superior, la copia de seguridad basada en archivos generará un error de tiempo de espera. Aparece el siguiente mensaje de error: Timeout! Failed to complete in 72000 seconds

  Solución alternativa: Ninguna.

• Se puede producir un error al restaurar una instancia de vCenter Server 7.0 obtenida tras actualizar vCenter Server 6.x con una instancia externa de Platform Services Controller

  Cuando se restaura una instancia de vCenter Server 7.0 obtenida tras actualizar la versión 6.x con una instancia externa de Platform Services Controller, es posible que se produzca un error en la restauración y se muestre el siguiente mensaje: Failed to retrieve appliance storage list

  Solución alternativa: Durante la primera etapa del proceso de restauración, aumente el nivel de almacenamiento de vCenter Server 7.0. Por ejemplo, si el tipo de almacenamiento en la configuración de la instancia externa de Platform Services Controller de vCenter Server 6.7 es pequeño, seleccione el tipo de almacenamiento grande para el proceso de restauración.

• El parámetro de configuración Enabled SSL protocols no se define durante el proceso de corrección de un perfil de host

  El parámetro de configuración Enabled SSL protocols no se define durante la corrección de un perfil de host y solo se habilita el protocolo predeterminado del sistema tlsv1.2. Este comportamiento se observa en un perfil de host con la versión 7.0 y anteriores en un entorno de vCenter Server 7.0.

  Solución alternativa: Si desea habilitar los protocolos SSL TLSV 1.0 o TLSV 1.1 para SFCB, inicie sesión en un host ESXi mediante SSH y ejecute el siguiente comando de ESXCLI: esxcli system wbem -P <nombre_protocolo>

• No se pueden configurar los ajustes de Modo de bloqueo mediante perfiles de host

  El modo de bloqueo no se puede configurar a través de un perfil de host de seguridad y no se puede aplicar a varios hosts ESXi a la vez. Es necesario configurar manualmente cada host.  

  Solución alternativa: En vCenter Server 7.0, puede configurar el modo de bloqueo y administrar la lista de usuarios con excepción de modo de bloqueo mediante el uso de un perfil de host de seguridad.

• Cuando se aplica un perfil de host a un clúster, no se encuentra la configuración de Enhanced vMotion Compatibility (EVC) en los hosts ESXi

  Algunos ajustes del archivo de configuración /etc/vmware/config de VMware no se administran mediante perfiles de host y se bloquean cuando se modifica el archivo de configuración. Como resultado, cuando se aplica el perfil de host a un clúster, se pierde la configuración de EVC, lo que provoca la pérdida de funcionalidades de EVC. Por ejemplo, las CPU sin enmascarar pueden quedar expuestas a cargas de trabajo.

  Solución alternativa: Vuelva a configurar la línea base de EVC relevante en el clúster para recuperar la configuración de EVC.

• El uso de un perfil de host para definir una partición de volcado de núcleo en vCenter Server 7.0 genera un error

  En vCenter Server 7.0, la configuración y la administración de una partición de volcado de núcleo en un perfil de host no se encuentra disponible. Al intentar aplicar un perfil de host para definir una partición de volcado de núcleo, se produce el siguiente error: No se encontró una partición de volcado de núcleo válida.

  Solución alternativa: Ninguna. En vCenter Server 7.0, los perfiles de host solo admiten volcados de núcleo basados en archivos.

• Si ejecuta el comando ESXCLI para descargar el módulo de firewall, se produce un error en el servicio hostd y los hosts de ESXi pierden conectividad

  Si automatiza la configuración del firewall en un entorno que incluya varios hosts ESXi y ejecuta el comando de ESXCLI esxcli network firewall unload que destruye los filtros y descarga el módulo de firewall, se produce un error en el servicio hostd y los hosts ESXi pierden conectividad.

  Solución alternativa: No se recomienda descargar el módulo de firewall en ningún momento. Si debe descargar el módulo de firewall, siga los siguientes pasos:

  1. Detenga el servicio hostd con este comando:
     /etc/init.d/hostd stop.
  2. Descargue el módulo de firewall con este comando:
     esxcli network firewall unload.
  3. Realice las operaciones necesarias.
  4. Cargue el módulo de firewall con este comando:
     esxcli network firewall load.
  5. Inicie el servicio hostd con este comando:
     /etc/init.d/hostd start.
• Es posible que se produzcan errores en las operaciones de vSphere Storage vMotion en un entorno de vSAN debido a una sesión sin autenticar del administrador de copia de archivos de red (NFC)

  Es posible que se produzcan errores en las migraciones a un almacén de datos de vSAN mediante vSphere Storage vMotion de máquinas virtuales que tengan al menos una instantánea y más de un disco virtual con una directiva de almacenamiento diferente. El problema se produce debido a una sesión sin autenticar del administrador de NFC porque el cuerpo del Protocolo simple de acceso a objeto (SOAP) supera el tamaño permitido.

  Solución alternativa: Primero, migre el espacio de nombres del directorio principal de la máquina virtual y solo uno de los discos virtuales. Una vez que se complete la operación, realice una migración solo de disco de los dos discos restantes. 

• Es posible que los cambios en las propiedades y los atributos de los dispositivos y el almacenamiento de un host ESXi no persistan después de un reinicio

  Si se agota el tiempo de espera de la rutina de detección de dispositivos durante un reinicio del host ESXi, es posible que el complemento de activación no reciba todos los cambios de configuración de los dispositivos y el almacenamiento de todos los dispositivos registrados en el host. Como resultado, es posible que después del reinicio, el proceso restaure las propiedades de algunos dispositivos o almacenamiento a los valores predeterminados.

  Solución alternativa: Restaure manualmente los cambios en las propiedades del dispositivo o almacenamiento afectados.

• Si utiliza una compilación beta de ESXi 7.0, se puede producir un error en los hosts de ESXi con una pantalla de diagnóstico de color morado durante algunas operaciones de ciclo de vida

  Si utiliza una compilación beta de ESXi 7,0, se puede producir un error en los hosts de ESXi con una pantalla de diagnóstico de color morado durante algunas operaciones de ciclo de vida, como descargar un controlador o cambiar entre el modo ENS y el modo de controlador nativo. Por ejemplo, si intenta cambiar el modo ENS, en el seguimiento inverso verá un mensaje de error similar a: case ENS::INTERRUPT::NoVM_DeviceStateWithGracefulRemove hit BlueScreen: ASSERT bora/vmkernel/main/dlmalloc.c:2733 Este problema es específico para las compilaciones beta y no afecta a las compilaciones de versiones como ESXi 7.0.

  Solución alternativa: Actualizar a ESXi 7.0 GA.

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

• Es posible que se rechacen las solicitudes HTTP de algunas bibliotecas a vSphere

  El servicio HTTP Reverse Proxy de vSphere 7.0 exige un cumplimiento de normas más estricto que las versiones anteriores. Esto puede exponer problemas preexistentes en algunas bibliotecas de terceros que utilizan las aplicaciones para las llamadas SOAP a vSphere.

  Si desarrolla aplicaciones de vSphere que utilizan esas bibliotecas o incluyen aplicaciones que dependen de esas bibliotecas en la pila de vSphere, puede experimentar problemas de conexión cuando estas bibliotecas envían solicitudes HTTP a VMOMI. Por ejemplo, las solicitudes HTTP emitidas desde bibliotecas vijava pueden adoptar el siguiente formato:

  POST /sdk HTTP/1.1
  SOAPAction
  Content-Type: text/xml; charset=utf-8
  User-Agent: Java/1.8.0_221

  En este ejemplo, la sintaxis infringe un requisito de campo de encabezado para el protocolo HTTP que exige dos puntos después de SOAPAction. Por lo tanto, la solicitud se rechaza en plena ejecución.

  Solución alternativa: Los desarrolladores que emplean bibliotecas no conformes en sus aplicaciones pueden considerar usar bibliotecas que sigan las normas HTTP en su lugar. Por ejemplo, los desarrolladores que utilizan la biblioteca vijava pueden considerar el uso de la versión más reciente de la biblioteca yavijava en su lugar.

• Es posible que vea un archivo de volcado al utilizar el controlador Broadcom lsi_msgpt3, lsi_msgpt35 y lsi_mr3

  Cuando se utilizan las controladoras lsi_msgpt3, lsi_msgpt35 y lsi_mr3, existe el riesgo de que vea el archivo de volcado lsuv2-lsi-drivers-plugin-util-zdump. Se produce un problema al salir de la instancia de storelib que se utiliza en esta utilidad del complemento. Esto no afecta a las operaciones de ESXi, por lo que puede ignorar el archivo de volcado.

  Solución alternativa: Puede hacer caso omiso de este mensaje sin problemas. Puede utilizar el siguiente comando para eliminar lsuv2-lsi-drivers-plugin:
  
  esxcli software vib remove -n lsuv2-lsiv2-drivers-plugin

• Es posible que vea que no es necesario reiniciar después de configurar la instancia de SR-IOV de un dispositivo PCI en vCenter, pero es posible que se pierdan las configuraciones de dispositivos que las extensiones de terceros definieron y que sea necesario volver a aplicar el reinicio

  En ESXi 7.0, se aplica la configuración de SR-IOV sin reiniciar y se vuelve a cargar el controlador del dispositivo. Puede que los hosts ESXi utilicen extensiones de terceros para realizar configuraciones de dispositivos que se deben ejecutar después de que el controlador del dispositivo se cargue durante el arranque. Es necesario reiniciar para que dichas extensiones de terceros vuelvan a aplicar la configuración del dispositivo.

  Solución alternativa: Debe reiniciar después de configurar SR-IOV para aplicar configuraciones de dispositivos de terceros.

Para contraer la lista de problemas conocidos anteriores, haga clic aquí.