VMware Cloud Community
srodenburg
Expert
Expert

Insane high OSI count, despite actual # OSI's being well below 100

Hello,

I just implemented LogInsight 3.6 at a customer (100 OSI License). Done that xxxxx times. This time we noticed something really wierd. The customer has 4 Horizon View 6.2.2 PODs with in total 10 Connection Brokers, 4 vCenters and 52 ESX Servers. So total ISO count is 66 if my math is correct.

LogInsights counts thousands of OSI's :smileyconfused:

(resulting in the license-violation thingy screaming like it's butt is on fire...)

At first glance, we see that VDI VM's get counted too (which explains the bizarre high count). We see that the "source" is a connection broker, but the hostname in that same entry is often a VDI Desktop vm.

We have not installed any View Content packs etc. by the way.

I thought this kind behaviour was something of the past. I know LogInsight will keep working despite the violation but ehrm, is this normal?

Kind regards,

Steven Rodenburg

Reply
0 Kudos
2 Replies
srodenburg
Expert
Expert

Anyone ?

Reply
0 Kudos
sflanders
Commander
Commander

Yes, this is normal. LI licenses based on the hostname field (the originator of the message) not the source field (the last hop before reaching the LI server). The reason for this is because the source may be a syslog aggregator, an external LB or even a NAT. Per the syslog RFC, the hostname field is the originator of the message. In the case of View, unfortunately, the logs put the VM in the hostname field even though they did not originate the message. A potential solution to this problem is to have the VM be the source and the View component be the hostname, but at the end of the day this is a View logging bug. I would suggest opening this on the View forum, but I will will escalate this on my end as well.

Hope this helps! === If you find this information useful, please award points for "correct" or "helpful". ===
Reply
0 Kudos