Error when trying to insert inventory from an oVirt node.

[emayoral]

Bug reporting acknowledgment

Yes, I read it

Professional support

Yes, I know

Describe the bug

When trying to insert the inventory from an oVirt node which is running VMs, the inventory injection fails with: glpi-injector --no-ssl-check --debug -f /tmp/inventory2.json --url https://some.url/ Loading /tmp/inventory2.json...[1771B01E] [agentid:bb159e3a-856b-489b-b751-45f420fa81f0] ERROR: JSON does not validate. Violations: "libvirt-qemu" does not match to ^(physical|xen|virtualbox|virtual machine|vmware|qemu|solaris ?zones?|vserver|openvz|bsdjail|parallels|hyperv|aix_lpar|docker|libvirt|lxd|lxc|virtuozzo|kvm|hpvm|wsl[12])$ at #->prop (...) (ssl check disabled) DEBUG: {"status":"error","message":"JSON does not validate. Violations:\n\"libvirt-qemu\" does not match to ^(physical|xen|virtualbox|virtual machine|vmware|qemu|solaris ?zones?|vserver|openvz|bsdjail|parallels|hyperv|aix_lpar|docker|libvirt|lxd|lxc|virtuozzo|kvm|hpvm|wsl[12])$ at #->prop (...)","expiration":24} These elements were not sent: /tmp/inventory2.json

Looks like the agent reports VMs running in oVirt as type "libvirt-qemu", and that is not a recognized type.

To reproduce

1. On an oVirt host glpi-inventory --json --verbose --debug > /tmp/inventory2.json glpi-injector --debug -f /tmp/inventory2.json --url https://some.url/
2. Fails with

glpi-injector --no-ssl-check --debug -f /tmp/inventory2.json --url https://some.url/ Loading /tmp/inventory2.json...[1771B01E] [agentid:bb159e3a-856b-489b-b751-45f420fa81f0] ERROR: JSON does not validate. Violations: "libvirt-qemu" does not match to ^(physical|xen|virtualbox|virtual machine|vmware|qemu|solaris ?zones?|vserver|openvz|bsdjail|parallels|hyperv|aix_lpar|docker|libvirt|lxd|lxc|virtuozzo|kvm|hpvm|wsl[12])$ at #->prop (...) (ssl check disabled) DEBUG: {"status":"error","message":"JSON does not validate. Violations:\n\"libvirt-qemu\" does not match to ^(physical|xen|virtualbox|virtual machine|vmware|qemu|solaris ?zones?|vserver|openvz|bsdjail|parallels|hyperv|aix_lpar|docker|libvirt|lxd|lxc|virtuozzo|kvm|hpvm|wsl[12])$ at #->prop (...)","expiration":24} These elements were not sent: /tmp/inventory2.json

3. Please note that if we leave virtualization out, it works just fine. glpi-inventory --json --verbose --debug --no-category=virtualmachine > /tmp/inventory3.json glpi-injector --no-ssl-check --debug -f /tmp/inventory3.json --url https://some.url/

Loading /tmp/inventory3.json...[F547E777] [agentid:6aaf326e-f793-4eab-a8ef-f807c7d87e23] OK (ssl check disabled) DEBUG: {"expiration":24,"status":"ok"}

Expected behavior

Import is successful.

Operating system

Linux

GLPI Agent version

Other (See additional context below)

GLPI version

10.0.1

GLPIInventory plugin or FusionInventory for GLPI plugin version

1.0.1

Additional context

CentOS Linux release 7.9.2009 (Core) glpi-agent Version 1.4-1

[trasher]

This check has been removed, your issue should be fixed in glpi 10.0.3 (which should be released in september). You can try with GLPI nightly build if you want to be sure.

[emayoral]

Actually I still think this is a bug with the agent. I had not noticed when I first reported the bug, but upon inspecting the generated json data, I see the VMs appear twice. Once as libvirt, once as libvirt-qemu. With same uuid but slightly different attributes. (The one with type "libvirt" seems to be the good one)

Excerpt from the json output:

...
      "virtualmachines": [
...
         {
            "memory": 1048,
            "name": "ns1.serveursdns.net",
            "status": "running",
            "subsystem": "kvm",
            "uuid": "2d0965fd-f077-4337-b470-8cb098c0a827",
            "vcpu": 16,
            "vmtype": "libvirt"
         },
...
         {
            "name": "qemu-27-ns1.serveursdns.net",
            "status": "running",
            "subsystem": "vm",
            "uuid": "2d0965fd-f077-4337-b470-8cb098c0a827",
            "vcpu": 24,
            "vmtype": "libvirt-qemu"
         },
...
      ],

[g-bougard]

Hi @emayoral you should open another issue for this case which is not related to your initial issue.

[emayoral]

OK, I will do as you say. Thanks!