The last word that I got from our Product Manager was:
"The ESX server’s flow support is in beta and the results are sporadic. Our next steps are to wait till ESX officially releases flow support, and then test with NTA again." Ref. (SolarWinds NTA PM - March 27, 2008 )
When our lab manager was testing this, I don't remember him running into your scenario. All I remember was that the actual NetFlow format coming from the ESX was not consistent. Maybe VMWare has released a newer version since then and once you get past this issue, you can be up and running. We would really like to see if you can get it working.
Ok, here is what I'd do to get around your scenario:
1. Stop the Orion NPM service
2. In the NetPerfMon database, open the Nodes table and modify the row with an IP_Address in your example of '10.10.10.1' to '10.10.10.2'. Also write down the NodeID of this row, in case you need it for step 5.
3. Start or restart your NTA service.
4. Open your NTA web console and look to see now if your receiving the flow.
5. If not receiving, but are now getting an alert indicating that the flow is coming on another interface index, open the Interfaces table in the database and look for the row (or rows) containing the NodeID that you wrote down in step 2. Change one of those rows InterfaceIndex to the index specified in the alert.
6. Restart your Orion NPM service.
Hopefully that works for you. Let us know your results.
first of all thanks for your answer.
Basically I used the described approach and it works. Some things are not really, so VMWare is reporting flows from interface which are not really used by any VM, and as it can not be monitored via SNMP the status of the interfaces is "unknown".
As the databases needs to be manually touched it is not really a scalable approach (updates, changes in the VM layout ...), therefore we decided to run a test for one week and then check whether the Netflow data reported by the ESX server is usable.