GLPI 10.0.17 does not record the IP of the VMs collected with the ESX task.

[alexmicontini]

Bug reporting acknowledgment

Yes, I read it

Professional support

None

Describe the bug

Hi @g-bougard,

with version 1.12 of the agent and version 10.0.17 of glpi, the agent obtains the IP address and operating system of the virtual machines hosted on the VCenter server, GLPI registers the operating system in the VMs but not the IP address, the field remains empty.

GLPI 10.0.17 is assumed to support the v1.1.36 inventory format scheme. Is there something to configure in GLPI?

LOG GLPI AGENT

GLPI 10.0.17

Greetings

To reproduce

1. I execute the agent
2. I notice that the agent obtains the IP and the operating system.
3. I check GLPI 10.0.17 for the IP of the VMs collected from VCenter and it is not displayed. However, the Operating System is shown.

Expected behavior

Register the IP in GLPI.

Operating system

Linux

GLPI Agent version

v1.12

GLPI version

10.0.17

GLPIInventory plugin or other plugin version

GLPI Inventory v1.4.0

Additional context

No response

[eduardomozart]

If the agent obtains the IP address of the VM you should report it into GLPI bugtracker instead. I believe it will be declined since it seems a feature request instead of a bug report, since I don't think this feature exists on GLPI UI before and it's not available on the GLPI 10.0.18 nightly build, so you would need to implement it on your own if you don't have a TecLib' subscription.

[alexmicontini]

Hi @eduardomozart,

yes, but in the changes brought by version 1.12 of the glpi agent it is indicated that the format is compatible with version 10.0.17 of GLPI.

esx:
Support reporting of ESX virtualmachines ip and operating system. It requires inventory_format schema v1.1.36 on server-side included in GLPI v10.0.17.

It doesn't make much sense to have functionality that you can't take advantage of.

[g-bougard]

Hi @alexmicontini

as said here, the feature also requires an option in GLPI to be enabled.

As you answered here, you have enabled it, so it seems this is maybe a GLPI server problem.

But you're also telling you still run inventory locally in VM or containers. So you may have a concurrency between local inventory and this feature. You must also know remote inventory of vm generated by RemoteInventory task will be considered as local inventory in GLPI. And this is normal are they were made running checks into the OS system itself. This means such kind of inventory will also be concurrent to the feature. I really don't know how concurrency between this feature and local inventory import can perform, and I won't be surprised if this generates side-effect issues. Generally, I won't advise to use this feature if you also generates local inventories from VMs. You should better choose between running local inventory and use this feature.

Another point, you are showing a screenshot where you expect to see the ip if column, but sorry, I don't understand that language, so I can't confirm you if the ip should be seen in that column. Can you translate the column name into english ?

[alexmicontini]

Hi @g-bougard,

I am clear that performing a local inventory and having the "Create computer for virtual machines" option enabled can be a problem. In my case I will do local inventory later, it is not possible for now, in the meantime I at least wanted to do the inventory for the ESX task. With version 1.11 of the agent it did not obtain from the ESX task either the Operating System or the IP of the VMs. Now with v1.12 I get both the O.S. as the IP, but in GLPI the IP is not registered, however the O.S. is registered.

I think it is because to register the IP it is necessary to associate it with a network interface and that is not obtained by the VCenter ESX task.

[g-bougard]

Okay, this reminded me there was a PR from @stonebuzz which has still been merged in GLPI but will only be available in next release and this PR should probably fix your problem.

Here's the PR: glpi-project/glpi#18746

You can try to apply on your server the changes on src/Inventory/Asset/InventoryNetworkPort.php from this PR.

[alexmicontini]

Hi @g-bougard,

I applied the patch but it did not solve the problem, GLPI does not record the IP address of the VCenter VMs collected with the ESX task with the glpi v1.2 agent, although the agent does collect it.

I think it is because of what I already mentioned, an IP has to be associated with a network interface but the ESX task does not obtain it from the VM, so it is not created in GLPI.

LOG GLPI AGENT

GLPI

[g-bougard]

Hi @alexmicontini

do you have any error that could be related in the GLPI php-warnings.log file ?

Do you see the ip as management ip on computer network ports tab in GLPI ? This may just be an UI issue where the expected ip doesn't appear in the search results but it does in the network ports.

[alexmicontini]

Hi @g-bougard,

in php-errors.log, this error repeats when I run the glpi agent:

