/var/log/cloudnet/nsx-ccp.log
[nsx@6876 comp="nsx-controller" level="INFO" subcomp="falcon"] Batching 1 falcon transactions. Remaining #### in the queue.Explanation:
Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.
VMware NSX
A lot of vMotion events may overwhelm the NSX Central Control Plane (CCP).
Tasks are queued for processing by the system component called falcon.
Some tasks are processed one by one, including vMotion, implying delays for the other queued tasks.
If enough delay occurs between the reception of a TEP membership update, its processing and propagation of resulting TEP update, impact may be observed on entities that rely on TEP memberships, such as BFD tunnels and NSX overlay connectivity.
For instance, when a VM is vMotion'ed from ESX host A to ESXi host B, the rest of the NSX network must be updated to know that the VM is now reachable via the TEP of ESX host B.
If the TEP update is delayed, then the VM will be unreachable from the rest of the network until that TEP update is processed and propagated (as GENEVE traffic will be incorrectly sent to the TEP of ESX host A).
BFD tunnels between ESX hosts are also established based on TEP memberships. If enough delay occurs during TEP upgrades, then BFD tunnels may reported down or seen flapping in the NSX UI.
NSX inventory objects exceeding documented maximums (see VMware Configuration Maximums) may exacerbate the issue as they increase the processing time.
This is a known issue impacting VMware NSX.
Workaround:
In a live NSX environment, you can monitor the falcon queue with the following command:
get log-file controller follow | find "Batching 1 falcon transactions.*Remaining"
tail -f /var/log/cloudnet/nsx-ccp.log | grep -E "Batching 1 falcon transactions.*Remaining"