Los problemas conocidos anteriores se agrupan del siguiente modo.
- 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.
- Realizar revisiones a vCenter Server 7.0 Update 1 desde versiones anteriores de vCenter Server 7.x se bloquea si está habilitada vCenter Server High Availability
Realizar revisiones a vCenter Server 7.0 Update 1 desde versiones anteriores de vCenter Server 7.x se bloquea si está activa vCenter Server High Availability.
Solución alternativa: Para realizar revisiones a vCenter Server 7.0 Update 1 desde versiones anteriores de vCenter Server 7.x, debe quitar vCenter Server High Availability y eliminar los nodos pasivos y testigos. Tras la actualización, debe volver a crear los clústeres de vCenter Server High Availability.
- La migración de un sistema vCenter Server 6.7.x a vCenter Server 7.x genera un error UnicodeEncodeError
Si selecciona la opción para importar todos los datos de configuración, el inventario, las tareas, los eventos y las métricas de rendimiento, se puede producir un error en la migración de un sistema vCenter Server de 6.7.x a vCenter Server 7.x para cualquier sistema vCenter Server que utilice una configuración regional que no sea en inglés. En el paso 1 de la etapa 2 de la migración, en vSphere Client se muestra un error como:
Error al exportar los datos de los eventos y tareas: …ERROR UnicodeEncodeError: Traceback (most recent call last):
Solución alternativa: Puede completar la operación de migración, realice una de las siguientes acciones:
- Seleccione la opción predeterminada Configuración e inventario al final de la etapa 1 de la migración.
Esta opción no incluye los datos de tareas y eventos.
- Limpie los datos en las tablas de eventos y vuelva a ejecutar la migración.
- Si un sistema vCenter Server de Windows tiene una contraseña de base de datos que contiene caracteres que no son ASCII, se produce un error en las comprobaciones previas de VMware Migration Assistant
Si intenta migrar un sistema vCenter Server 6.x a vCenter Server 7.x mediante VMware Migration Assistant, se produce un error en la operación si el sistema tiene un sistema operativo Windows y utiliza una base de datos externa con una contraseña que contiene caracteres que no son ASCII. Por ejemplo, Admin!23迁移. En la consola del asistente de migración, se muestra el siguiente error:
Error:Se produjo un error interno en el componente com.vmware.vcdb
Resolución:Archivo Bugzilla PR a VPX/VPX/vcdb-upgrade
Solución alternativa: Ninguna
- Durante una actualización desde vCenter Server 7.x a vCenter Server 7.0 Update 1, se le pide que proporcione la contraseña de vCenter Single Sign-On
Durante una actualización desde vCenter Server 7.x a vCenter Server 7.0 Update 1, se le pide que proporcione la contraseña del administrador de vCenter Single Sign-On.
Solución alternativa: Si ejecuta la actualización mediante la interfaz de administración de vCenter Server, debe proporcionar la contraseña del administrador de vCenter Single Sign-On.
Si ejecuta la actualización mediante el uso de paquetes de software o la CLI de forma interactiva, debe proporcionar la contraseña de administrador de vCenter Single Sign-On de forma interactiva.
Si ejecuta la actualización mediante el uso de paquetes de software o CLI de forma no interactiva, debe proporcionar la contraseña del administrador de vCenter Single Sign-On mediante un archivo de respuesta con el formato
{ "vmdir.password": "Contraseña de SSO del usuario Administrator@<SSO-DOMAIN>
" }
- 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.
- Es posible que no pueda aplicar o quitar NSX mientras agrega varios hosts ESXi mediante una imagen de vSphere Lifecycle Manager a un clúster con VMware vSphere High Availability habilitado
Si inicia una operación para aplicar o quitar NSX al agregar varios hosts ESXi mediante una imagen de vSphere Lifecycle Manager a un clúster con vSphere HA habilitado, las operaciones relacionadas con NSX pueden generar un error en el vSphere Client como:
vSphere HA Agent en algunos de los hosts del clúster <cluster_name> no es el agente principal de vSphere HA ni está conectado al agente principal de vSphere HA. Verifique que la configuración de HA sea correcta.
El problema se produce porque vSphere Lifecycle Manager configura vSphere HA para los hosts ESXi que se agregan al clúster uno a la vez. Si ejecuta una operación para aplicar o quitar NSX mientras las operaciones de configuración de vSphere HA están en curso, es posible que las operaciones de NSX se agoten entre las operaciones de configuración de vSphere HA para dos hosts ESXi diferentes. En tal caso, se produce un error en la operación de NSX con un error de comprobación de estado del clúster, ya que el estado del clúster en ese punto no coincide con el estado esperado de todos los hosts ESXi que tienen vSphere HA configurado y en ejecución. Cuantos más hosts ESXi se agregan a un clúster al mismo tiempo, más probable es que se produzca el problema.
Solución alternativa: Deshabilite y habilite vSphere HA en el clúster. Continúe con las operaciones para aplicar o quitar NSX.
- Después de una actualización de un sistema vCenter Server 7.0, no puede ver las direcciones IP de los pods en la pestaña Resumen de pods de vSphere de vSphere Client
Si actualiza el sistema vCenter Server 7.0 a una versión posterior, ya no podrá ver las direcciones IP de los pods en la pestaña Resumen de pods de vSphere de vSphere Client.
Solución alternativa: Utilice las Herramientas de la CLI de Kubernetes para vSphere para revisar los detalles de los pods:
- Como requisito previo, copie el pod y los nombres del espacio de nombres.
- En vSphere Client, desplácese hasta Administración de cargas de trabajo > Clústeres.
- Copie la dirección IP que se muestra en la pestaña Dirección IP del nodo de plano de control.
- Puede desplazarse hasta
https://<dirección_IP_de_nodo_de_plano_de_control> y descargar las Herramientas de la CLI de Kubernetes: kubectl y kubectl-vsphere.
También puede seguir los pasos que se indican en Descargar e instalar Herramientas de la CLI de Kubernetes para vSphere.
- Use el complemento de CLI para vSphere para revisar los detalles del pod.
- Inicie sesión en el clúster supervisor mediante el comando
kubectl vsphere login --server=https://<server_adress> --vsphere-username <your user account name> --insecure-skip-tls-verify
- Con los nombres copiados en el paso 1, ejecute los comandos para recuperar los detalles del pod:
kubectl config use-context <namespace_name>
y
kubectl describe pod <pod_name> -n <namespace_name>
Como resultado, puede ver la dirección IP, similar a la siguiente:
$ kubectl describe pod helloworld -n my-podvm-ns ...
Estado: En ejecución
IP: 10.0.0.10
IP:
IP: 10.0.0.10 ...
- 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
- La actualización de vCenter Server mediante la CLI conserva de forma incorrecta la configuración de la capa de seguridad de transporte (Transport Security Layer, TLS) para el servicio vSphere Authentication Proxy
Si el servicio vSphere Authentication Proxy (vmcam) se configuró para utilizar un protocolo TLS específico que no es el protocolo TLS 1.2 predeterminado, esta configuración se conserva durante el proceso de actualización de la CLI. De forma predeterminada, vSphere es compatible con el protocolo de cifrado TLS 1.2. Si debe utilizar los protocolos TLS 1.0 y TLS 1.1 para admitir productos o servicios que no son compatibles con TLS 1.2, use la utilidad de configuración de TLS para habilitar o deshabilitar diferentes versiones del protocolo TLS.
Solución alternativa: Use la utilidad de configuración de TLS para configurar el puerto vmcam. Para obtener información sobre cómo administrar la configuración del protocolo TLS y utilizar la utilidad de configuración de TLS, consulte la documentación de seguridad de VMware.
- 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:
- 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.
- 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:
- Elimine del documento del perfil de host todas las reglas de notificación que sean duplicados de las reglas predeterminadas del sistema.
- Compruebe el estado de cumplimiento.
- Corrija el host.
- 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.
- Es posible que se produzca un error al aplicar una revisión a un nodo testigo o pasivo de entornos con VMware vCenter Server High Availability habilitado
En entornos con vCenter Server High Availability habilitado, se puede producir un error al aplicar una revisión a un nodo testigo o pasivo con un mensaje similar al siguiente:
RuntimeError: unidentifiable C++ exception.
Solución alternativa: Deshabilite vCenter Server High Availability. Aplique las revisiones al sistema vCenter Server. Vuelva a habilitar vCenter Server High Availability.
- Después de aplicar la revisión de vCenter Server 7.0.0a al sistema vCenter Server, la versión de TLS de los clientes de almacenamiento de VC puede revertir a la versión predeterminada
Si tiene una configuración de TLS para el servicio de clientes de almacenamiento de VC distinta de la versión 1.2 de TLS predeterminada, es posible que la versión de TLS revierta a la versión predeterminada después de aplicar la revisión de vCenter Server 7.0.0a al sistema vCenter Server.
Solución alternativa: Use la utilidad de configuración de TLS para habilitar o deshabilitar las versiones de TLS en el sistema vCenter Server después de la actualización.
- Después de actualizar el sistema a vCenter Server 7.0.0b, verá el volcado de núcleo de systemd en la carpeta /var/core.
Después de actualizar el sistema a vCenter Server 7.0.0b desde vCenter Server 7.0.0a o vCenter Server 7.0, en la carpeta /var/core se ve systemd core dump, como core.systemd-journal.393 y core.systemd-udevd.405. El volcado de núcleo es inofensivo y se puede eliminar.
Solución alternativa: Ninguna
- Después de actualizar el sistema de vCenter Server a la versión 7.0.0b, la versión de vCenter Server no se actualiza en la DCUI
Después de actualizar el sistema a vCenter Server 7.0.0b desde vCenter Server 7.0.0a o vCenter Server 7.0, seguirá viendo la versión anterior de vCenter Server en la DCUI.
Solución alternativa: Después de completar la actualización, para actualizar la versión de vCenter Server, en el shell del dispositivo, ejecute el comando /usr/lib/applmgmt/dcui/notify.
- Update Planner genera el error No se puede acceder al repositorio configurado debido a la conectividad de red o una URL incorrecta.
Si utiliza Update Planner, que forma parte de vSphere Lifecycle Manager, para facilitar las actualizaciones de vCenter Server, es posible que se muestre el siguiente error en vSphere Client:
No se puede acceder al repositorio configurado debido a la conectividad de red o una URL incorrecta. Compruebe la configuración del repositorio.
El problema se produce cuando se utiliza un repositorio local personalizado, como https:///uploads/dpe/ o una ruta de DBC, para almacenar lo que se extrajo. Si el repositorio personalizado para la aplicación de revisiones basada en URL tiene una directiva de autenticación, es posible que Update Planner no pueda recuperar la lista de actualizaciones disponibles.
Solución alternativa: Configure el repositorio personalizado de tal forma que no sea necesaria la autenticación para acceder a la URL del repositorio personalizado.
- Después de actualizar a vCenter Server 7.0.0b, se muestran errores de vSphere HA en los clústeres basados en imágenes de vSphere Lifecycle Manager
Después de actualizar a vCenter Server 7.0.0b, en los clústeres basados en imágenes de vSphere Lifecycle Manager que están configurados con vSphere HA, es posible que aparezcan mensajes de error sobre la configuración de vSphere HA después de iniciar sesión por primera vez en el entorno. En vSphere Client, se muestran mensajes como:
No se puede completar la configuración del agente de vSphere HA en el host. o
Se produjo un error al aplicar los VIB de HA en el clúster.
El problema se produce debido a que las exportaciones del almacén de imágenes pueden tardar mucho y provocar que se agote el tiempo de espera de la tarea. En /storage/log/vmware/vmware-updatemgr/vum-server/vmware-vum-server.log se ve este mensaje: La exportación está tardando demasiado (caso de error)
Solución alternativa: Este es un problema transitorio que se resuelve en 10 minutos después de que la instancia de vCenter Server esté activa y en ejecución. El problema no afecta a ninguna funcionalidad. vSphere HA funciona según lo esperado en los clústeres afectados. Todas las operaciones relacionadas con las máquinas virtuales, como el encendido y la migración, funcionan en los clústeres habilitados para vSphere HA mientras esta recuperación de errores aún está en curso.
- 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.
- Si intenta deshabilitar vSphere with Tanzu en un clúster de vSphere, la operación se detiene con un error
Si algunas máquinas virtuales fuera de un clúster supervisor residen en cualquiera de los grupos de puertos de segmentos de NSX en el clúster, el script de limpieza no puede eliminar dichos puertos y deshabilitar vSphere with Tanzu en el clúster. En vSphere Client, se muestra el error Error de las solicitudes de limpieza para NSX Manager y la operación se detiene en el estado Eliminando. En el archivo /var/log/vmware/wcp/wcpsvc.log, se ve un mensaje de error como
La ruta de acceso del segmento = [...] tiene máquinas virtuales x o VIF conectadas. Desconecte todas las máquinas virtuales y VIF antes de eliminar un segmento.
Solución alternativa: Elimine las máquinas virtuales indicadas en el archivo /var/log/vmware/wcp/wcpsvc.log desde el segmento. Espere que se restaure la operación.
- Después de actualizar a NSX 6.4.7, cuando se asigna una dirección IPv6 estática a las máquinas virtuales de carga de trabajo en una red IPv6, las máquinas virtuales no pueden hacer ping a la interfaz de puerta de enlace IPv6 de Edge
Este problema se produce después de actualizar las instancias de vSphere Distributed Switch de la versión 6.x a la versión 7.0.
Solución alternativa 1:
Seleccione el VDS en el que se conectan todos los hosts, vaya al ajuste Editar y, en la opción Multidifusión, cambie a básica.
Solución alternativa 2:
Agregue las siguientes reglas en el firewall de Edge:
Haga ping a la regla de permiso.
La regla de permiso de Multicast Listener Discovery (MLD), que son icmp6, tipo 130 (v1) y tipo 143 (v2).
- 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.
- 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.
- 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
- 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.
- Una vez resueltas las condiciones de APD o PDL, es posible que no se pueda acceder al almacén de datos de VMFS con compatibilidad habilitada para discos virtuales agrupados en clúster
Este problema solo se puede producir en los almacenes de datos en los que se habilitó la compatibilidad con discos virtuales agrupados en clúster. Cuando el almacén de datos se recupera de una condición de todas las rutas desactivadas (All Paths Down, APD) o de pérdida de dispositivo permanente (PDL), no se puede acceder a él. Es posible que el registro de VMkernel muestre varios mensajes SCSI3 reservation conflict similares a los siguientes:
2020-02-18T07:41:10.273Z cpu22:1001391219)ScsiDeviceIO: vm 1001391219: SCSIDeviceCmdCompleteCB:2972: Reservation conflict retries 544 for command 0x45ba814b8340 (op: 0x89) to device "naa.624a9370b97601e346f64ba900024d53"
El problema puede ocurrir porque el host ESXi que participa en el clúster pierde las reservas de SCSI para el almacén de datos y no siempre puede volver a adquirirlas automáticamente después de que se recupera el almacén de datos.
Solución alternativa: Registre manualmente la reserva con el siguiente comando:
vmkfstools -L registerkey /vmfs/devices/disks/<device name>
donde <device name> es el nombre del dispositivo en el que se creó el almacén de datos.
- 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.
- Nuevo Los volúmenes de CNS eliminados se pueden mostrar de manera temporal como existentes 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.
- Nuevo 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.
- Nuevo Una operación de eliminación incorrecta para un volumen persistente de CNS puede dejar el volumen no eliminado 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.
- 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`
- No se puede agregar ni modificar un adaptador de red existente en una máquina virtual
Si intenta agregar o modificar un adaptador de red existente en una máquina virtual, es posible que se produzca un error en la tarea Reconfigurar la máquina virtual, como No se puede completar la operación debido a una modificación simultánea de otra operación en vSphere Client. En el archivo /var/log/hostd.log del host ESXi en el que se ejecuta la máquina virtual, se muestran registros como:
2020-07-28T07:47:31.621Z verbose hostd[2102259] [Originator@6876 sub=Vigor.Vmsvc.vm:/vmfs/volumes/vsan:526bc94351cf8f42-41153841cab2f9d9/bad71f5f-d85e-a276-4cf6-246e965d7154/interop_l2vpn_vmotion_VM_1.vmx] NIC: mensaje de control de conexión: No se pudo conectar al dispositivo virtual 'ethernet0'.
En el archivo vpxa.log, se pueden ver entradas similares a: 2020-07-28T07:47:31.941Z info vpxa[2101759] [Originator@6876 sub=Default opID=opId-59f15-19829-91-01-ed] [VpxLRO] -- ERROR task-138 -- vm-13 -- vim.VirtualMachine.reconfigure: vim.fault.GenericVmConfigFault:
Solución alternativa: Para cada host ESXi en su clúster, haga lo siguiente:
- Conéctese al host ESXi mediante SSH y ejecute el comando
esxcli system module parameters set -a -p dvfiltersMaxFilters=8192 -m dvfilter
- Ponga al host ESXi en modo de mantenimiento.
- Reinicie el host ESXi.
Para obtener más información, consulte el artículo 80399 de la base de conocimientos de VMware.
- Los hosts de ESXi 6.5 con procesadores AMD Opteron Generation 3 (Greyhound) no pueden unirse a los clústeres de Enhanced vMotion Compatibility (EVC) AMD REV E o AMD REV F en un sistema vCenter Server 7.0 Update 1
En vCenter Server 7.0 Update 1, los servicios de clúster de vSphere, como vSphere DRS y vSphere HA, se ejecutan en máquinas virtuales de ESX Agent para que los servicios sean funcionalmente independientes de vCenter Server. Sin embargo, la línea base de CPU para los procesadores AMD de las máquinas virtuales de ESX Agent tiene instrucciones de POPCNT SSE4A, lo que impide que los hosts de ESXi 6.5 con procesadores AMD Opteron Generation 3 (Greyhound) habiliten el modo EVC de AMD REV E y AMD REV F en un sistema vCenter Server 7.0 Update 1.
Solución alternativa: Ninguna
- 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.
- Es posible que se produzca un error al importar o implementar archivos OVF locales cuyo nombre contiene caracteres que no son ASCII
Cuando se importan archivos .ovf locales cuyo nombre contiene caracteres que no son ASCII, es posible recibir el mensaje 400 Bad Request Error. Cuando se utilizan estos archivos .ovf para implementar una máquina virtual en vSphere Client, el proceso de implementación se detiene en 0%. Como resultado, es posible recibir el mensaje 400 Bad Request Error o 500 Internal Server Error.
Solución alternativa:
- Elimine los caracteres que no sean ASCII de los nombres de los archivos
.ovf y .vmdk.
- Para editar el archivo
.ovf, ábralo con un editor de texto.
- Busque el nombre de archivo
.vmdk que no sea ASCII y conviértalo en ASCII.
- Importe o implemente nuevamente los archivos guardados.
- Nuevo No puede verse el tercer nivel de objetos anidados en una carpeta de máquina virtual
Realice los pasos siguientes:
- Desplácese hasta un centro de datos y cree una carpeta de máquina virtual.
- En la carpeta de la máquina virtual, cree una carpeta de máquina virtual anidada.
- 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.
- Se produce un error en las operaciones de servicios de archivos de vSAN en los clústeres habilitados para vSphere Lifecycle Manager
Durante un cambio en el estado de un host ESXi, pueden producirse errores en las operaciones de servicios de archivos de vSAN en los clústeres habilitados para vSphere Lifecycle Manager debido a una condición de carrera en vSphere ESX Agent Manager (EAM). El problema se produce durante las actualizaciones y las operaciones, como las de encendido y apagado, o de arranque, o bien cuando el host sale del modo de mantenimiento o de espera. La condición de carrera se produce cuando un endpoint no estaba disponible antes de cambiar el estado del host ESXi. En estos casos, la instancia de EAM inicia un proceso de corrección que no se puede resolver y no se ejecutan operaciones de otros servicios, como los servicios de archivos de vSAN.
Solución alternativa: Reinicie la instancia de vSphere ESX Agent 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.
- Vuelva a conectar el administrador de soporte de hardware a vCenter Server.
- Seleccione un clúster en el menú Hosts y clústeres.
- Seleccione la pestaña Configurar.
- En Servicios, haga clic en vSphere Availability.
- Vuelva a habilitar vSphere HA.
- Si el administrador de soporte de hardware no está disponible de forma permanente, realice los siguientes pasos.
- Elimine el administrador de soporte de hardware y el paquete de soporte de hardware de la especificación de imagen.
- Vuelva a habilitar vSphere HA.
- Seleccione un clúster en el menú Hosts y clústeres.
- Seleccione la pestaña Actualizaciones.
- Haga clic en Editar.
- Elimine el complemento de firmware y controlador, y haga clic en Guardar.
- Seleccione la pestaña Configurar.
- En Servicios, haga clic en vSphere Availability.
- 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:
- Llame a la API del filtro de E/S
UninstallIoFilter_Task desde el objeto administrado de vCenter Server (IoFilterManager).
- Corrija el clúster en vSphere Lifecycle Manager.
- 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, 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.
- 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.
- Si se utiliza un cliente Java para revisar las tareas de corrección, no se pueden extraer los resultados de las operaciones de corrección
Si utiliza un cliente Java para revisar las tareas de corrección, se puede producir un error en la extracción de los resultados con un error ConstraintValidationException. El problema se produce cuando un host ESXi no puede entrar en modo de mantenimiento durante la corrección y obtiene un estado de OMITIDO, pero al mismo tiempo obtiene una marca en curso para las operaciones de corrección consecutivas. Esto causa el error ConstraintValidationException en los clientes Java y no se puede extraer el resultado de la operación de corrección.
Solución alternativa: Solucione los problemas subyacentes que impiden que los hosts ESXi entren en el modo de mantenimiento y vuelva a intentar la operación de corrección.
- Es posible que el almacén de vSphere Lifecycle Manager general y los almacenes locales de las implementaciones de oficinas remotas y sucursales (ROBO) no estén sincronizados
Los clústeres de ROBO con acceso limitado o sin acceso a Internet o conectividad limitada a vCenter Server pueden descargar una imagen de un almacén local para ellos, en lugar de acceder al almacén de vSphere Lifecycle Manager en vCenter Server. Sin embargo, vSphere Lifecycle Manager genera recomendaciones de software en forma de imágenes validadas previamente solo en un nivel central, y es posible que el contenido de la imagen recomendada no esté disponible en un reemplazo de almacén.
Solución alternativa: Si decide utilizar una imagen recomendada, asegúrese de que el contenido entre los reemplazos de almacén y el almacén central esté sincronizado.
- Se puede producir un error en la corrección del clúster mediante vSphere Lifecycle Manager en hosts ESXi con el modo de bloqueo habilitado
Si un clúster tiene hosts ESXi con el modo de bloqueo habilitado, las operaciones de corrección mediante vSphere Lifecycle Manager podrían omitir dichos hosts. En los archivos de registro, aparecen mensajes como Se produjo un error en la tarea de examinación del host y com.vmware.vcIntegrity.lifecycle.EsxImage.UnknownError Se produjo un error desconocido al realizar la operación..
Solución alternativa: Agregue el usuario raíz a la lista de excepciones para el modo de bloqueo y vuelva a intentar la corrección del clúster.
- Después de actualizar a vCenter Server 7.0.0b, en la vista de inicio de vSphere Lifecycle Manager en vSphere Client, no aparece el botón de alternancia Mostrar solo las actualizaciones acumulativas.
En vCenter Server 7.0.0b, puede utilizar el botón de alternancia Mostrar solo las actualizaciones acumulativas para filtrar y seleccionar las revisiones que desee incluir en una línea base cuando utilice vSphere Lifecycle Manager.
El botón está disponible en la pestaña Actualizaciones en el panel Lifecycle Manager, Menú > Lifecycle Manager, que es la vista de inicio de vSphere Lifecycle Manager en vSphere Client. El botón también está disponible en la página Seleccionar revisiones manualmente en la pestaña Líneas base en el asistente Crear línea base, que se abre al seleccionar Nueva > Línea base.
Sin embargo, el botón de alternancia Mostrar solo actualizaciones acumulativas puede no estar visible después de actualizar a vCenter Server 7.0.0b.
Solución alternativa: Después de realizar una actualización a vCenter Server 7.0.0b, reinicie vSphere Client. Para obtener más información, consulte Iniciar, detener y reiniciar servicios.
- El botón de alternancia Mostrar solo las actualizaciones acumulativas está siempre activado al abrir una pestaña en la vista de inicio de vSphere Lifecycle Manager en vSphere Client
En vCenter Server 7.0.0b, puede utilizar el botón de alternancia Mostrar solo las actualizaciones acumulativas para filtrar y seleccionar las revisiones que desee incluir en una línea base cuando utilice vSphere Lifecycle Manager.
El botón está disponible en la pestaña Actualizaciones en el panel Lifecycle Manager, Menú > Lifecycle Manager, que es la vista de inicio de vSphere Lifecycle Manager en vSphere Client. El botón también está disponible en la página Seleccionar revisiones manualmente en la pestaña Líneas base en el asistente Crear línea base, que se abre al seleccionar Nueva > Línea base.
Sin embargo, el botón de alternancia aparece siempre activado al desplazarse a la pestaña Actualizaciones o a la página Seleccionar revisiones manualmente. Incluso si desactiva el botón al desplazarse fuera de la pestaña o la página, este aparecerá la próxima vez que las abra.
Solución alternativa: Ninguna
- Cuando se utiliza Update Planner, es posible que se produzca un error inesperado en vSphere Client al obtener las actualizaciones
Cuando se utiliza Update Planner, que forma parte de vSphere Lifecycle Manager, para facilitar las actualizaciones de vCenter Server, es posible que se muestre el siguiente error en vSphere Client:
Se produjo un error inesperado al obtener las actualizaciones
El problema se produce al utilizar un puerto HTTPS personalizado que impide ejecutar informes de interoperabilidad mediante vSphere Client.
Solución alternativa: Invoque la API manualmente. Para obtener más detalles, consulte API de automatización de vSphere.
- 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.
- 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.
- 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.
- El menú desplegable Acciones no contiene ningún elemento cuando se configura el explorador en un idioma diferente del inglés
Cuando se configura el explorador en un idioma diferente del inglés y se hace clic en el botón Cambiar a la nueva vista en la pestaña Resumen de la máquina virtual en el inventario de vSphere Client, el menú desplegable Acciones del panel Sistema operativo invitado no contiene ningún elemento.
Solución alternativa: Seleccione el menú desplegable Acciones en la parte superior de la página de la máquina virtual.
- 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 <protocol_name>
- 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.
- 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.
- El conjunto de reglas de firewall dinámico de SNMP se modifica mediante perfiles de host durante un proceso de corrección
El conjunto de reglas de firewall de SNMP es un estado dinámico que se procesa durante el tiempo de ejecución. Cuando se aplica un perfil de host, los perfiles de host y SNMP administran la configuración del conjunto de reglas de forma simultánea, lo que puede modificar la configuración del firewall de forma inesperada.
Solución alternativa: Existen dos soluciones alternativas posibles.
- Para permitir que el conjunto de reglas se administre a sí mismo de forma dinámica, excluya la opción de conjunto de reglas de firewall de SNMP en la configuración del perfil de host.
- Para continuar con la doble administración del conjunto de reglas, corrija el estado del conjunto de reglas de firewall cuando sea necesario.
- 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.
- Verá zonas negras o grises en el fondo de una ventana principal de la interfaz de usuario de la consola directa (Direct Console User Interface, DCUI) después de que se cierre una ventana secundaria.
En DCUI, al cerrar una ventana secundaria presionando las teclas ESC o Enter, o los botones Cancelar o Aceptar, la apariencia de la ventana secundaria puede cambiar. El color de fondo cambia a gris o negro en alguna parte de la ventana principal. Sin embargo, toda la información necesaria de la DCUI se muestra de forma adecuada y todas las operaciones realizadas en la DCUI se completan correctamente.
Solución alternativa: Espere un minuto sin actualizar la ventana actual en la DCUI ni presionar ninguna tecla.