[2025-01-31 11:50:41] glpiphplog.WARNING: *** PHP Warning (2): Undefined array key "operatingsystems_id" in /var/www/html/glpi/src/Inventory/Asset/OperatingSystem.php at line 184
Backtrace :
src/Inventory/Asset/VirtualMachine.php:357 Glpi\Inventory\Asset\OperatingSystem->handle()
src/Inventory/Asset/VirtualMachine.php:278 Glpi\Inventory\Asset\VirtualMachine->createVmComputer()
src/Inventory/Asset/MainAsset.php:998 Glpi\Inventory\Asset\VirtualMachine->handle()
src/Inventory/Asset/MainAsset.php:913 Glpi\Inventory\Asset\MainAsset->handleAssets()
src/RuleImportAsset.php:974 Glpi\Inventory\Asset\MainAsset->rulepassed()
src/Rule.php:1537 RuleImportAsset->executeActions()
src/RuleCollection.php:1660 Rule->process()
src/Inventory/Asset/MainAsset.php:577 RuleCollection->processAllRules()
src/Inventory/Inventory.php:726 Glpi\Inventory\Asset\MainAsset->handle()
src/Inventory/Inventory.php:357 Glpi\Inventory\Inventory->handleItem()
src/Inventory/Request.php:364 Glpi\Inventory\Inventory->doInventory()
src/Inventory/Request.php:90 Glpi\Inventory\Request->inventory()
src/Agent/Communication/AbstractRequest.php:359 Glpi\Inventory\Request->handleAction()
src/Agent/Communication/AbstractRequest.php:271 Glpi\Agent\Communication\AbstractRequest->handleJSONRequest()
front/inventory.php:99 Glpi\Agent\Communication\AbstractRequest->handleRequest()
...tplace/glpiinventory/front/communication.php:72 include_once()
marketplace/glpiinventory/index.php:45 include_once()
public/index.php:82 require()

No network interface is created in GLPI

[stonebuzz]

Hi @alexmicontini

would you have a dictionary rule that would change the OS name?

Check that you don't have an inconsistent rule (assign N/A)

Best regards

[alexmicontini]

Hi @stonebuzz,

I don't have any dictionary rules, it is from a default installation of glpi with no additional rules configured.

Best regards

[stonebuzz]

Can you post here related inventory file ?

[alexmicontini]

Hi @stonebuzz,

I cannot send the inventory files because they have confidential information. I send you an extract where a VM appears with the Operating System and the IP address.

[eduardomozart]

Hello guys,
Since I also use ESXi into my homelab I decided to provide my inventory files to help to troubleshoot this issue, as I was able to reproduce it:

Here I opened the UniFi OS Console machine, no IP is shown:

Also find an odd behavior, as ESX inventory seems to create a new machine instead of updating the existing one:

I believe it happens because the GLPI Agent is nativelly installed into server02 VM, but I don't think that should happen. I'll try to troubleshoot that last issue further.

Here's my inventory files:

server02-agentless-esx-inventory.json
server02-with-glpi-agent.json
esxi01.json

[g-bougard]

Hi @eduardomozart

thank you for the sharing, I really don't know why you have assets duplication here. Do you import manually via GLPI UI in Administration section ? If yes, do you have the same problem when injecting the inventory while using glpi-injector script ? If not, you may have to refresh your GLPI session by logging out and logging in so the UI import works as expected.

Regarding the duplication problem because using import from ESX at the same time than import from a local agent, this is realted to a bug from ESX around UUID support... even a very old which caused a lot of trouble to a lot of people. Their poorly managed to report UUID to the vm system a long time ago and we are still have to handle the consequences. Shame on them... 😒
There's maybe a ESX setting to overcome the trouble, but I'm not aware of.

If you check your esxi01.json inventory, you'll see the VM with "564d4cbc-c6a9-1969-3fee-fa0f3887b6a5" as UUID and you'll see "BC4C4D56-A9C6-6919-3FEE-FA0F3887B6A5" as UUID in your computer inventory. There's a big difference on the first 8 hexadecimal digits... the bytes are in reversed order. 😒
This is definitively a big reason to not mix VM asset import/update from ESX host inventory and VM local inventories.

But you probably still can enhance the situation: check Computers import rules and try to play with their order... As serialnumber is the same in the two inventories, you can manage to have the related rules triggered before the S/N+UUID ones, for example you can try to disable import and update rules by serial+UUID. But be aware and warned this can involve other problems. Try this change as your own risk.
Anyway, you may want also to duplicate the update by serial and add a criteria which would check if "serialnumber" starts with "VMware-", then you can move that rules on the top just after the "Computer constraint (name)" and before the "Computer update (by serial + uuid)".
If I test this rule with your files @eduardomozart I can see esx inventory updating the previously imported local inventory, but the computer name is changed, the UUID is changed and even the OS is changed... A lot of trouble.

