cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

vCenter installed on IP and not FQDN

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

(1) Solution

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.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)

View solution in original post

(11) Replies
mfranz
By Level 17 Champion
Level 17 Champion

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

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.

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.

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.

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

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.

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

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.

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

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

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.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)