Guía de solución de problemas de NSX-TModificado el 5 de junio de 2018
VMware NSX-T Data Center 2.2
Puede encontrar la documentación técnica más actualizada en el sitio web de VMware:
https://docs.vmware.com/es/
Si tiene comentarios relacionados con esta documentación, envíelos a:
VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com
VMware Spain, S.L.Calle Rafael Boti 262.ª plantaMadrid 28023Tel.: +34 914125000www.vmware.com/es
Copyright © 2017, 2018 VMware, Inc. Todos los derechos reservados. Información sobre el copyright y la marca comercial.
Guía de solución de problemas de NSX-T
VMware, Inc. 2
Contenido
Guía de solución de problemas de NSX-T 5
1 Solución de problemas de conectividad de capa 2 6Comprobar el estado del clúster de NSX Manager y de NSX Controller 6
Comprobar los puertos lógicos 7
Comprobar el estado del nodo de transporte 8
Comprobar el estado del conmutador lógico 8
Comprobar el CCP para el conmutador lógico 9
Comprobar el estado del plano de control local 10
Solucionar problemas de la sesión de configuración 10
Solucionar problemas de la sesión de capa 2 11
Solucionar problemas de plano de datos para un conmutador lógico superpuesto 12
Solucionar problemas de plano de datos para un conmutador lógico de VLAN 14
Solucionar problemas de ARP para un conmutador lógico superpuesto 14
Solucionar problemas de pérdida de paquetes para un conmutador lógico de VLAN o cuando se ha resuelto ARP 15
2 Solucionar problemas de instalación 17
3 Solución de problemas de enrutamiento 21
4 Solución de problemas del firewall 23Determinar las reglas de firewall que se aplican a un host ESXi 23
Determinar las reglas de firewall que se aplican a un host de KVM 26
Registros de paquetes de firewall 27
5 Registros y servicios 29Mensajes de registro 29
Configurar registros remotos 30
Identificadores de mensajes de registro 32
Solucionar problemas de syslog 33
Comprobación de servicios 34
Recopilar paquetes de soporte 36
6 Otros escenarios de solución de problemas 38Error al agregar o eliminar un nodo de transporte 38
El nodo de transporte tarda unos 5 minutos en conectarse a otro controlador 39
La máquina virtual de NSX Manager está degradada 40
VMware, Inc. 3
Se agota el tiempo de espera para que el agente NSX se comunique con NSX Manager 41
Error al agregar un host ESXi 42
Estado incorrecto de NSX Controller 42
No se puede tener acceso a direcciones IP de administración en máquinas virtuales de KVM con IPFIX habilitado 43
Guía de solución de problemas de NSX-T
VMware, Inc. 4
Guía de solución de problemas de NSX-T
La Guía de solución de problemas de NSX-T proporciona información sobre cómo solucionar problemas que podrían producirse en un entorno de NSX-T.
Público objetivoEsta guía es para administradores de sistemas de NSX-T. Se da por sentado que los administradores están familiarizados con operaciones de virtualización, redes y centro de datos.
Glosario de publicaciones técnicas de VMwarePublicaciones técnicas de VMware proporciona un glosario de términos que podrían resultarle desconocidos. Si desea ver las definiciones de los términos que se utilizan en la documentación técnica de VMware, acceda a la página http://www.vmware.com/support/pubs.
VMware, Inc. 5
Solución de problemas de conectividad de capa 2 1Si hay un error de comunicación entre dos interfaces virtuales que están conectadas al el mismo conmutador lógico, por ejemplo, no puede hacer ping a una máquina virtual desde otra, puede seguir los pasos descritos en esta sección para solucionar el error.
Antes de comenzar, asegúrese de que no haya ninguna regla de firewall que bloquee el tráfico entre los dos puertos lógicos. Se recomienda que siga el orden de los temas en esta sección para solucionar el problema de conectividad.
Este capítulo incluye los siguientes temas:
n Comprobar el estado del clúster de NSX Manager y de NSX Controller
n Comprobar los puertos lógicos
n Comprobar el estado del nodo de transporte
n Comprobar el estado del conmutador lógico
n Comprobar el CCP para el conmutador lógico
n Comprobar el estado del plano de control local
n Solucionar problemas de la sesión de configuración
n Solucionar problemas de la sesión de capa 2
n Solucionar problemas de plano de datos para un conmutador lógico superpuesto
n Solucionar problemas de plano de datos para un conmutador lógico de VLAN
n Solucionar problemas de ARP para un conmutador lógico superpuesto
n Solucionar problemas de pérdida de paquetes para un conmutador lógico de VLAN o cuando se ha resuelto ARP
Comprobar el estado del clúster de NSX Manager y de NSX ControllerCompruebe que el estado del clúster de NSX Manager y de NSX Controller sea normal, y que los controladores estén conectados a NSX Manager.
VMware, Inc. 6
Procedimiento
1 Ejecute el siguiente comando de la CLI en NSX Manager para asegurarse de que el estado sea estable.
NSX-Manager> get management-cluster status
Number of nodes in management cluster: 1
- 192.168.110.47 (UUID 45A8869B-BB90-495D-8A01-69B5FCC56086) Online
Management cluster status: STABLE
Number of nodes in control cluster: 3
- 192.168.110.201 (UUID 45A8869B-BB90-495D-8A01-69B5FCC56086)
- 192.168.110.202 (UUID 45A8869B-BB90-495D-8A01-69B5FCC56086)
- 192.168.110.203 (UUID 45A8869B-BB90-495D-8A01-69B5FCC56086)
2 Ejecute el siguiente comando de la CLI en NSX Controller para asegurarse de que el estado sea activo.
NSX-Controller1> get control-cluster status
uuid: db4aa77a-4397-4d65-ad33-9fde79ac3c5c
is master: true
in majority: true
uuid address status
0cfe232e-6c28-4fea-8aa4-b3518baef00d 192.168.110.201 active
bd257108-b94e-4e6d-8b19-7fa6c012961d 192.168.110.202 active
538be554-1240-40e4-8e94-1497e963a2aa 192.168.110.203 active
3 Ejecute el siguiente comando de la CLI en NSX Controller para asegurarse de que esté conectado a NSX Manager.
NSX-Controller1> get managers
- 192.168.110.47 Connected
Comprobar los puertos lógicosCompruebe que los puertos lógicos estén configurados en el mismo conmutador lógico y que su estado sea activo.
Procedimiento
1 En la GUI de NSX Manager, obtenga los UUID de los puertos lógicos.
2 Realice la siguiente llamada API para cada puerto lógico con el fin de garantizar que los puertos lógicos se encuentran en el mismo conmutador lógico.
GET https://<nsx-mgr>/api/v1/logical-ports/<logical-port-uuid>
Guía de solución de problemas de NSX-T
VMware, Inc. 7
3 Realice la siguiente llamada API para cada puerto lógico para asegurarse de que el estado sea activo.
GET https://<nsx-mgr>/api/v1/logical-ports/<logical-port-uuid>/status
Comprobar el estado del nodo de transporteCompruebe el estado del nodo de transporte.
Procedimiento
u Realice la siguiente llamada API para obtener el estado del nodo de transporte.
GET https://<nsx-mgr>/api/v1/transport-nodes/<transport-node-ID>/state
Si la llamada devuelve el error Tiempo de espera de RPC, realice los siguientes pasos de solución de problemas:
n Ejecute /etc/init.d/nsx-opsAgent status para ver si se está ejecutando opsAgent.
n Ejecute /etc/init.d/nsx-mpa status para ver si se está ejecutando nsx-mpa.
n Para ver si nsx-mpa está conectado a NSX Manager, compruebe los registros de latido de nsx-mpa.
n Para ver si opsAgent está conectado a NSX Manager, compruebe el registro de nsx-opsAgent. Si opsAgent está conectado a NSX Manager, verá el siguiente mensaje.
Connected to mpa, cookie: ...
n Para ver si opsAgent tiene bloqueado el procesamiento de HostConfigMsg, compruebe el registro de nsx-opsAgent. Si es así, verá un mensaje de solicitud RMQ, pero la respuesta no se envía o se envía después de un prolongado retraso.
n Compruebe si opsAgent se bloqueó mientras se ejecutaba HostConfigMsg.
n Para ver si los mensajes RMQ demoran mucho tiempo en entregarse al host, compare las marcas de tiempo de los mensajes de registro en NSX Manager y el host.
Si la llamada devuelve el error partial_success, existen muchas causas posibles. Comience viendo los registros de nsx-opsAgent. En el host ESXi, compruebe hostd.log y vmkernel.log. En KVM, syslog contiene todos los registros.
Comprobar el estado del conmutador lógicoCompruebe el estado del conmutador lógico.
Guía de solución de problemas de NSX-T
VMware, Inc. 8
Procedimiento
u Realice la siguiente llamada API para obtener el estado del conmutador lógico.
GET https://<nsx-mgr>/api/v1/logical-switches/<logical-switch-ID>/state
Si la llamada devuelve el error partial_success, la respuesta contendrá una lista de los nodos de transporte donde NSX Manager no pudo insertar la configuración de conmutador lógico o no obtuvo una respuesta. Los pasos de solución de problemas son similares a aquellos para el nodo de transporte. Compruebe lo siguiente:
n Todos los componentes requeridos están instalados y en ejecución.
n nsx-mpa está conectado a NSX Manager.
n nsxa está conectado a la conmutación vertical.
n Ejecute grep para el ID del conmutador lógico en nsxa.log y nsxaVim.log para ver si el nodo de transporte recibió la configuración del conmutador lógico.
n Compruebe el tiempo de actividad de nsxa y nsx-mpa. Averigüe cuándo se inició y se detuvo nsxa mediante grep de los mensajes de registro de nsxa en el archivo syslog.
n Averigüe el tiempo de conexión de nsxa para la conmutación vertical. Si la configuración del conmutador lógico se envía al host cuando nsxa no está conectado a la conmutación vertical, puede que la configuración no se entregue al host.
En KVM, no se inserta ninguna configuración de conmutador lógico en el host. Por lo tanto, es probable que la mayoría de los problemas de conmutador lógico esté en el plano de administración.
En ESXi, se asigna una red opaca al conmutador lógico. Para utilizar el conmutador lógico, los usuarios conectan máquinas virtuales a la red opaca mediante vCenter Server o VSphere API.
Comprobar el CCP para el conmutador lógicoCompruebe que el conmutador lógico esté en el plano de control central (CCP).
Procedimiento
u Ejecute el siguiente comando de la CLI en un NSX Controller para asegurarse de que el conmutador lógico está presente.
NSX-Controller1> get logical switches
VNI UUID Name
52104 feab22ec-94b2-46f4-88f8-f9d44a416272 ls1
Nota Este comando de la CLI no enumera conmutadores lógicos respaldados por VLAN.
Guía de solución de problemas de NSX-T
VMware, Inc. 9
Comprobar el estado del plano de control localPara un conmutador lógico superpuesto, compruebe que el netcpa en el host está conectado al plano de control central.
Requisitos previos
Busque el controlador en el que se encuentra el conmutador lógico. Consulte Comprobar el CCP para el conmutador lógico.
Procedimiento
1 Utilice SSH para el controlador en el que se encuentra el conmutador lógico.
2 Ejecute el siguiente comando y compruebe que el controlador muestre los hipervisores que están conectados a este VNI.
get logical-switch 5000 connection-table
3 En los hipervisores, ejecute el comando /bin/nsxcli para iniciar la CLI de NSX.
4 Ejecute el siguiente comando para obtener las sesiones de CCP.
host1> get ccp-session
Session Index State Controller
Config 0 UP 10.33.74.163
L2 5000 UP 10.33.74.163
Debería ver una sesión de configuración en uno de los nodos CCP en el clúster CCP. Para cada conmutador lógico superpuesto, debe ver una sesión de capa 2 en uno de los nodos CCP en el clúster CCP. Para conmutadores lógicos de VLAN, no hay ninguna conexión de CCP.
Solucionar problemas de la sesión de configuraciónSi la sesión de la configuración de CCP no está activa, compruebe el estado de MPA y netcpa.
Procedimiento
1 Realice la siguiente llamada API para ver si MPA está conectado a NSX Manager.
GET https://<nsx-mgr>/api/v1/logical-ports/<logical-port-uuid>
2 En el hipervisor, ejecute el comando /bin/nsxcli para iniciar la CLI de NSX.
3 Ejecute el siguiente comando para obtener node-uuid.
host1> get node-uuid
0c123dd4-8199-11e5-95e2-73cc1cd9b614
4 Ejecute el siguiente comando para ver si NSX Manager insertó la información del CCP en el host.
cat /etc/vmware/nsx/config-by-vsm.xml
Guía de solución de problemas de NSX-T
VMware, Inc. 10
5 Si config-by-vsm.xml tiene información del CCP, compruebe si hay un nodo de transporte configurado en el hipervisor.
NSX Manager envía el certificado de host del hipervisor en el paso de creación del nodo de transporte. El CCP debe tener el certificado de host antes de aceptar conexiones desde el host.
6 Comprueba la validez del certificado de host en /etc/vmware/nsx/host-cert.pem.
El certificado debe ser el mismo que el que tiene NSX Manager para el host.
7 Ejecute el siguiente comando para comprobar el estado de netcpa.
En ESXi:
/etc/init.d/netcpad status
En KVM:
/etc/init.d/nsx-agent status
8 Inicie o reinicie netcpa.
En ESXi, inicie netcpa en caso de que no se esté ejecutando, o reinícielo si está en ejecución.
/etc/init.d/netcpad start
/etc/init.d/netcpad restart
En KVM, inicie netcpa si no se está ejecutando, o reinícielo si está en ejecución.
/etc/init.d/nsx-agent start
/etc/init.d/nsx-agent restart
9 Si la sesión de configuración aún no está activa, recopile los paquetes de soporte técnico y póngase en contacto con el soporte de VMware.
Solucionar problemas de la sesión de capa 2Esto se aplica solo a conmutadores lógicos superpuestos.
Procedimiento
1 En el hipervisor, ejecute el comando /bin/nsxcli para iniciar la CLI de NSX.
2 Ejecute el siguiente comando para ver si el conmutador lógico está presente en el host.
host1> get logical-switches
Guía de solución de problemas de NSX-T
VMware, Inc. 11
3 Compruebe que el estado del puerto no sea Administrador caído.
En ESXi, ejecute net-dvs y vea la respuesta. Por ejemplo,
port 63eadf53-ff92-4a0e-9496-4200e99709ff:
com.vmware.port.extraConfig.opaqueNetwork.id = … <- this should match the logical switch UUID
com.vmware.port.opaque.network.id = …. <- this should match the logical switch UUID
com.vmware.port.opaque.network.type = nsx.LogicalSwitch , propType = RUNTIME
com.vmware.common.port.block = false, ... <- Make sure the value is false.
com.vmware.vswitch.port.vxlan = …
com.vmware.common.port.volatile.status = inUse ... <- make sure the value is inUse.
Si el puerto lógico termina con el estado bloqueado, recopile los paquetes de soporte técnico y póngase en contacto con el soporte de VMware. Mientras tanto, ejecute el siguiente comando para obtener el nombre de DVS:
[root@host1:~] net-dvs | grep nsx-switch
com.vmware.common.alias = nsx-switch , propType = CONFIG
Ejecute el siguiente comando para desbloquear el puerto:
[root@host1:~] net-dvs -s com.vmware.common.port.block=false <DVS-NAME> -p <logical-port-ID>
En KVM, ejecute ovs-vsctl list interface y compruebe que está presente la interfaz con el UUID de la VIF correspondiente y que admin_state está activo. Puede ver el UUID de la VIF en OVSDB en external-ids:iface-id.
Solucionar problemas de plano de datos para un conmutador lógico superpuestoLos pasos descritos en esta sección son para la solución de problemas de conectividad entre máquinas virtuales en diferentes hipervisores a través del conmutador superpuesto, cuando los estados de configuración y tiempo de ejecución son normales.
Si las máquinas virtuales están en el mismo hipervisor, vaya a Solucionar problemas de ARP para un conmutador lógico superpuesto.
Procedimiento
1 Ejecute el siguiente comando en el controlador que tiene el conmutador lógico para ver si CCP tiene la lista correcta de VTEP:
controller1> get logical-switch 5000 vtep
2 En cada hipervisor, ejecute el siguiente comando de la CLI de NSX para ver si tiene la lista correcta de VTEP:
En ESXi:
host1> get logical-switch <logical-switch-UUID> tep-table
Guía de solución de problemas de NSX-T
VMware, Inc. 12
Como alternativa, puede ejecutar el siguiente comando de shell para obtener la información de VTEP:
[root@host1:~] net-vdl2 -M vtep -s vds -n VNI
En KVM:
host1> get logical-switch <logical-switch-UUID or VNI> tep-table
3 Compruebe si los VTEP en los hipervisores pueden hacer ping entre sí.
En el indicador de shell de ESXi:
host1> ping ++netstack=vxlan <remote-VTEP-IP>
En el indicador de shell de KVM:
host1> ping <remote-VTEP-IP>
Si los VTEP no pueden hacer ping entre sí:
a Asegúrese de que la VLAN de transporte especificada al crear el nodo de transporte coincida con lo que se espera de la red. Si va a utilizar puertos de acceso en la red, la VLAN de transporte se debe establecer en 0. Si va a especificar una VLAN de transporte, los puertos del conmutador subyacente a los que se conectan los hipervisores deben configurarse para que acepten esta VLAN en modo de tronco.
b Compruebe la conectividad de la red.
4 Compruebe que las sesiones BFD entre los VTEP estén activas.
En ESXi, ejecute net-vdl2 -M bfd y vea la respuesta. Por ejemplo,
BFD count: 1
===========================
Local IP: 192.168.48.35, Remote IP: 192.168.197.243, Local State: up, Remote State: up, Local
Diag: No Diagnostic, Remote Diag: No Diagnostic, minRx: 1000000, isDisabled: 0
En KVM, busque la interfaz GENEVE para la dirección IP remota.
ovs-vsctl list interface <GENEVE-interface-name>
Si no conoce el nombre de la interfaz, ejecute ovs-vsctl find Interface type=geneve para devolver todas las interfaces de túnel. Busque información de BFD.
Si no puede encontrar una interfaz GENEVE para VTEP remoto, compruebe si se está ejecutando nsx-agent y si el puente de integración de OVS está conectado a nsx-agent.
[root@host1 ~]# ovs-vsctl show
96c9e543-fc68-448a-9882-6e161c313a5b
Manager "tcp:127.0.0.1:6632"
is_connected: true
Bridge nsx-managed
Guía de solución de problemas de NSX-T
VMware, Inc. 13
Controller "tcp:127.0.0.1:6633"
is_connected: true
Controller "unix:ovs-l3d.mgmt"
is_connected: true
fail_mode: secure
Solucionar problemas de plano de datos para un conmutador lógico de VLANLos pasos descritos en esta sección son para la solución de problemas de conectividad entre máquinas virtuales en diferentes hipervisores a través de la VLAN configurada en la red, cuando los estados de configuración y de tiempo de ejecución son normales.
Si las máquinas virtuales están en el mismo hipervisor y todos los estados de configuración y de tiempo de ejecución son normales, vaya a Solucionar problemas de ARP para un conmutador lógico superpuesto.
Procedimiento
u Compruebe que la red esté configurada para la VLAN para el conmutador lógico en modo de tronco.
En ESXi, compruebe que la VLAN está configurada en el puerto lógico mediante la ejecución de net-dvs y la búsqueda del puerto lógico. Por ejemplo:
port 63eadf53-ff92-4a0e-9496-4200e99709ff:
com.vmware.common.port.volatile.vlan = VLAN 1000 propType = RUNTIME VOLATILE
En KVM, el conmutador lógico de la VLAN está configurado como una regla de Openflow en puente de integración. En otras palabras, para tráfico proveniente de la VIF, etiquételo con VLAN X y reenvíelo en el puerto de revisión hacia el puente PIF. Ejecute ovs-vsctl list interface y compruebe la presencia del puerto de revisión entre el puente administrado por NSX y el puente de conmutador de NSX.
Solucionar problemas de ARP para un conmutador lógico superpuestoLos pasos descritos en esta sección son para solucionar problemas en relación con paquetes que se pierden para un conmutador superpuesto.
Para un conmutador lógico respaldado por VLAN, vaya a Solucionar problemas de pérdida de paquetes para un conmutador lógico de VLAN o cuando se ha resuelto ARP.
Antes de realizar los siguientes pasos de solución de problemas, ejecute el comando arp -n en cada máquina virtual. Si ARP se resolvió correctamente en ambas máquinas virtuales, no es necesario realizar los pasos en esta sección. En su lugar, vaya a la siguiente sección Solucionar problemas de pérdida de paquetes para un conmutador lógico de VLAN o cuando se ha resuelto ARP.
Guía de solución de problemas de NSX-T
VMware, Inc. 14
Procedimiento
u Si ambos endpoints son ESXi y el proxy ARP está habilitado en el conmutador lógico (solo se admite para conmutadores lógicos superpuestos), compruebe la tabla de ARP en el CCP y el hipervisor.
En el CCP:
controller1> get logical-switch 5000 arp-table
En el hipervisor, inicie la CLI de NSX y ejecute el siguiente comando:
host1> get logical-switch <logical-switch-UUID> arp-table
La recuperación de la tabla ARP solo nos indica si tenemos el estado correcto del proxy ARP. Si no se recibe respuesta de ARP a través del proxy, o si el host es KVM y no es compatible con proxy ARP, la ruta de datos debe transmitir la solicitud de ARP. Puede haber un problema con el reenvío de tráfico BUM. Realice los siguientes pasos:
n Si el modo de replicación para el conmutador lógico es MTEP, en la GUI de NSX Manager cambie este modo a SOURCE para el conmutador lógico. Esto podría solucionar el problema y el ping comenzará a funcionar.
n Agregue entradas de ARP estáticas y compruebe si funciona el resto de la ruta de datos.
Solucionar problemas de pérdida de paquetes para un conmutador lógico de VLAN o cuando se ha resuelto ARPPuede usar la herramienta Traceflow automatizada o hacer seguimiento manual de los paquetes para solucionar problemas de pérdida de estos.
Para ejecutar la herramienta Traceflow, en la interfaz gráfica de usuario de NSX Manager, desplácese hasta Herramientas > Traceflow. Para obtener más información, consulte la Guía de administración de NSX-T.
Procedimiento
u Para realizar un seguimiento manual de los paquetes:
En ESXi, ejecute net-stats -l para obtener el ID de puerto de conmutador de las VIF. Si las VIF de origen y destino están en el mismo hipervisor, ejecute los siguientes comandos:
pktcap-uw --switchport <src-switch-port-ID> --dir=0
pktcap-uw --switchport <dst-switch-port-ID> --dir=1
Si las VIF de origen y destino están en hipervisores diferentes, en el hipervisor que aloja la VIF de origen, ejecute los siguientes comandos:
pktcap-uw --switchport <src-switch-port-ID> --dir=0
pktcap-uw --uplink <uplink-name> --dir=1
Guía de solución de problemas de NSX-T
VMware, Inc. 15
En el hipervisor que aloja la VIF de destino, ejecute los siguientes comandos:
pktcap-uw --uplink <uplink-name> --dir=0
pktcap-uw --switchport <dest-switch-port-ID> --dir=1
En KVM, si las VIF de origen y destino están en el mismo hipervisor, ejecute el siguiente comando:
ovs-dpctl dump-flows
Guía de solución de problemas de NSX-T
VMware, Inc. 16
Solucionar problemas de instalación 2En esta sección, se incluye información sobre cómo solucionar problemas relacionados con la instalación.
Servicios de infraestructura básicosLos siguientes servicios deben ejecutarse en los dispositivos e hipervisores, así como en vCenter Server si se utiliza como un administrador de equipos.
n NTP
n DNS
Asegúrese de que el firewall no esté bloqueando el tráfico entre los componentes de NSX-T y los hipervisores. Compruebe que los puertos requeridos estén abiertos entre los componentes.
Para vaciar la caché DNS en NSX Manager, utilice SSH para iniciar sesión como usuario root en el administrador y ejecute el siguiente comando:
root@nsx-mgr-01:~# /etc/init.d/resolvconf restart
[ ok ] Restarting resolvconf (via systemctl): resolvconf.service.
A continuación, puede comprobar el archivo de configuración de DNS.
root@nsx-mgr-01:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.253.1
search mgt.sg.lab
VMware, Inc. 17
Comprobar la comunicación del host al controlador y al administradorEn un host ESXi mediante comandos de la CLI de NSX-T:
esxi-01.corp.local> get managers
- 192.168.110.19 Connected
esxi-01.corp.local> get controllers
Controller IP Port SSL Status Is Physical Master Session State Controller
FQDN
192.168.110.16 1234 enabled connected true up NA
En un host de KVM mediante comandos de la CLI de NSX-T:
kvm-01> get managers
- 192.168.110.19 Connected
kvm-01> get controllers
Controller IP Port SSL Status Is Physical Master Session State Controller
FQDN
192.168.110.16 1234 enabled connected true up NA
En un host ESXi mediante comandos de la CLI de host:
[root@esxi-01:~] esxcli network ip connection list | grep 1234
tcp 0 0 192.168.110.53:42271 192.168.110.16:1234
ESTABLISHED 67702 newreno netcpa
[root@esxi-01:~]
[root@esxi-01:~] esxcli network ip connection list | grep 5671
tcp 0 0 192.168.110.253:11721 192.168.110.19:5671 ESTABLISHED 2103688
newreno mpa
tcp 0 0 192.168.110.253:30977 192.168.110.19:5671 ESTABLISHED 2103688
newreno mpa
En un host de KVM mediante comandos de la CLI de host:
root@kvm-01:/home/vmware# netstat -nap | grep 1234
tcp 0 0 192.168.110.55:53686 192.168.110.16:1234 ESTABLISHED 2554/netcpa
root@kvm-01:/home/vmware#
root@kvm-01:/home/vmware#
root@kvm-01:/home/vmware# netstat -nap | grep 5671
tcp 0 0 192.168.110.55:50108 192.168.110.19:5671 ESTABLISHED 2870/mpa
tcp 0 0 192.168.110.55:50110 192.168.110.19:5671 ESTABLISHED 2870/mpa
root@kvm-01:/home/vmware# tcpdump -i ens32 port 1234 | grep kvm-01
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes
<truncated output>
03:46:27.040461 IP nsxcontroller01.corp.local.1234 > kvm-01.corp.local.38754: Flags [P.], seq
3315301231:3315301275, ack 2671171555, win 323, length 44
03:46:27.040509 IP kvm-01.corp.local.38754 > nsxcontroller01.corp.local.1234: Flags [.], ack 44, win
1002, length 0
Guía de solución de problemas de NSX-T
VMware, Inc. 18
^C
<truncated output>
root@kvm-01:/home/vmware#
root@kvm-01:/home/vmware# tcpdump -i ens32 port 5671 | grep kvm-01
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes
03:51:16.802934 IP kvm-01.corp.local.58954 > nsxmgr01.corp.local.amqps: Flags [P.], seq 1153:1222,
ack 1790, win 259, length 69
03:51:16.823328 IP nsxmgr01.corp.local.amqps > kvm-01.corp.local.58954: Flags [P.], seq 1790:1891,
ack 1222, win 254, length 101
^C
<truncated output>
Error de registro de hostSi NSX-T utiliza la dirección IP incorrecta, se producirá un error en el registro de host. Esto puede suceder cuando un host tiene varias direcciones IP. Al intentar eliminar el nodo de transporte, queda en el estado huérfano. Para resolver el problema, realice lo siguiente:
n Vaya a Tejido > Nodos > Hosts, edite el host y quite todas las direcciones IP, excepto la de administración.
n Haga clic en los errores y seleccione Resolver.
Problemas de host de KVMLos problemas del host de KVM en ocasiones se producen porque no hay suficiente espacio de disco. El directorio /boot puede llenarse rápidamente y provocar errores como los siguientes:
n No se puede instalar el software en el host.
n No hay más espacio en el dispositivo.
Puede ejecutar el comando df -h para comprobar el espacio de almacenamiento disponible. Si el directorio /boot está al 100 %, puede hacer lo siguiente:
n Ejecute sudo dpkg --list 'linux-image*' | grep ^ii para ver todos los kernels instalados.
n Ejecute uname -r para ver el kernel en ejecución actualmente. No elimine este kernel (imagen de Linux).
n Utilice apt-get purge para quitar las imágenes que ya no necesite. Por ejemplo, ejecute sudo apt-get purge linux-image-3.13.0-32-generic linux-image-3.13.0-33-generic.
n Reinicie el host.
n En NSX Manager, compruebe los errores y seleccione Resolver.
n Asegúrese de que las máquinas virtuales estén encendidas.
Guía de solución de problemas de NSX-T
VMware, Inc. 19
Error de configuración al implementar una máquina virtual de EdgeDespués de implementar una máquina virtual de Edge, NSX Manager muestra el estado de la máquina virtual como Error de configuración. En el registro del administrador, aparece un mensaje similar al siguiente:
nsx-manager NSX - FABRIC [nsx@6876 comp="nsx-manager" errorCode="MP16027" subcomp="manager"] Edge
758ad396-0754-11e8-877e-005056abf715 is not ready for configuration error occurred, error detail is
NSX Edge configuration has failed. The host does not support required cpu features: ['aes'].
Si se reinician el servicio de ruta de datos de Edge y, a continuación, la máquina virtual, el problema debería resolverse.
Forzar la eliminación de un nodo de transportePuede quitar un nodo de transporte que está atascado en el estado huérfano realizando la siguiente llamada API:
DELETE https://<NSX Manager>/api/v1/transport-nodes/<TN ID>?force=true
NSX Manager no realizará ninguna validación en cuanto a si se dispone de máquinas virtuales activas en ejecución en el host. Usted es responsable de eliminar el N-VDS y los VIB. Si tiene el nodo agregado a través del administrador de equipos, elimine primero el administrador de equipos y, a continuación, elimine el nodo. También se eliminará el nodo de transporte.
Guía de solución de problemas de NSX-T
VMware, Inc. 20
Solución de problemas de enrutamiento 3NSX-T tiene herramientas integradas para solucionar problemas de enrutamiento.
TraceflowPuede utilizar Traceflow para inspeccionar el flujo de paquetes. Puede ver los paquetes entregados, descartados, recibidos y reenviados. Si se descarta un paquete, se muestra un motivo. Por ejemplo, se puede descartar un paquete debido a una regla de firewall.
Comprobación de las tablas de enrutamientoPara ver la tabla de enrutamiento en un enrutador de servicio, ejecute los siguientes comandos:
edge01> get logical-router
Logical Route
UUID VRF LR-ID Name Type
Ports
736a80e3-23f6-5a2d-81d6-bbefb2786666 0 0 TUNNEL 3
c9393d0c-1fcf-4c34-889d-2da1eeee25b8 1 10 SR-t0-router SERVICE_ROUTER_TIER0 5
9333c94e-5938-46b4-8c7d-5e6ac2c8b7b5 2 8 DR-t1-router01 DISTRIBUTED_ROUTER_TIER1 6
c91eb7c5-0297-4fed-9c22-b96df1c9b80f 3 9 DR-t0-router DISTRIBUTED_ROUTER_TIER0 4
edge01> vrf 1
edge01(tier0_sr)> get route
Flags: c - connected, s - static, b - BGP, ns - nsx_static
nc - nsx_connected, rl - router_link, t0n: Tier0-NAT, t1n: Tier1-NAT
t1l: Tier1-LB VIP, t1s: Tier1-LB SNAT
Total number of routes: 25
b 10.10.20.0/24 [20/0] via 192.168.140.1
b 10.10.30.0/24 [20/0] via 192.168.140.1
b 10.20.20.0/24 [20/0] via 192.168.140.1
b 10.20.30.0/24 [20/0] via 192.168.140.1
b 30.0.0.0/8 [20/0] via 192.168.140.1
rl 100.64.80.0/31 [0/0] via 169.254.0.1
rl 100.64.80.2/31 [0/0] via 169.254.0.1
rl 100.64.80.4/31 [0/0] via 169.254.0.1
<TRUNCATED OUTPUT>
b 192.168.200.0/24 [20/0] via 192.168.140.1
VMware, Inc. 21
b 192.168.210.0/24 [20/0] via 192.168.140.1
b 192.168.220.0/24 [20/0] via 192.168.140.1
b 192.168.230.0/24 [20/0] via 192.168.140.1
b 192.168.240.0/24 [20/0] via 192.168.140.1
Para obtener la dirección IP de las interfaces, ejecute el siguiente comando:
edge01(tier0_sr)> get interfaces
Logical Router
UUID VRF LR-ID Name Type
c9393d0c-1fcf-4c34-889d-2da1eeee25b8 1 10 SR-t0-router SERVICE_ROUTER_TIER0
interfaces
interface : 977ac2eb-8ab7-40e9-8abe-782a438c749a
ifuid : 285
name : uplink01
mode : lif
IP/Mask : 192.168.140.3/24
MAC : 00:50:56:b5:d5:64
LS port : 14391f86-efef-4e3d-98c3-f291c17d13f8
urpf-mode : STRICT_MODE
admin : up
MTU : 1600
interface : 6af81d72-4d32-5f66-b7ae-403e617290e5
ifuid : 270
mode : blackhole
interface : 015e709d-6079-5c19-9556-8be2e956f775
ifuid : 269
mode : cpu
interface : 3f40f838-eb8a-4f35-854c-ea8bb872dc47
ifuid : 272
name : bp-sr0-port
mode : lif
IP/Mask : 169.254.0.2/28
MAC : 02:50:56:56:53:00
VNI : 25489
LS port : 770a208d-27fa-4f8d-afad-a9c41ca6295b
urpf-mode : NONE
admin : up
MTU : 1500
interface : 00003300-0000-0000-0000-00000000000a
ifuid : 263
mode : loopback
IP/Mask : 127.0.0.1/8
Anunciar rutas T1Se deben anunciar rutas T1 para que estén visibles en el enrutador T0 en adelante. Hay diferentes tipos de rutas que puede anunciar: conectada con NSX, NAT, estática, LB VIP y LB SNAT.
Guía de solución de problemas de NSX-T
VMware, Inc. 22
Solución de problemas del firewall 4En esta sección se incluye información sobre cómo solucionar problemas relacionados con el firewall.
Este capítulo incluye los siguientes temas:
n Determinar las reglas de firewall que se aplican a un host ESXi
n Determinar las reglas de firewall que se aplican a un host de KVM
n Registros de paquetes de firewall
Determinar las reglas de firewall que se aplican a un host ESXiPara solucionar los problemas del firewall de un host ESXi, puede consultar las reglas de firewall que se aplican al host.
Obtenga la lista de dvfilters en el host ESXi:
[root@esxi-01:~] summarize-dvfilter
<TRUNCATED OUTPUT>
world 70181 vmm0:app-01a vcUuid:'50 35 9c 70 18 8e 99 1d-3c f9 8e cc 6b 27 4c 6f'
port 50331655 app-01a.eth0
vNic slot 2
name: nic-70181-eth0-vmware-sfw.2
agentName: vmware-sfw
state: IOChain Attached
vmState: Detached
failurePolicy: failClosed
slowPathID: none
filter source: Dynamic Filter Creation
world 70179 vmm0:web-02a vcUuid:'50 35 2b f3 4a 4b 10 83-54 72 50 f7 25 10 d8 64'
port 50331656 web-02a.eth0
vNic slot 2
name: nic-70179-eth0-vmware-sfw.2
agentName: vmware-sfw
state: IOChain Attached
vmState: Detached
failurePolicy: failClosed
slowPathID: none
filter source: Dynamic Filter Creation
VMware, Inc. 23
Busque dvfilter para una máquina virtual específica:
[root@esxi-01:~] summarize-dvfilter | less -p web
world 70179 vmm0:web-02a vcUuid:'50 35 2b f3 4a 4b 10 83-54 72 50 f7 25 10 d8 64'
port 50331656 web-02a.eth0
vNic slot 2
name: nic-70179-eth0-vmware-sfw.2
agentName: vmware-sfw
state: IOChain Attached
vmState: Detached
failurePolicy: failClosed
slowPathID: none
filter source: Dynamic Filter Creation
.
.
.
Determine las reglas de firewall que se aplican a un dvfilter específico (en este ejemplo, nic-70227-eth0-vmware-sfw.2 es el nombre del dvfilter):
[root@esxi-02:~] vsipioctl getrules -f nic-70227-eth0-vmware-sfw.2
ruleset mainrs {
rule 3072 at 1 inout protocol tcp from any to addrset 48822ec3-2670-497b-82f9-524618c16877 port 443
accept with log;
rule 3072 at 2 inout protocol tcp from any to addrset 48822ec3-2670-497b-82f9-524618c16877 port 80
accept with log;
rule 3074 at 3 inout protocol tcp from addrset 48822ec3-2670-497b-82f9-524618c16877 to addrset
8b9e75e7-bc62-4d7f-9a58-a872f393448e port 8443 accept with log;
rule 3074 at 4 inout protocol tcp from addrset 48822ec3-2670-497b-82f9-524618c16877 to addrset
8b9e75e7-bc62-4d7f-9a58-a872f393448e port 22 accept with log;
rule 3075 at 5 inout protocol tcp from addrset 8b9e75e7-bc62-4d7f-9a58-a872f393448e to addrset
b695c8df-9894-4068-a5e7-5504fe48d459 port 3306 accept with log;
rule 3076 at 6 inout protocol tcp from ip 192.168.110.10 to addrset rdst3076 port 443 accept with log;
rule 3076 at 7 inout protocol icmp typecode 8:0 from ip 192.168.110.10 to addrset rdst3076 accept
with log;
rule 3076 at 8 inout protocol tcp from ip 192.168.110.10 to addrset rdst3076 port 22 accept with log;
rule 3076 at 9 inout protocol tcp from ip 192.168.110.10 to addrset rdst3076 port 80 accept with log;
rule 2 at 10 inout protocol any from any to any accept with log;
}
ruleset mainrs_L2 {
rule 1 at 1 inout ethertype any stateless from any to any accept;
}
Obtenga la lista de conjuntos de direcciones que se utilizan en un dvfilter específico:
[root@esxi-02:~] vsipioctl getaddrsets -f nic-70227-eth0-vmware-sfw.2
addrset 48822ec3-2670-497b-82f9-524618c16877 {
ip 172.16.10.13,
mac 52:54:00:42:4d:38,
}
addrset 8b9e75e7-bc62-4d7f-9a58-a872f393448e {
}
Guía de solución de problemas de NSX-T
VMware, Inc. 24
addrset b695c8df-9894-4068-a5e7-5504fe48d459 {
ip 172.16.30.11,
mac 52:54:00:64:0e:4f,
}
addrset rdst3076 {
ip 172.16.10.13,
ip 172.16.30.11,
mac 52:54:00:42:4d:38,
mac 52:54:00:64:0e:4f,
}
Compruebe los flujos de un dvfilter específico:
[root@esxi-02:~] vsipioctl getflows -f nic-75360-eth0-vmware-sfw.2
Count retrieved from kernel active(L3,L4)=20, active(L2)+inactive(L3,L4)=0, drop(L2,L3,L4)=0
a5d914f7a5b85fe5 Active tcp 0800 IN 3076 0 0 192.168.110.10:Unknown(51281) -> 172.16.10.11:ssh(22)
513 FINWAIT2:FINWAIT2 4304 5177 34 33
a5d914f7a5b86001 Active tcp 0800 OUT 2 0 0 172.16.10.11:http(80) -> 100.64.80.1:Unknown(60006) 457
SYNSENT:CLOSED 56 819 1 1
a5d914f7a5b86006 Active igmp 0800 IN 2 0 0 0.0.0.0 -> 224.0.0.1 36 0 1 0
a5d914f7a5b86011 Active tcp 0800 IN 3072 0 0 100.64.80.1:Unknown(60098) -> 172.16.10.11:http(80) 320
FINWAIT2:FINWAIT2 413 5411 9 6
a5d914f7a5b86012 Active tcp 0800 OUT 3074 0 0 172.16.10.11:Unknown(46001) ->
172.16.20.11:Unknown(8443) 815 FINWAIT2:FINWAIT2 7418 1230 10 9
a5d914f7a5b86013 Active udp 0800 OUT 2 0 0 172.16.10.11:Unknown(40080) -> 192.168.110.10:domain(53)
268 140 2 2
a5d914f7a5b86014 Active udp 0800 OUT 2 0 0 172.16.10.11:Unknown(59251) -> 192.168.110.10:domain(53)
268 140 2 2
a5d914f7a5b86015 Active ipv6-icmp 86dd OUT 2 0 0 fe80::250:56ff:feb5:a60e -> ff02::1:ff62:5ed4 135 0
0 72 0 1
a5d914f7a5b86016 Active ipv6-icmp 86dd OUT 2 0 0 fe80::250:56ff:feb5:a60e -> ff02::1:ff62:5ed4 135 0
0 72 0 1
a5d914f7a5b86017 Active tcp 0800 IN 3072 0 0 100.64.80.1:Unknown(60104) -> 172.16.10.11:http(80) 320
FINWAIT2:FINWAIT2 413 5451 9 7
a5d914f7a5b86018 Active tcp 0800 OUT 3074 0 0 172.16.10.11:Unknown(46002) ->
172.16.20.11:Unknown(8443) 815 TIMEWAIT:TIMEWAIT 7314 1230 8 9
a5d914f7a5b86019 Active tcp 0800 IN 3072 0 0 100.64.80.1:Unknown(60110) -> 172.16.10.11:http(80) 320
FINWAIT2:FINWAIT2 373 5451 8 7
a5d914f7a5b8601a Active tcp 0800 OUT 3074 0 0 172.16.10.11:Unknown(46003) ->
172.16.20.11:Unknown(8443) 815 FINWAIT2:FINWAIT2 7418 1230 10 9
a5d914f7a5b8601b Active tcp 0800 IN 3072 0 0 100.64.80.1:Unknown(60114) -> 172.16.10.11:http(80) 328
TIMEWAIT:TIMEWAIT 413 5451 9 7
a5d914f7a5b8601c Active tcp 0800 OUT 3074 0 0 172.16.10.11:Unknown(46004) ->
172.16.20.11:Unknown(8443) 815 TIMEWAIT:TIMEWAIT 7262 1218 7 9
a5d914f7a5b8601d Active tcp 0800 OUT 2 0 0 172.16.10.11:http(80) -> 100.64.80.1:Unknown(60060) 457
SYNSENT:CLOSED 56 819 1 1
a5d914f7a5b8601e Active tcp 0800 IN 3072 0 0 100.64.80.1:Unknown(60120) -> 172.16.10.11:http(80) 320
TIMEWAIT:TIMEWAIT 373 5411 8 6
a5d914f7a5b8601f Active tcp 0800 OUT 3074 0 0 172.16.10.11:Unknown(46005) ->
172.16.20.11:Unknown(8443) 815 FINWAIT2:FINWAIT2 7418 1230 10 9
a5d914f7a5b86020 Active tcp 0800 IN 3072 0 0 100.64.80.1:Unknown(60126) -> 172.16.10.11:http(80) 229
EST:EST 173 5371 3 5
a5d914f7a5b86021 Active tcp 0800 OUT 3074 0 0 172.16.10.11:Unknown(46006) ->
172.16.20.11:Unknown(8443) 815 FINWAIT2:FINWAIT2 7418 1230 10 9
Guía de solución de problemas de NSX-T
VMware, Inc. 25
Determinar las reglas de firewall que se aplican a un host de KVMPara solucionar los problemas de firewall de un host de KVM, puede consultar las reglas de firewall que se aplican al host.
Obtenga la lista de VIF que están sujetos a reglas de firewall en el host de KVM:
# ovs-appctl -t /var/run/openvswitch/nsxa-ctl dfw/vif
Vif ID : da95fc1e-65fd-461f-814d-d92970029bf0
Port name : db-01a-eth0
Port number : 2
Si el resultado está vacío, busque problemas de conectividad entre el nodo y los controladores.
Obtenga la lista de reglas que se aplican a un VIF específico (en este ejemplo, da95fc1e-65fd-461f-814d-d92970029bf0 es el identificador de VIF):
# ovs-appctl -t /var/run/vmware/nsx-agent/nsxa-ctl dfw/rules da95fc1e-65fd-461f-814d-d92970029bf0
Distributed firewall status: enabled
Vif ID : da95fc1e-65fd-461f-814d-d92970029bf0
ruleset d035308b-cb0d-4e7e-aae5-a428b461db46 {
rule 3072 inout protocol tcp from any to addrset 48822ec3-2670-497b-82f9-524618c16877 port 443
accept with log;
rule 3072 inout protocol tcp from any to addrset 48822ec3-2670-497b-82f9-524618c16877 port 80 accept
with log;
rule 3074 inout protocol tcp from addrset 48822ec3-2670-497b-82f9-524618c16877 to addrset 8b9e75e7-
bc62-4d7f-9a58-a872f393448e port 8443 accept with log;
rule 3074 inout protocol tcp from addrset 48822ec3-2670-497b-82f9-524618c16877 to addrset 8b9e75e7-
bc62-4d7f-9a58-a872f393448e port 22 accept with log;
rule 3075 inout protocol tcp from addrset 8b9e75e7-bc62-4d7f-9a58-a872f393448e to addrset
b695c8df-9894-4068-a5e7-5504fe48d459 port 3306 accept with log;
}
ruleset 3027fed3-60b1-483e-aa17-c28719275704 {
rule 3076 inout protocol tcp from 192.168.110.10 to addrset b695c8df-9894-4068-a5e7-5504fe48d459
port 443 accept with log;
rule 3076 inout protocol icmp type 8 code 0 from 192.168.110.10 to addrset b695c8df-9894-4068-
a5e7-5504fe48d459 accept with log;
rule 3076 inout protocol tcp from 192.168.110.10 to addrset b695c8df-9894-4068-a5e7-5504fe48d459
port 22 accept with log;
rule 3076 inout protocol tcp from 192.168.110.10 to addrset b695c8df-9894-4068-a5e7-5504fe48d459
port 80 accept with log;
rule 3076 inout protocol tcp from 192.168.110.10 to addrset 8b9e75e7-bc62-4d7f-9a58-a872f393448e
port 443 accept with log;
rule 3076 inout protocol icmp type 8 code 0 from 192.168.110.10 to addrset 8b9e75e7-bc62-4d7f-9a58-
a872f393448e accept with log;
rule 3076 inout protocol tcp from 192.168.110.10 to addrset 8b9e75e7-bc62-4d7f-9a58-a872f393448e
port 22 accept with log;
rule 3076 inout protocol tcp from 192.168.110.10 to addrset 8b9e75e7-bc62-4d7f-9a58-a872f393448e
port 80 accept with log;
rule 3076 inout protocol tcp from 192.168.110.10 to addrset 48822ec3-2670-497b-82f9-524618c16877
Guía de solución de problemas de NSX-T
VMware, Inc. 26
port 443 accept with log;
rule 3076 inout protocol icmp type 8 code 0 from 192.168.110.10 to addrset
48822ec3-2670-497b-82f9-524618c16877 accept with log;
rule 3076 inout protocol tcp from 192.168.110.10 to addrset 48822ec3-2670-497b-82f9-524618c16877
port 22 accept with log;
rule 3076 inout protocol tcp from 192.168.110.10 to addrset 48822ec3-2670-497b-82f9-524618c16877
port 80 accept with log;
}
ruleset 5e9bdcb3-adba-4f67-a680-5e6ed5b8f40a {
rule 2 inout protocol any from any to any accept with log;
}
ruleset ddf93011-4078-4006-b8f8-73f979d7a717 {
rule 1 inout ethertype any stateless from any to any accept;
}
Obtenga la lista de conjuntos de direcciones que se utilizan en un VIF específico:
# ovs-appctl -t /var/run/vmware/nsx-agent/nsxa-ctl dfw/addrsets da95fc1e-65fd-461f-814d-d92970029bf0
48822ec3-2670-497b-82f9-524618c16877 {
mac 52:54:00:42:4d:38,
ip 172.16.10.13,
}
8b9e75e7-bc62-4d7f-9a58-a872f393448e {
}
b695c8df-9894-4068-a5e7-5504fe48d459 {
mac 52:54:00:64:0e:4f,
ip 172.16.30.11,
}
Compruebe las conexiones a través del módulo Linux Conntrack. En este ejemplo, buscamos flujos entre dos direcciones IP específicas.
# ovs-appctl -t ovs-l3d conntrack/show | grep 192.168.110.10 | grep 172.16.10.13
ACTIVE
icmp,orig=(src=192.168.110.10,dst=172.16.10.13,id=1,type=8,code=0),reply=(src=172.16.10.13,dst=192.168
.110.10,id=1,type=0,code=0),start=2018-03-26T04:43:28.325,id=3122159040,zone=23119,status=SEEN_REPLY|
CONFIRMED,timeout=29,mark=3076,labels=0x1f
Registros de paquetes de firewallSi se habilita el registro de reglas de firewall, puede consultar los registros de paquetes de firewall para solucionar los problemas.
El archivo de registro es /var/log/dfwpktlogs.log para los hosts ESXi y de KVM.
# tail -f /var/log/dfwpktlogs.log
2018-03-27T10:23:35.196Z INET TERM 3072 IN TCP FIN 100.64.80.1/60688->172.16.10.11/80 8/7 373/5451
2018-03-27T10:23:35.196Z INET TERM 3074 OUT TCP FIN 172.16.10.11/46108->172.16.20.11/8443 8/9
1178/7366
Guía de solución de problemas de NSX-T
VMware, Inc. 27
2018-03-27T10:23:35.196Z INET TERM 3072 IN TCP RST 100.64.80.1/60692->172.16.10.11/80 9/6 413/5411
2018-03-27T10:23:35.196Z INET TERM 3074 OUT TCP RST 172.16.10.11/46109->172.16.20.11/8443 9/7
1218/7262
2018-03-27T10:23:37.442Z 71d32787 INET match PASS 3074 IN 60 TCP 172.16.10.12/35770-
>172.16.20.11/8443 S
2018-03-27T10:23:38.492Z INET match PASS 2 OUT 1500 TCP 172.16.10.11/80->100.64.80.1/60660 A
2018-03-27T10:23:39.934Z INET match PASS 3072 IN 52 TCP 100.64.80.1/60720->172.16.10.11/80 S
2018-03-27T10:23:39.944Z INET match PASS 3074 OUT 60 TCP 172.16.10.11/46114->172.16.20.11/8443 S
2018-03-27T10:23:39.944Z 71d32787 INET match PASS 3074 IN 60 TCP 172.16.10.11/46114-
>172.16.20.11/8443 S
2018-03-27T10:23:42.449Z 71d32787 INET match PASS 3074 IN 60 TCP 172.16.10.12/35771-
>172.16.20.11/8443 S
2018-03-27T10:23:44.712Z INET TERM 3074 IN TCP RST 172.16.10.11/46109->172.16.20.11/8443 9/7 1218/7262
2018-03-27T10:23:44.712Z INET TERM 3074 IN TCP FIN 172.16.10.12/35766->172.16.20.11/8443 9/10
1233/7418
2018-03-27T10:23:44.712Z INET TERM 3074 IN TCP FIN 172.16.10.11/46110->172.16.20.11/8443 9/9 1230/7366
2018-03-27T10:23:44.712Z INET TERM 3074 IN TCP FIN 172.16.10.12/35767->172.16.20.11/8443 9/10
1233/7418
2018-03-27T10:23:44.939Z INET match PASS 3072 IN 52 TCP 100.64.80.1/60726->172.16.10.11/80 S
2018-03-27T10:23:44.957Z INET match PASS 3074 OUT 60 TCP 172.16.10.11/46115->172.16.20.11/8443 S
2018-03-27T10:23:44.957Z 71d32787 INET match PASS 3074 IN 60 TCP 172.16.10.11/46115-
>172.16.20.11/8443 S
2018-03-27T10:23:45.480Z INET TERM 2 OUT TCP TIMEOUT 172.16.10.11/80->100.64.80.1/60528 1/1 1500/56
Guía de solución de problemas de NSX-T
VMware, Inc. 28
Registros y servicios 5Los registros pueden ser útiles en muchas situaciones de solución de problemas. También es importante comprobar el estado de los servicios.
Este capítulo incluye los siguientes temas:
n Mensajes de registro
n Solucionar problemas de syslog
n Comprobación de servicios
n Recopilar paquetes de soporte
Mensajes de registroLos mensajes de registro de todos los componentes de NSX-T, incluidos los que se ejecutan en hosts ESXi, tienen el formato de syslog que se especifica en RFC 5424. Los mensajes de registro provenientes de los hosts de KVM tienen el formato de RFC 3164. Los archivos de registro están en el directorio /var/log.
En los dispositivos de NSX-T, puede ejecutar el siguiente comando de la CLI de NSX-T para ver los registros:
get log-file <auth.log | http.log | kern.log | manager.log | node-mgmt.log | syslog> [follow]
En los hipervisores, puede utilizar comandos de Linux como tac, tail, grep y more para ver los registros. También puede usar estos comandos en los dispositivos de NSX-T.
Para obtener más información sobre RFC 5424, consulte https://tools.ietf.org/html/rfc5424. Para obtener más información sobre RFC 3164, consulte https://tools.ietf.org/html/rfc3164.
RFC 5424 define el siguiente formato para los mensajes de registro:
<facility * 8 + severity> version UTC-TZ hostname APP-NAME procid MSGID [structured-data] msg
Un mensaje de registro de ejemplo:
<187>1 2016-03-15T22:53:00.114Z nsx-manager NSX - SYSTEM [nsx@6876 comp="nsx-manager"
errorCode="MP4039" subcomp="manager"] Connection verification failed for broker '10.160.108.196'.
Marking broker unhealthy.
VMware, Inc. 29
Cada mensaje contiene información de componentes (comp) y subcomponentes (subcomp) para ayudar a identificar el origen del mensaje.
NSX-T genera registros regulares (instalaciones local6, que tienen un valor numérico de 22) y registros de auditoría (instalaciones local7, que tienen un valor numérico de 23). Todas las llamadas de API activan un registro de auditoría.
Un registro de auditoría asociado con una llamada de API contiene la siguiente información:
n Un parámetro de ID de entidad entId para identificar el objeto de la API.
n Un parámetro de ID de solicitud req-id para identificar una llamada de API concreta.
n Un parámetro de ID de solicitud externa ereqId si la llamada de API contiene el encabezado X-NSX-EREQID:<string>.
n Un parámetro de usuario externo euser si la llamada de API contiene el encabezado X-NSX-EUSER:<string>.
El formato RFC 5424 define los siguientes niveles de gravedad:
Nivel de gravedad Descripción
0 Emergencia: el sistema no se puede utilizar
1 Alerta: se debe realizar una acción inmediatamente
2 Gravedad: condiciones graves
3 Error: condiciones de error
4 Advertencia: condiciones de advertencia
5 Notificación: indica una condición normal, pero importante
6 Informativo: mensajes informativos
7 Depuración: mensajes de nivel de depuración
Todos los registros con un nivel de gravedad de emergencia, alerta, gravedad o error contienen un código de error único en la parte de datos estructurados del mensaje de registro. El código de error está compuesto por una cadena y un número decimal. La cadena representa un módulo específico.
El campo MSGID identifica el tipo de mensaje. Para ver una lista de los identificadores de mensaje, consulte Identificadores de mensajes de registro.
Configurar registros remotosPuede configurar dispositivos e hipervisores NSX-T para enviar mensajes de registro a un servidor de registro remoto.
El registro remoto es compatible con NSX Manager, NSX Controller, NSX Edge y los hipervisores. Es necesario configurar el registro remoto en cada nodo de forma individual.
En un host de KVM, el paquete de instalación de NSX-T configura automáticamente el daemon rsyslog al colocar los archivos de configuración en el directorio /etc/rsyslog.d.
Guía de solución de problemas de NSX-T
VMware, Inc. 30
Requisitos previos
n Configure un servidor de registro para recibir los registros.
Procedimiento
1 Para configurar el registro remoto en un dispositivo de NSX-T:
a Ejecute el siguiente comando para configurar un servidor de registro y los tipos de mensajes que se pueden enviar a dicho servidor. Varios recursos o ID de mensajes pueden especificarse en una lista separada por comas, sin espacios.
set logging-server <hostname-or-ip-address[:port]> proto <proto> level <level> [facility
<facility>] [messageid <messageid>] [certificate <filename>] [structured-data <structured-
data>]
Para obtener más información sobre este comando, consulte la referencia de la CLI de NSX-T. Puede ejecutar el comando varias veces para agregar varias configuraciones de servidores de registro. Por ejemplo:
nsx> set logging-server 192.168.110.60 proto udp level info facility syslog messageid
SYSTEM,FABRIC
nsx> set logging-server 192.168.110.60 proto udp level info facility auth,user
b Puede ver la configuración de registro con el comando get logging-server. Por ejemplo,
nsx> get logging-servers
192.168.110.60 proto udp level info facility syslog messageid SYSTEM,FABRIC
192.168.110.60 proto udp level info facility auth,user
2 Para configurar el registro remoto en un host ESXi:
a Ejecute los siguientes comandos para configurar syslog y enviar un mensaje de prueba:
esxcli network firewall ruleset set -r syslog -e true
esxcli system syslog config set --loghost=udp://<log server IP>:<port>
esxcli system syslog reload
esxcli system syslog mark -s "This is a test message"
b Puede ejecutar el siguiente comando para ver la configuración:
esxcli system syslog config get
Guía de solución de problemas de NSX-T
VMware, Inc. 31
3 Para configurar el registro remoto en un host de KVM:
a Edite el archivo /etc/rsyslog.d/10-vmware-remote-logging.conf para su entorno.
b Agregue la siguiente línea al archivo:
*.* @<ip>:514;RFC5424fmt
c Ejecute el siguiente comando:
service rsyslog restart
Identificadores de mensajes de registroEn un mensaje de registro, el campo de identificador de mensaje identifica el tipo de mensaje. Puede usar el parámetro messageid en el comando set logging-server para filtrar los mensajes de registro que se envían a un servidor de registro.
Tabla 5-1. Identificadores de mensajes de registro
identificador de mensaje Ejemplos
FABRIC Nodo de host
Preparación del host
Nodo de Edge
Zona de transporte
Nodo de transporte
Perfiles de vínculo de carga
Perfiles de clúster
Clúster de Edge
Endpoints y clústeres de puente
SWITCHING Conmutador lógico
Puertos del conmutador lógico
Perfiles de conmutación
Funciones de seguridad del conmutador
ROUTING Enrutador lógico
Puertos del enrutador lógico
Enrutamiento estático
Enrutamiento dinámico
NAT
FIREWALL Reglas de firewall
Secciones de reglas de firewall
FIREWALL-PKTLOG Registros de conexión de firewall
Registros de paquete de firewall
Guía de solución de problemas de NSX-T
VMware, Inc. 32
Tabla 5-1. Identificadores de mensajes de registro (continuación)
identificador de mensaje Ejemplos
GROUPING Conjuntos de direcciones IP
Conjuntos de direcciones MAC
grupos NSGroup
servicios NSService
Grupos de NSService
Grupo de VNI
Grupo de direcciones IP
DHCP Retransmisión DHCP
SYSTEM Administración de dispositivos (syslog remoto, ntp, etc.)
Administración de clústeres
Administración de confianza
Licencias
Usuarios y funciones
Administración de tareas
Instalar (NSX Manager, NSX Controller)
Actualizar (actualizaciones de paquetes de hosts, NSX Manager, NSX Controller y NSX Edge)
Realización
Etiquetas
MONITORING SNMP
Conexión de puertos
Traceflow
- El resto de los mensajes de registro
Solucionar problemas de syslogSi el servidor de registros remoto no recibe registros, realice los siguientes pasos.
n Compruebe la dirección IP del servidor de registros remoto.
n Verifique que la configuración del parámetro level sea correcta.
n Verifique que la configuración del parámetro facility sea correcta.
n Si el protocolo es TLS, establézcalo como UDP para determinar si hay un error de coincidencia de certificado.
n Si el protocolo es TLS, compruebe que el puerto 6514 esté abierto en ambos extremos.
n Quite el filtro de identificadores de mensajes y compruebe si el servidor recibe registros.
n Reinicie el servicio rsyslog con el comando restart service rsyslogd.
Guía de solución de problemas de NSX-T
VMware, Inc. 33
Un archivo de configuración de rsyslog de muestra (/etc/rsyslog.conf):
### rsyslog config file. Customized by VMware.
### Do not edit this file by hand. Use the API to make changes.
$PreserveFQDN on
$ModLoad imklog
$ModLoad immark
module(load="imuxsock" sysSock.useSpecialParser="off")
$RepeatedMsgReduction on
$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format
$IncludeConfig /etc/rsyslog.d/*.conf
$template RFC5424fmt,"<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID%
%STRUCTURED-DATA% %msg%\n"
$WorkDirectory /var/spool/rsyslog
$ModLoad imudp
$UDPServerAddress 127.0.0.1
$UDPServerRun 514
$PrivDropToUser syslog
$ActionQueueType LinkedList # nsx exporter: e7347687-8be7-4519-a8e1-73c5192c9b43
*.info @1.2.3.4:514;RFC5424fmt # nsx exporter: e7347687-8be7-4519-a8e1-73c5192c9b43
Comprobación de serviciosLos servicios que dejan de ejecutarse o no logran iniciarse pueden causar problemas. Es importante asegurarse de que todos los servicios se estén ejecutando con normalidad.
Para comprobar el estado del servicio NSX Manager:
nsxmgr> get services
Service name: cm-inventory
Service state: stopped
Service name: http
Service state: stopped
Session timeout: 1800
Connection timeout: 30
Redirect host: (not configured)
Service name: install-upgrade
Service state: stopped
Enabled: True
Service name: liagent
Service state: stopped
Service name: manager
Service state: stopped
Logging level: info
Guía de solución de problemas de NSX-T
VMware, Inc. 34
Service name: mgmt-plane-bus
Service state: running
Service name: node-mgmt
Service state: running
Service name: nsx-message-bus
Service state: running
Service name: nsx-upgrade-agent
Service state: running
Service name: ntp
Service state: running
Service name: search
Service state: stopped
Service name: snmp
Service state: stopped
Start on boot: False
Service name: ssh
Service state: running
Start on boot: True
Service name: syslog
Service state: running
En el ejemplo anterior, se interrumpe el servicio http. Puede iniciar el servicio HTTP con el siguiente comando:
nsxmgr> start service http
Servicio SSHSi el servicio SSH no se habilitó al implementar el dispositivo, puede iniciar sesión en él como administrador y habilitarlo mediante el siguiente comando:
start service ssh
Puede configurar que SSH se inicie cuando se inicia el host con el siguiente comando:
set service ssh start-on-boot
Para habilitar el inicio de sesión en SSH raíz, puede iniciar sesión en el dispositivo como raíz, editar el archivo /etc/ssh/sshd_config y reemplazar la siguiente línea:
PermitRootLogin prohibit-password
Guía de solución de problemas de NSX-T
VMware, Inc. 35
Opcionalmente, si desea habilitar el servicio SSH y el acceso de SSH raíz, apague el dispositivo y modifique sus propiedades de vApp.
Con lo siguiente:
PermitRootLogin yes
A continuación, reinicie el servidor sshd con el siguiente comando:
/etc/init.d/ssh restart
Recopilar paquetes de soporteEs posible recopilar paquetes de soporte de los clústeres y nodos de tejido y descargarlos en la máquina o cargarlos a un servidor de archivos.
Si decide descargar los paquetes en la máquina, obtendrá un único archivo de almacenamiento compuesto por un archivo de manifiesto y paquetes de soporte para cada nodo. Si opta por cargar los paquetes a un servidor de archivos, el archivo manifiesto y los paquetes individuales se cargan al servidor de archivos de forma independiente.
NSX Cloud Note Si desea recopilar el paquete de soporte para CSM, inicie sesión en CSM, vaya a Sistema > Utilidades > Paquete de soporte y haga clic en Descargar. El paquete de soporte para PCG está disponible en NSX Manager siguiendo estas instrucciones. El paquete de soporte para PCG también contiene registros para todas las máquinas virtuales de carga de trabajo.
Procedimiento
1 En un explorador, inicie sesión con privilegios de administrador en NSX Manager en https://nsx-manager-ip-address.
2 Seleccione Sistema > Utilidades en el panel de navegación.
3 Haga clic en la pestaña Paquete de soporte.
4 Seleccione los nodos de destino.
Los tipos de nodos disponibles son los nodos de administración, los nodos de controladores, las instancias de Edge, los hosts y las puertas de enlace de nube pública.
5 (opcional) Especifique el número de días de antigüedad del registro para excluir aquellos que sean más antiguos que el número especificado.
6 (opcional) Alterne el conmutador que indica si incluir o excluir archivos básicos y registros de auditoría.
Nota Los archivos básicos y registros de auditoría incluyen información confidencial, como contraseñas o claves cifradas.
7 (opcional) Seleccione una casilla de verificación para cargar los paquetes a un servidor de archivos.
Guía de solución de problemas de NSX-T
VMware, Inc. 36
8 Haga clic en Iniciar recopilación de paquetes para comenzar a recopilar paquetes de soporte.
En función del número de registros, cada nodo puede tardar varios minutos.
9 Supervise el estado del procedimiento de recopilación.
El campo del estado muestra el porcentaje de nodos que completaron la recopilación de paquetes de soporte.
10 Haga clic en Descargar para descargar el paquete si la opción para enviarlo a un servidor de archivos no está configurada.
Guía de solución de problemas de NSX-T
VMware, Inc. 37
Otros escenarios de solución de problemas 6Esta sección describe cómo solucionar problemas en diversos escenarios de error.
Este capítulo incluye los siguientes temas:
n Error al agregar o eliminar un nodo de transporte
n El nodo de transporte tarda unos 5 minutos en conectarse a otro controlador
n La máquina virtual de NSX Manager está degradada
n Se agota el tiempo de espera para que el agente NSX se comunique con NSX Manager
n Error al agregar un host ESXi
n Estado incorrecto de NSX Controller
n No se puede tener acceso a direcciones IP de administración en máquinas virtuales de KVM con IPFIX habilitado
Error al agregar o eliminar un nodo de transporteNo se puede eliminar o agregar un nodo de transporte.
Problema
Se produce el error en la siguiente situación:
1 Un host ESXi es un nodo de tejido y un nodo de transporte.
2 El host se elimina como nodo de transporte. Sin embargo, se produce un error en la eliminación del nodo de transporte. El estado del nodo de transporte es Huérfano.
3 El host se elimina inmediatamente como un nodo de tejido.
4 El host se agrega nuevamente como nodo de tejido.
5 El host se agrega como nodo de transporte con una nueva zona de transporte y conmutador. Este paso da como resultado el error Error/parcialmente correcto.
VMware, Inc. 38
Causa
En el paso 2, si espera unos minutos, la eliminación del nodo de transporte se realizará correctamente, porque NSX Manager volverá a intentarla. Cuando se elimina el nodo de tejido inmediatamente, NSX Manager no puede volver a intentarlo, debido a que el host se quitó de NSX-T. Esto da como resultado una limpieza incompleta del host, con la configuración del conmutador aún presente, lo que hace que el paso 5 genere error.
Solución
1 Elimine todos los vmknics de vCenter Server en el host que está conectado al conmutador de NSX-T.
2 Obtenga el nombre del conmutador mediante el comando de la CLI esxcfg-vswitch -l. Por ejemplo:
esxcfg-vswitch -l
Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch0 1536 4 128 1500 vmnic0
PortGroup Name VLAN ID Used Ports Uplinks
VM Network 0 0 vmnic0
Management Network 0 1 vmnic0
Switch Name Num Ports Used Ports Uplinks
nsxvswitch 1536 4
3 Elimine el nombre del conmutador mediante el comando de la CLI esxcfg-vswitch -d <switch-name> --dvswitch Por ejemplo:
esxcfg-vswitch -d nsxvswitch --dvswitch
El nodo de transporte tarda unos 5 minutos en conectarse a otro controladorCuando un controlador conectado de un nodo de transporte de ESXi deja de funcionar, el nodo de transporte tarda aproximadamente cinco minutos en conectarse a otro controlador.
Problema
Normalmente, un nodo de transporte de ESXi está conectado a un controlador específico en un clúster de controladores. Puede encontrar el controlador conectado con el comando de la CLI get controllers. Si el controlador conectado deja de funcionar, el nodo de transporte tarda aproximadamente cinco minutos en conectarse a otro controlador.
Causa
El nodo de transporte intenta volver a conectarse durante un tiempo al controlador que está inactivo antes de desistir y conectarse a otro controlador. Todo el proceso tarda aproximadamente cinco minutos. Este es el comportamiento esperado.
Guía de solución de problemas de NSX-T
VMware, Inc. 39
La máquina virtual de NSX Manager está degradadaLa instancia de NSX Manager que está implementada en un host de KVM devuelve un error al ejecutar comandos de la CLI, como get service y get interface.
Problema
El comando get service de la CLI devuelve un error. Por ejemplo,
nsx-manager-1> get service
% An error occurred while processing the service command
Otros comandos de la CLI también podrían devolver un error. El comando get support-bundle indica que el directorio /tmp pasó a ser de solo lectura. Por ejemplo,
nsx-manager-1> get support-bundle file failed-to-get-service.tgz
% An error occurred while retrieving the support bundle: [Errno 30] Read-only file system: '/tmp/
tmpHzXF1u'
El registro /var/log/mensajes-<timestamp> tiene un mensaje como el siguiente:
Nov 17 07:26:48 no kernel: NMI watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [qemu-kvm:4386]
Causa
Uno o varios sistemas de archivos en el dispositivo de NSX Manager estaban dañados. Algunas de las posibles causas se documentan en https://access.redhat.com/solutions/22621.
Para solucionar el problema, puede reparar los sistemas de archivos dañados o realizar una restauración desde una copia de seguridad.
Solución
1 Opción 1: Reparar los sistemas de archivos dañados. Los siguientes pasos están destinados específicamente a la instancia de NSX Manager que se ejecuta en un host de KVM.
a Ejecute el comando virsh destroy para detener la máquina virtual de NSX Manager.
b Ejecute el comando virt-rescue en modo de escritura en la imagen qcow2. Por ejemplo,
virt-rescue --rw -a nsx-unified-appliance-2.0.0.0.0.6522097.phadniss-p0-DK-to-DGo-on-rhel-
prod_nsx_manager_1.qcow2
c En la línea de comandos virt-rescue, ejecute el comando e2fsck para corregir el sistema de archivos tmp. Por ejemplo,
<rescue> e2fsck /dev/nsx/tmp
d Si es necesario, ejecute nuevamente e2fsck /dev/nsx/tmp hasta que no existan más errores.
e Reinicie NSX Manager con virsh start.
Guía de solución de problemas de NSX-T
VMware, Inc. 40
2 Opción 2: Realizar una restauración desde una copia de seguridad.
Para obtener instrucciones, consulte la Guía de administración de NSX-T.
Se agota el tiempo de espera para que el agente NSX se comunique con NSX ManagerEn un entorno de gran escala con muchos nodos de transporte y máquinas virtuales en hosts ESXi, es posible que se agote el tiempo de espera para que los agentes NSX, que se ejecutan en hosts ESXi, se comuniquen con NSX Manager.
Problema
Algunas operaciones fallan, como cuando un vnic de máquina virtual intenta conectarse a un conmutador lógico. El archivo /var/run/log/nsx-opsagent.log tiene mensajes como el siguiente:
level="ERROR" errorCode="MPA41542"] [MP_AddVnicAttachment] RPC call [0e316296-13-14] to NSX
management plane timout
2017-05-15T05:32:13Z nsxa: [nsx@6876 comp="nsx-esx" subcomp="NSXA[VifHandlerThread:-2282640]"
tid="1000017079" level="ERROR" errorCode="MPA42003"] [DoMpVifAttachRpc] MP_AddVnicAttachment()
failed: RPC call to NSX management plane timout
Causa
En un entorno a gran escala, algunas operaciones podrían tardar más de lo habitual y presentar error debido a que se superan los valores de tiempo de espera predeterminados.
Solución
1 Aumente el valor de tiempo de espera del agente NSX.
a En el host ESXi, detenga el agente NSX opsAgent con el siguiente comando:
/etc/init.d/nsx-opsagent stop
b Edite el archivo /etc/vmware/nsx-opsagent/nsxa.json y cambie el valor de vifOperationTimeout de 25 a, por ejemplo, 55.
"mp" : {
/* timeout for VIF operation */
"vifOperationTimeout" : 25,
Nota Este valor de tiempo de espera debe ser menor que el valor de tiempo de espera de hostd que estableció en el paso 2.
c Inicie el agente NSX opsAgent con el siguiente comando:
/etc/init.d/nsx-opsagent start
Guía de solución de problemas de NSX-T
VMware, Inc. 41
2 Aumente el valor de tiempo de espera de hostd.
a En el host ESXi, detenga al agente de hostd con el siguiente comando:
/etc/init.d/hostd stop
b Edite el archivo /etc/vmware/hostd/config.xml. En <opaqueNetwork>, quite el comentario de la entrada de <taskTimeout> y cambie el valor de 30 a, por ejemplo, 60.
<opaqueNetwork>
<!-- maximum message size allowed in opaque network manager IPC, in bytes. -->
<!-- <maxMsgSize> 65536 </maxMsgSize> -->
<!-- maximum wait time for opaque network response -->
<!-- <taskTimeout> 30 </taskTimeout> -->
c Inicie al agente de hostd con el siguiente comando:
/etc/init.d/hostd start
Error al agregar un host ESXiNo es posible agregar un host ESXi al tejido de NSX-T.
Problema
En la GUI de NSX Manager, si se agrega un host ESXi, se genera el error A la ruta de acceso de archivo... la reclaman varios VIN sin superposición". El archivo de registro muestra mensajes como el siguiente:
Failed to install software on host. Failed to install software on host. 10.172.120.60 :
java.rmi.RemoteException: [DependencyError] File path of '/usr/lib/vmware/vmkmod/nsx-vsip' is claimed
by multiple non-overlay VIBs
Causa
Algunos VIB desde una instalación anterior todavía están en el host, probablemente debido a que no se produjo una desinstalación completa.
Solución
1 Desde el mensaje de error, obtenga los nombres de VIB que son la causa del error.
2 Utilice los comandos de ESXi para desinstalar los VIB.
Estado incorrecto de NSX ControllerAlgunos controladores en un clúster de NSX Controller informan un estado incorrecto para uno de los controladores.
Guía de solución de problemas de NSX-T
VMware, Inc. 42
Problema
Después de que un controlador se enciende y se apaga varias veces, los otros controladores informan que está inactivo cuando está en funcionamiento.
Causa
A veces, cuando un controlador se enciende y se apaga, se produce un error interno que involucra al módulo de ZooKeeper, lo que genera un error de comunicación entre este controlador y los otros controladores del clúster.
Solución
u Elimine del clúster el nodo del controlador que se informa que está inactivo, elimine la configuración del clúster desde el nodo y vuelva a unir el nodo al clúster. Para obtener más información, consulte la sección "Reemplazar un miembro del clúster de NSX Controller" en la Guía de administración de NSX-T.
No se puede tener acceso a direcciones IP de administración en máquinas virtuales de KVM con IPFIX habilitadoCuando IPFIX está habilitado en varias máquinas virtuales en un host de KVM y la frecuencia de muestreo es de 100 %, no se puede tener acceso de forma intermitente a las direcciones IP de administración de algunas de las máquinas virtuales.
Problema
Cuando habilita IPFIX para varias máquinas virtuales en el mismo host y establece la frecuencia de muestreo en 100 %, puede haber una gran cantidad de tráfico IPFIX. Esto puede afectar al tráfico de administración, lo que hace que sea imposible acceder de forma intermitente a las direcciones IP de administración, incluso si el tráfico de producción y el de administración pasan por OVS diferentes.
Causa
La carga de trabajo es demasiado estresante para el host y las máquinas virtuales.
Solución
u Reduzca la carga en el host mediante la disminución de la cantidad de máquinas virtuales con IPFIX habilitado o la reducción de la frecuencia de muestreo.
Guía de solución de problemas de NSX-T
VMware, Inc. 43