You should definitively choose between local inventory of ESX VM and VM creation/update from ESX host inventory. This feature has been developed for people who won't run local inventory in the sens of GLPI (as inventory generated by RemoteInventory task are also seen as local inventory by GLPI).

[eduardomozart]

Hello @g-bougard, thank you for your response and digging into this. I'm not sure why the wrong UUID reading, I believe it maybe a bug with GLPI Agent itself instead of ESXi because it reports the UUID correctly on MOB (vSphere API) which I believe where ESX remote inventory gather information from:

On the VMX file of the VM it also doesn't seems to be inverted:

Also, there's the "duplicate VM" error on SQL above, so I believe it's importing the UUID correctly but there should be some buggy on GLPI core itself maybe? Digging into that SQL message maybe lead us to the main issue. I imported them through GLPI Agent itself: simply created an ESX task and run it, I didn't used the GLPI-Injector or manual import through GLPI UI.

I do believe that local inventory (aka. GLPI Agent installed) is the best approach but I have on my homelab some VMs (like ClearPass and Aruba Mobility) which are based on RHEL 8 but they are appliance with their console blocked (I'm unable to install GLPI Agent on them), so a hybrid approach would be great, but I think it would be better handling those scenarios through rules as they aren't common, because how we could handle when not overriding a VM inventory using ESX info when GLPI-Agent is installed for clients with no clean-up inactive GLPI-Agents?

[alexmicontini]

Hi @g-bougard,

I have 400 VMs hosted in the VCenter, in a few of them the agent is installed (I cannot install the agent in all the VMs), so I go to the inventory through ESX to the VCenter to at least have them inventoried with the minimum data of the majority of VMs. Local inventory using the GLPI agent gives much more information than with the ESX task.

In GLPI there is a problem because in the case of VMs that have the agent installed, two Computers are created for the same VM when executing the ESX task, I suppose because the UUID of the Computer created by the agent is different from the UUID of the Computer created by the ESX task.

For example, for the GLPIPre VM:

[g-bougard]

@eduardomozart

About UUID, the problem is not what you can find for a VM on ESX side. GLPI-Agent also finds that value during ESX host inventory. The problem is ESX provided a wrongly encoded UUID via the Bios. Since years, Operating systems see wrong UUID for ESX vms. On the local OS, glpi-agent gets UUID as it does for physical computers. Should do we do differently for ESX ? No, this is not glpi-agent role to assume UUID can be wrong. This is a really old and often reported problem with VMware ESX. Other virtualization systems don't make such a mistake.

For your other question, maybe a hybrid approach would be great, but this won't be cost effective to develop. I agree having dedicated rules glpi-server side would probably be more appropriate. A simple way of doing would be to keep a field on asset telling which task generated an inventory. With such a data, GLPI could be able to decided to not update an asset with an inventory from esx task if an inventory from inventory task was still integrated. Actually, the only data we keep is which agent provided the datas, not the task used to generate datas.

[g-bougard]

@alexmicontini

Yes, this is what I explained an hour ago. As I said, this problem is only related to ESX. Other virtualization systems, don't have that issue.

You can use the rule I told about to not use UUID during asset look up. Maybe if you have only few devices, you can create a rule to just deny the update from ESX when UUID starts with "420717a6-" and only count on locally installed glpi-agent to update that asset. You can also put the full UUID in blacklist. You'll also have to remove the duplicated light entry for that asset.

I still don't know why ip is not integrated. @stonebuzz do you have time to take a look ?

[eduardomozart]

I know it's a bug from ESX, but if it's a known bug, I believe that we could create a workaround to circumvent that because even if it be fixed into the near future, users that are stuck with older ESX versions (which is common since most major ESX upgrades requires a hardware upgrade) would still be affected. I can try to take it a look, but if you wouldn't be willing to accept some PR into that way please let me know so I won't invest time on it.
I'm not sure that tagging the fields with the information about which task populated the field would be enough. E.g. let's say I did an inventory using GLPI-Agent, so I decided to uninstall it to priorize ESX inventory, but ESX inventory wouldn't work on that machine because some day into the past it used GLPI-Agent. Not an easy workaround here. Creating a dictionary to avoid updating info from these machines is the way to go.

[g-bougard]

@eduardomozart

Don't loose your time on such a feature. I don't want to have to maintain ESX bug support in glpi-agent (and indeed there's still some kind of such support on which we are just afraid to have update to do without really knowing if this won't involved more and more problems...).

About the field, you would always have the choice to manually revert how glpi would expect datas are coming from. Of course, this is not optimum, but nothing is fully optimum in such a context.