I'm biased, but I'll say that it can indeed do the same functions as VIN. It does so with the flows as you've found in the blog below, but it also does application discovery based on metadata (names, tags) from the vCenter/AWS inventory and pulling apps down from ServiceNowCMDB: Application Discovery
How would you say that it does it with flows? Do you have any link to doco on what and how it does it.
Whats the impact on the VM? VIN was very light/no touch and provided allot of usefully info. Its replacement the the Discovery Management Pack, was,..... well not usefull.
Is vRNI, something that we can just let run for a week and based on PG flow it will map out the traffic, figure out the type and the potential dependencies. Or will we need to connect to our F5s, switched ect to get useful data?
I did see that it can collect info from Service Now and other services, but what is the point of vRNI if I already have the dependencies mapped out?
The security planner (donut) will show all incoming and outgoing connections. The idea is to discover applications using the tags, naming convention, and CMDB sources. Considering these sources are almost always incomplete (it's typically manual work to update the CMDB), vRNI can be used to complete and validate the discovery. If you group by VM or application, and look at the connections, anything that you've missed from the CMDB, tags, or naming convention discovery, will be shown - and you can update the CMDB from it.
More info in the docs: Analyzing the Application
There is no impact on the VM, as the data that vRNI ingests, comes from vSphere and the physical infra. If your infra is primarily virtual, no need to include your physical infra to do app discovery and flow analysis. However, for day 2 operations; adding the physical infra is critical.
Hope that helps,