Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

VMware vRealize Network Insight System Defined Events (55978)

Last Updated: 5/8/2020Categories: InformationalTotal Views: 3033Language:
English

1 like this article

Subscribe to get an email
newsletter with new updates

1 people found this helpful Please provide article feedback:

Purpose

Purpose of this article is to share information with regards to the multiple System defined events recorded/collected in VMware vRealize Network Insight.

Resolution

There are events in vRNI which are computed internally based on the data it gathers from different sources. These events are opened and closed based on the data polling that we do.

There are some events which are raised by NSX Manager as well, these are called System Events. There are hundreds of System Event defined in NSX and vRNI collects these events based on their severity.

There are some of the event for which we have specific mapping/name and rest all are mapped to generic.

The specific mapping/name events are below:

1.      NSX Manager to Edge VM communication failure
2.      NSX Edge VM not in active/self state
3.      NSX Edge to NSX Manager heartbeat failed
4.      Host messaging configuration update failed
5.      Host messaging connection re-config failed
6.      Host messaging channel between host and NSX Manager failed to re-establish
7.      Host messaging infrastructure down on host
8.      Distributed firewall update for host vNIC failed to be applied
9.      Distributed firewall update failed to be applied to host
10.  Distributed firewall configuration update failed
11.  SpoofGuard configuration update failed
12.  Distributed firewall rule not applied to host vNIC
13.  Distributed firewall container update failed on host
14.  SpoofGuard initial configuration failed

The generically mapped events are:

1.      NSX system event (warning)
2.      Critical NSX System Event

All of the above NSX System Events are shown with the "Event Code", which can be looked into NSX Manager page and also searchable on the internet to get more details around the issue. It's good to tell the event code in case of any conversation with NSX GSS.

For more information regarding how these events were introduced and how the events are closed, please refer to Related Information section

Please Note:

1. The above information is for NSX-v and not NSX-T.
2.  vRNI has not  converted any NSX-T system event to vRNI specific event. All event will come under “NSX-T System  Event”.

Related Information

The reason for specific mapping/name is historical. When vRNI (Arkin) started introducing these events which were collected from NSX Manager, the idea was to show only few of the events which were major pain point at that time. With time, NSX Manager came up with lots of new System Events and still keep adding more with new releases. So we thought of mapping these events into generic name.

The way NSX Manager closes these system events is that there is CLOSE event for some of the events, and not for all. What it means is that, when NSX Manager OPEN the event, there might come a CLOSE event as well for it, but not all the event type has CLOSE event associated. The only way to determine that the OPEN problem (for which the CLOSE doesn't exist) is closed is to wait and see if the NSX Manager has re-send the OPEN event again or not. NSX Manager periodically re-send/re-open the event if the problem still persists. For these kind of System Event (which doesn't have CLOSE event associated), vRNI waits for few hours (2-4 hours) to make sure that the problem is not seen again by NSX Manager and then closes it in vRNI.

For all other events which are computed in vRNI, the opening and closing depends on the data gathered through polling.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
VMware Workstation Pro 12.x へのゲスト OS としての Windows 10 のインストール (2128790)

KB
•
Download and Install VMware Fusion (2014097)

Results 1-3 of 3

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vRealize Network Insight

Related Versions:

Take Our Survey

Support Assistant