Hi all,
I encountered a strange and may be a bug in FNMS vCenter audit.
I have a few vCenters installed on ip and not on FQDN as is advised by VmWare.
Back ground info. Seems that in the past VmWare had a bug where was not possible to install FQDN that finished on 1, like vcenter.acme.com1 which in my case that was the issue. The cloud team installed the vCenter after ip, which give us issues, because on audit we receive the following values:
Scope= 10.10.10.10
MachineName=10
From this point every thing go sideways, in inventory a machine with name 10 is created with domain 10.10.10
But in the ESXi ndi that are created together with the vCenter the host name is 10.10.10.10
So the application will not know where to link the host with the vCenter
And I don't know how to solve this issue, because I have vCenters with wrong names and hosts that are linked to a vCenter that do not exists.
In mean time the bug is fixes on VmWare but seems that to install again the vCenter after FQDN is a no go from the customer side.
Maybe some one have some idea how to solve this.
Regards,
Adrian Ritz
Aug 21, 2019 06:36 AM
For reference, the fix in the 2020 R1 release referred to in this thread is Issue Number IOJ-2082558 (First octet of IP address used as device name for vCenter servers that have an IP address as their primary network identifier) in the Resolved Issues List.
Jul 15, 2020 03:29 AM
Hi Adrian,
I've seen FNMS importing ILMT data for machines named like their IPs. An the same happened, FNMS took the first digits as name and everything after the first point as domain.
In your case, I am not sure how the vCenter itself is an issue, because I would think that vCenters aren't linked to any othe rmachines. However, I understand the problem with those ESXi hosts.
If you consider your own workaround, you could have a look into the ManageSoft Reader and see how it handles the FQDN there. You could try and implement a case checking the computer name (replacing all points) for being numeric and in this case using the whole string as name. An example:
CASE WHEN ISNUMERIC(REPLACE(Computername, '.', '')) = 1 THEN <IP as ComputerName> ELSE <Original logic goes here> END AS ComputerName
For matching VMs to Hosts, you might still have to check how the reader does that and see if you have to adapt.
Best regards,
Markward
Aug 21, 2019 07:12 AM - edited Aug 21, 2019 07:13 AM
Hi Markward,
I was thinking of something like:
Rename the inventory in FNMS WebUI from 10 to 10.10.10.10
And whit the next import when a new inventory 10 will be created to set as ignored, in this way I think the esx hosts will be linked to the right vCenter.
I need to test this, as I don't know how the system will react.
Aug 21, 2019 07:29 AM
I am not completely sure if this will work. ComplianceComputerConnection makes kind of a permanent connection between you inventory (ComplianceComputerID ) and the ImportedComputer (ExternalID & ComplianceConnectionID). So I guess there is a good chance that the compliance import will update the very inventory you just changed and not create a new one.
Aug 21, 2019 07:42 AM
Hi,
I opened a support case with Flexera, as it seems to be a defect in the way the vCenter inventory is done.
Let's see what the support will say about this topic.
Aug 29, 2019 02:28 AM
Hi,
Just a quick one, I experienced a similar issue,
You can verify the data that is collected, try using the ESX Query tool
you can find it here: https://community.flexera.com/t5/FlexNet-Manager-Knowledge-Base/Flexera-Labs-Additional-Inventory-Tools-for-FlexNet-Manager/ta-p/5377
Aug 29, 2019 02:39 AM
Hi,
I had tried also with the ESXtool and receive the same result, I checked the .ndi file and the value of first digits are there.
Aug 29, 2019 02:45 AM
Hi @adrian_ritz1 \ all,
I am facing the same issue on my environment. Did you receive any solution for the case you have raised.
If yes, kindly share the same so that it would be helpful for me aswell.
Thank you
Sasi
Jul 09, 2020 08:43 AM
Hi @sasikumar_r ,
Seems that new version of FNMS 2020 R1 is addressing this issue. If till now when you run the vCenter inventory you have the scope = 10 instead of 10.10.10.10, now with the new version you have scope = 10-10-10-10, but if you check the ndi files for associated ESX, you will have the vCenter name as =10.10.10.10, as it's fresh upgrade on test system, only today I managed to run the vCenter audit, let's see in the next days if the issue is solved and vCenter will be correctly associated with the esx.
As a workaround I did the following, delete the original 10 vCenter, you can see domain as the rest of the ip address, 10.10.10
Manually disable the upload of the beacon which is running the vCenter inventory, modify the .ndi file that is for vCenter and put in the scope the entire IP address, enable back the scheduled tasks for upload
And make sure to move impacted vCenter is a separate target, and run it only when you want to update something, like once per month. If you run it normally, a second device with name 10 will be created and your vCenter inventory will be duplicated, also consuming license and stuff.
Jul 09, 2020 09:56 AM
Seems that FNMS 2020 R1 fixed this issue, now the vCenters are correctly identified after IP address, also the ESXi are correctly linked to the vCenter
Jul 10, 2020 08:31 AM
Hi @adrian_ritz1 ,
Thank you so much for the info! I will try upgrade the platform to see if the issue fix in my case too.
Sasi
Jul 10, 2020 09:50 AM
For reference, the fix in the 2020 R1 release referred to in this thread is Issue Number IOJ-2082558 (First octet of IP address used as device name for vCenter servers that have an IP address as their primary network identifier) in the Resolved Issues List.
Jul 15, 2020 03:29 AM