[ZBX-23189] Patch up Proxmox VE by HTTP template Created: 2023 Aug 02  Updated: 2024 May 10  Resolved: 2024 May 09

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Templates (T)
Affects Version/s: 6.4.5
Fix Version/s: None

Type: Patch request Priority: Trivial
Reporter: MArk Assignee: Aleksejs Abrosimovs
Resolution: Won't fix Votes: 0
Labels: Proxmox, lxc, qemu, template, uptime, vm
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All

Attachments: PNG File Screenshot 2024-05-08 154312.png     PNG File Screenshot 2024-05-08 154849.png     PNG File uptime_zero.png     PNG File vm_lxc_event_active.png    

 Description   

The "Proxmox VE by HTTP" OOTB template includes an "LXC discovery" and a "QEMU discovery" with the following trigger prototypes:

LXC

Name: Proxmox: LXC {#NODE.NAME}/{#LXC.NAME}: has been restarted
Expression: last(/Proxmox VE by HTTP/proxmox.lxc.uptime{#LXC.ID})<10m

QEMU

Name: Proxmox: VM {#NODE.NAME}/{#QEMU.NAME}: has been restarted
Expression: last(/Proxmox VE by HTTP/proxmox.qemu.uptime{#QEMU.ID})<10m

 

In both cases, the trigger identifies and generate an event when a discovered LXC/VM has an uptime of less than 10 minutes. However, there is a potential issue with this approach that could to be addressed.

The issue arises when the item "Proxmox: LXC/VM {#LXC.NAME}/{#LXC.NAME}: Status" captures the LXC/VM's raw status, which includes the uptime even when it is stopped. In such cases, the uptime value remains at zero, causing the trigger expression to generate an event that won't be resolved.

 

To mitigate this issue, it is good to perform a status validation before generating the event. This validation should check the status of the LXC/VM and prevent the trigger from generating events for stopped instances.
A simple status check should suffice. By incorporating this validation, the trigger will only generate an event when the LXC/VM is genuinely restarted and not when it is stopped.

Here's a suggested version of the trigger expression that includes the status validation:

LXC:

 

last(/Proxmox VE by HTTP/proxmox.lxc.uptime[{#LXC.ID}])<10m
and
last(/Proxmox VE by HTTP/proxmox.lxc.vmstatus[{#LXC.ID}],#1)="running"

 

QEMU:

 

last(/Proxmox VE by HTTP/proxmox.qemu.uptime[{#QEMU.ID}])<10m
and
last(/Proxmox VE by HTTP/proxmox.qemu.vmstatus[{#QEMU.ID}],#1)="running"

 

With this modified expression, the trigger will only fire when the LXC/VM has an uptime of less than 10 minutes and its status is "running," ensuring that events are generated and resolved accurately.

 Comments   
Comment by Aleksejs Abrosimovs [ 2024 May 07 ]

Fixed in: ZBX-21455

Comment by MArk [ 2024 May 08 ]

Hi. I appreciate the time taken to analyze this issue, but I think there's a misunderstanding.
With Zabbix 6.4.14 and the latest OOTB template for Proxmox, the problem is still present.

This patch request is newer than ZBX-21455, and the commits created for it did not fix the problem.
The included dependencies did not solve the problem for the Proxmox: ... has been restarted triggers.

Again, as I described, if we use the OOTB template, the VM/LXC triggered event will remain active indefinitely.

Comment by MArk [ 2024 May 08 ]

Hi. I appreciate the time taken to analyze this issue, but I think there's a misunderstanding.
With Zabbix 6.4.14 and the latest OOTB template for Proxmox, the problem is still present.

This patch request is newer than ZBX-21455, and the commits created for it did not fix the problem.
The included dependencies did not solve the problem for the Proxmox: ... has been restarted triggers.

Again, as I described, if we use the OOTB template, the VM/LXC triggered event will remain active indefinitely.

Comment by Aleksejs Abrosimovs [ 2024 May 08 ]

Triggers "* has been restarted" are dependent on corresponding triggers "* Not running", where the "running" status of the LXC/QEMU is already checked. Creating an additional check is unnecessary, and it will add extra load to the server.

 

Trigger "* has been restarted" will behave as intended if the following items works as they should:
Proxmox: LXC [

{#LXC.NAME}

/{#LXC.NAME}|#LXC.NAME}/{#LXC.NAME}]: Status
and items dependent on it:
Proxmox: LXC [

{#NODE.NAME}

/{#LXC.NAME} ({#LXC.ID})|#NODE.NAME}/{#LXC.NAME} ({#LXC.ID})]: Status
Proxmox: LXC [{#NODE.NAME}

/{#LXC.NAME} ({#LXC.ID})|#NODE.NAME}/{#LXC.NAME} ({#LXC.ID})]: Uptime

 

Please, double-check your installation and configuration.

 

Tested with clean default installation of Proxmox VE 8.2.2 and Zabbix servers 6.0.29 / 6.4.14 / 7.0.0beta3. Everything works fine.

 

P.S. Misleading items names ("Status") are fixed in ZBX-24451

 

As an example:

LXC is not running and uptime is less than 10 min. Therefore both triggers has "problem" status:

But, because "has been restarted" is dependent trigger, it is not shown in the "Problems menu/section":

Comment by MArk [ 2024 May 10 ]

Please, consider this scenario:
If a VM/LXC is stopped manually, a new event may not be necessary.
However, with the default template, whenever a VM/LXC is stopped, two new events are created, where only the "has been restarted" trigger is withheld.
This may or may not be a desired behavior. It all depends on the Proxmox environment and usage.
Mine, for example, has some stopped VM/LXCs and Zabbix should not create events for them.

My main point is that a dependency between the "not running" and "has been restarted" triggers does not address the scenario where a VM/LXC has been manually stopped.

If an admin manually stops a Proxmox VM, and he disables the Zabbix "not running" trigger to avoid a permanent open problem, the "has been restarted" trigger then arises for the stopped VM. This event can be avoided by using the suggested expression.

Another approach to prevent the "has been restarted" trigger from firing on a stopped VM/LXC is to check if the VM/LXC uptime is greater than 0, instead of checking 2 different items.

LXC:

last(/Proxmox VE by HTTP/proxmox.lxc.uptime[{#LXC.ID}])<10m
and
last(/Proxmox VE by HTTP/proxmox.lxc.uptime[{#LXC.ID}])>0

QEMU:

last(/Proxmox VE by HTTP/proxmox.qemu.uptime[{#QEMU.ID}])<10m
and
last(/Proxmox VE by HTTP/proxmox.qemu.uptime[{#QEMU.ID}])>0

 

Of course, these are just suggestions for improving the template logic.

Comment by Aleksejs Abrosimovs [ 2024 May 10 ]

The current template's behavior suits the general needs of most Proxmox users. Unfortunately, we can't satisfy all possible variations of installations and situations.
But there is the beauty of the Zabbix - you can adjust and fine tune almost everything. 
For example, you can adjust the template so it will react better to your installation.

Or you can temporarily disable monitoring for stopped machines/containers.
For example: to disable monitoring for specific LXC, you can disable main monitoring item (HTTP agent) for that container:

Proxmox: LXC [{#LXC.NAME}/{#LXC.NAME}]: Status

or as it will be called in the following versions: 6.0.30rc1, 6.4.15rc1, 7.0.0rc1:

Proxmox: LXC [{#NODE.NAME}/{#LXC.NAME}]: Get data

 

Thank you for your interest in improving Zabbix.
We appreciate your time and effort.

 

Generated at Sun Jun 08 15:17:17 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.