cconard96
commented
2 years ago I cannot recreate the issue following these steps. The only difference is that I made the VM manually.
Closed mightyspiky closed 2 years ago
cconard96
commented
2 years ago I cannot recreate the issue following these steps. The only difference is that I made the VM manually.
mightyspiky
commented
2 years ago I cannot recreate the issue following these steps. The only difference is that I made the VM manually.
Hmm.. I initially thought the problem occurs also with automatically inventoried KVM virtual machines but I've just verified and it occurs only with my LXC containers. When I click on a container name in the virtualization section, the loaded page doesn't include the memory amount I see on the overview so when I edit any field and save, empty value is overwriting the old value. It might be good to note that with my LXC containers, the amount of memory is suffixed with "M" for megabytes (ex: 2048M) and it's not the case with my KVM virtual machines (ex: 2048). Could it be related to the problem you think?
cconard96
commented
2 years ago The UI for VMs should only accept numeric values but I do see that the database stores the data as a string. This may explain how the value gets removed after saving the form, but the suffixed value "2048M" should not have shown like that at all in the form. It may have shown in other places like search results and the list on the VMs tab though.
The native inventory feature seems to remove some suffixes like B, KB, and MB and ensures the value is converted into the number of MB (without the suffix). I don't see it handling suffixed like "M" though.
mightyspiky
commented
2 years ago The UI for VMs should only accept numeric values but I do see that the database stores the data as a string. This may explain how the value gets removed after saving the form, but the suffixed value "2048M" should not have shown like that at all in the form. It may have shown in other places like search results and the list on the VMs tab though.
The native inventory feature seems to remove some suffixes like B, KB, and MB and ensures the value is converted into the number of MB (without the suffix). I don't see it handling suffixed like "M" though.
My LXC containers first got inventoried with Fusion-Inventory agent but I moved to glpi-agent when I upgraded to GLPI 10. Shouldn't the new native agent modify the value to remove the "M" ? If not, can I safely manually remove the "M" and presume the memory amount will still get updated automatically in GLPI (without adding the "M") if I change the memory amount of my LXC containers in LXC configuration?
mightyspiky
commented
2 years ago By the way, I re-read your last post and the value for the memory field gets removed after loading the form, not after saving it. The value with "M" is only shown in the overview of the virtualization section.
cconard96
commented
2 years ago I don't know if there are locks for VM fields that would prevent the inventory from updating it once it is manually changed. However, if it does get updated by the inventory agent, it would still get the bad value unless the agent is changed to send just memory size in MB without the suffix or with an expected suffix, or the server side is updated to handle more possible suffixes.
The official format for the inventory file states the VM memory value should be "Memory size in MB" and an integer type so no suffixes should be used.
mightyspiky
commented
2 years ago So, if the bug is in GLPI agent and not GLPI server, am I at the right place? Is there a Github page specific to GLPI agent?
cconard96
commented
2 years ago I'll let someone who knows the agent/inventory part better but from what I saw, the LXC inventory in GLPI Agent should get the memory size in bytes but I don't see it being transformed to MB or having a suffix added.
Can you provide the version of the FusionInventory agent and plugin that it was initially inventoried with, and the current GLPI agent version?
On the server side, I guess supporting shortened suffixes would be OK as long as it is safe to assume they stand for Megabyte (1000 1000 bytes) for example and not Mebibyte (1024 1024 bytes).
mightyspiky
commented
2 years ago I really can't remember the initial FusionInventory agent version I've used, sorry, but it's from many years ago. As for GLPI agent, I have the rpm version installed and it's 1.2-1 . As for my problem, I think I might have a clue: In my LXC configuration for a specific container, I have this:
lxc.cgroup.memory.limit_in_bytes = 2048M
The parameter specifies in its name that I should write the value in bytes but I have always used the "M" suffix with success (it works without problem in LXC). Maybe if I write the value in bytes in my LXC conf, I would have no more problem in GLPI interface after the next automatic inventory..? I still think though that GLPI should handle this correctly since the "M" suffix is a valid way to specify memory amount in LXC.
cconard96
commented
2 years ago I saw the config name and it didn't occur to me that it was a user-defined value (I don't know LXC either). In that case, it seems like something that needs handled on the agent side.
g-bougard
commented
2 years ago Hi @mightyspiky please try next glpi-agent nightly build.
mightyspiky
commented
2 years ago I've just tried the nightly build and it works perfect now! I had to delete manually the containers that had the "M" suffix in the GLPI interface but, after that, I re-ran the agent, containers reappear and memory amount for them appears correctly without the "M". Thanks Guillaume!!
mightyspiky
commented
2 years ago I'm now running glpi-agent 1.4 and it seems LXC containers memory limit get inventoried correctly the first time, but if I change the memory limit in an lxc container's config and then run glpi-agent again, the memory limit in GLPI doesn't get updated. I must delete the container in GLPI and then re-inventory again to get the memory limit update so I would like to re-open the issue. Also, I don't know if I must post here or on https://github.com/glpi-project/glpi/issues/11734 so I'm waiting for your answer g-bougard or anyone else.
Code of Conduct
Is there an existing issue for this?
Version
10.0
Bug description
In the GLPI web interface, manually editing the comment field of an LXC container brought up by automatic inventory (in the virtualization section of a computer object) erase the value for the memory field.
Relevant log output
No response
Page URL
No response
Steps To reproduce
Your GLPI setup information
Informations sur le système, l'installation et la configuration
Server
Operating system: Linux zesty 5.4.17-2136.307.3.1.el8uek.x86_64 glpi-project/glpi#2 SMP Mon May 9 17:29:47 PDT 2022 x86_64 PHP 7.4.28 apache2handler (Core, FFI, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, apache2handler, bz2, calendar, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, intl, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, pdo_mysql, posix, readline, session, shmop, sockets, sodium, standard, sysvmsg, sysvsem, sysvshm, tokenizer, xml, xmlreader, xmlwriter, xsl, zip, zlib) Setup: max_execution_time="30" memory_limit="128M" post_max_size="8M" safe_mode="" session.save_handler="files" upload_max_filesize="2M" Software: Apache/2.4.53 (Debian) (Apache/2.4.53 (Debian) Server at zesty.local Port 80 ) Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.5 Safari/605.1.15 Server Software: Debian 11 Server Version: 10.5.15-MariaDB-0+deb11u1 Server SQL Mode: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION Parameters: glpi@localhost/glpi Host info: Localhost via UNIX socket PHP version (7.4.28) is supported. Sessions configuration is OK. Allocated memory is sufficient. mysqli extension is installed. Following extensions are installed: dom, fileinfo, json, simplexml. curl extension is installed. gd extension is installed. intl extension is installed. libxml extension is installed. zlib extension is installed. The constant SODIUM_CRYPTO_AEAD_XCHACHA20POLY1305_IETF_NPUBBYTES is present. Database engine version (10.5.15) is supported. The log file has been created successfully. Write access to /var/www/html/glpi/files/_cache has been validated. Write access to /var/www/html/glpi/config has been validated. Write access to /var/www/html/glpi/files/_cron has been validated. Write access to /var/www/html/glpi/files has been validated. Write access to /var/www/html/glpi/files/_dumps has been validated. Write access to /var/www/html/glpi/files/_graphs has been validated. Write access to /var/www/html/glpi/files/_lock has been validated. Write access to /var/www/html/glpi/files/_pictures has been validated. Write access to /var/www/html/glpi/files/_plugins has been validated. Write access to /var/www/html/glpi/files/_rss has been validated. Write access to /var/www/html/glpi/files/_sessions has been validated. Write access to /var/www/html/glpi/files/_tmp has been validated. Write access to /var/www/html/glpi/files/_uploads has been validated. Web access to the files directory should not be allowed but this cannot be checked automatically on this instance. Make sure access to error log file (/glpi/files/_log/php-errors.log) is forbidden; otherwise review .htaccess file and web server configuration. exif extension is installed. ldap extension is not present. openssl extension is installed. zip extension is installed. bz2 extension is installed. Zend OPcache extension is installed. Following extensions are installed: ctype, iconv, mbstring, sodium. Write access to /var/www/html/glpi/marketplace has been validated. Access to timezone database (mysql) is not allowed.GLPI constants
Libraries
SQL replicas
Notifications
Plugins list
Anything else?
No response