Log Insight VIDM: Unexpected Redirections

In my last post, I talked about the “Redirect URL Host” option that is part of VIDM integration. In this post, I would like to discuss configurations that may result in unexpected redirections and what you can do about it. Read on to learn more!

Standalone Instance

As you may recall in my last post, with standalone Log Insight instances, the node’s IP address will always be used. It is unlikely that you will be accessing the Log Insight UI via an IP and will leverage DNS instead. If you access the UI via a FQDN and authenticate via VIDM then when VIDM redirects back to Log Insight it will redirect you back to the Log Insight IP instead of the FQDN. The implications of this are two-fold:

  1. The URL changes in the address bar
  2. You will need to accept the SSL warning

This is clearly not the best customer experience and can also make changing the IP address of the instance (should be very rare) harder. To overcome this behavior, you should configure the Integrated Load Balancer and ensure you set a FQDN. Then when you integrate with VIDM you will have the ability to use a FQDN instead of an IP.
For non-production environments, you could also try the following changes:

WARNING: This is NOT officially supported by VMware. Proceed at your own risk.

  1. Disable VIDM integration — note this will wipe all configuration inputs, they will need to all be manually entered in a later step
  2. Go to /internal/config and find the standalone service-group:
    <distributed overwrite-children="true">
       <daemon port="16520" token="97c70439-ee10-4d9f-b447-600b837b3fbe">
       <service-group name="standalone" />

    and add a host option to the daemon XML with the FQDN from which you access the UI

    <distributed overwrite-children="true">
       <daemon host="loginsight.example.com" port="16520" token="97c70439-ee10-4d9f-b447-600b837b3fbe">
       <service-group name="standalone" />
  3. Hit save
  4. Go back to VIDM integration and configure it again

Note: The above configuration change may be lost during upgrades.

Now the “Redirect URL Host” option will match the URL you enter into your browser and redirection will work as expected.

Note: If you check /internal/config you may notice a vidm-oauth-client-redirect-url option, changing this will break your VIDM configuration so leave it alone.

Multiple ILB VIPs

If you have configured multiple ILB VIPs on your Log Insight instance then you may run into the same issue as the standalone instance scenario above. In short, you may access the UI on VIP 1, but VIDM redirection might be set on VIP 2. This means the URL and possibly a SSL warning will occur. The solution is to ensure that the FQDN used to access the UI is the same FQDN used to configure VIDM integration. In this scenario, you can make all necessary changes on supported UI pages so no need to worry about supported configurations.

© 2017, Steve Flanders. All rights reserved.

11 comments on “Log Insight VIDM: Unexpected Redirections

kondrich says:

Thank you Steve!
I finally managed to reconfigure our standalone LI instance using Integrated Load Balancer and VIDM. Now everything is working fine.
I encountered two issues:
When creating the new vIP, it seems that you also have to use use an unused FQDN as well.
Initially we were using vcenterlog.dom.tld -> or LI appliance.
Then we changed DNS record for vcenterlog.dom.tld to point to the new vIP So the standalone node is still using but has no FQDN pointing on it. However, it was not possible to create a new vIP in LI using the old, reused FQDN and the new vIP. It always told me that the IP could not be resolved (in fact, it could be resolved from any other machine and even an Log Insight appliance reboot did not help).
So we changed DNS back to vcenterlog.dom.tld -> and created a new DNS record vcenterli.dom.tld pointing at the new vIP Now, I could successfully configure a new vIP within LI using and vcenterli.dom.tld.
The second issue is that LI vSphere integration still configures the hosts with the old FQDN instead of the new load balancer FQDN. It’s still udp://vcenterlog.dom.tld:514 in vCenter host configuration even after unconfigure/configure in LI.
When I manually set the new load balanced FQDN in vCenter Web Client for a host, it appears as Configured “0” instead of “Yes (UDP)” in LI.
Is there any way to get the new load balanced FQDN into host configuration via LI vSphere integration or do I have to manually set it for each host and ignore that LI does not display them as configured?

vSphere integration should use the FQDN you specified during configuration — is this not working for you?

kondrich says:

No, I even completely removed vCenter integration from LI.
When re-adding my vCenter server, it initially offers me “Target vcenterli.dom.tld”.
When I activate “Configure ESXi hosts to send logs to Log Insight” it switches to “Target Log Insight Master” and stays there even when I uncheck the ESXi configuration.

Hmm — this seems wrong. Can you file a SR and send me the number? What version of LI?

kondrich says:

It’s current version 4.5.0-5654101.
However, a SR is not necessary anymore: I tried it again and realized that I removed vCenter Integration by clicking the closing-x in the top-right corner, but I probably did not hit “Save” to really remove it.
Now I also saved the removal, then added it again and it remained on vcenterli.dom.tld. I doublechecked it in vCenter host configuration: udp://vcenterli.dom.tld:514
Everything is fine now. 🙂

Great to hear! I was surprised to hear this may not be working.

Aaron Masser says:

I tried to do this on a new Insight 4.5 standalone install. When i got back to configure identity manager, i can see my new FQDN under the redirect URL, but when i click save i get this.
” Save failed: {key”:”com.vmware.loginsight.config.Workerconfigurationprovider.setconfigfailed params. masterfqdnunresolvableexecption: loginsightvip.domain.local cannot be resolved and there is not a master ip buffer

Aaron Masser says:

I should have also mentioned, i can ping my FQDN from the loginsight appliance.

Weird — did you edit /etc/hosts on the VA or did you configure the FQDN on your DNS servers?

Chad says:

Awesome, thanks for this…

I had seen screenshots with the FQDN and couldn’t figure out why my install was missing the option.

Worked like a charm, now if I could get vROps to do the same thing when opening from vCenter 6.7. It currently uses the IP.

Happy to help!

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top