Proxmox: nodes, virtual machines, and monitoring

Scope and boundaries

Proxmox integration inventories virtualization nodes, QEMU virtual machines, LXC containers, power state, telemetry, backups, problems, and synchronization history. It is an infrastructure view, while ISP Dude remains responsible for general network monitoring.

Provider state is authoritative for guest execution; ISP Billing maintains a synchronized operational copy and protected actions.

Prerequisites and security

Create a dedicated Proxmox API identity with the minimum permissions required for inventory and the explicitly enabled actions. Use trusted HTTPS, limit source networks, document credential ownership, and rotate secrets.

For a private node, deploy an up-to-date Edge Agent on a network that can reach its Base URL. The agent uses an outbound connection, so port 8006 does not need to be published. There is no automatic fallback from the assigned agent to direct access.

Add a node

Choose Direct connection or Through Edge Agent, then enter the exact node name, Base URL, API Token ID, secret, and SSL verification setting. Agent mode accepts a private address and requires the agent located on that network.

Direct mode validates during save. For a private node, save first and then run Test connection; the test verifies routing, TLS, authentication, authorization, and the configured cluster node name through the agent. On edit, leave the secret empty to retain the stored value.

General settings and thresholds

Configure the synchronization interval and realistic thresholds for CPU, RAM, backup age or absence, and other supported problem sources. Thresholds should identify actionable risk rather than create permanent noise.

Select one default Edge Agent for node SSH and guest Console. An override chosen for one interactive session does not silently replace the saved default.

Hierarchical dashboard

The compact hierarchy displays node → VM or LXC. Nodes show availability, the configured management address, guest count, CPU, RAM, and backup indicators and start collapsed. A direct address can open in a new tab; a private address is not opened by the browser. The Monitoraggio con Edge Agent (Monitoring with Edge Agent) badge identifies nodes monitored through an agent. Direct connections show Monitoraggio con (Monitoring with) followed by the custom platform brand associated with the Master domain.

Compact bars appear below the values: blue for the proportion of running guests, green for CPU and RAM below their thresholds, and orange at or above them. The backup bar separates OK results in green from KO results in red; a grey remainder and the ? symbol indicate unknown results. An empty bar with no backup records does not indicate full coverage. Numbers remain visible; unavailable CPU and RAM values show —. On phones, the indicators use two rows.

Online indicates node availability. When warnings are present, a third line below the address displays Da verificare (Needs attention) with every reason, even while the node is collapsed: CPU or RAM values and thresholds, counts of missing backups or backup errors, storage warnings, or unreadable data. These warnings use thresholds of at least 80% CPU, 85% RAM, and 90% storage usage. The storage summary counts storage locations above the threshold or unreadable, without distinguishing those causes: check available space and storage accessibility in Proxmox.

For a missing backup or backup error, expand the node and open Gestisci VM (Manage VMs); for unreadable data, check node connectivity and permissions. The Problemi (Problems) counter refers to the issues on that page and can differ from the number of nodes with warnings.

Espandi tutti (Expand all) and Comprimi tutti (Collapse all) control the hierarchy. Search by node, guest name, or VMID to open the owning node. Always read the last update time before treating telemetry as current.

Nodes, VMs, and containers

Node detail identifies infrastructure and aggregate capacity. Guest rows distinguish QEMU and LXC, VMID, node, power state, CPU, memory, storage or backup information returned by Proxmox, and available actions.

Confirm cluster, node, guest type, VMID, name, and customer impact before any operation. Identical names can exist in different contexts; VMID plus node is the safer operational reference.

Start, Shutdown, Stop, and Reboot

Start boots a stopped guest. Shutdown requests an orderly guest shutdown. Stop is forced and can cause data loss. Reboot restarts a running guest.

Check maintenance authorization, dependent services, backups, and user impact. Execute once, wait for the remote task, and refresh state before considering another action.

Synchronization and logs

Synchronization updates cluster inventory, guest state, resource metrics, and backup observations. It also opens, updates, or resolves problem records according to configured thresholds.

Review last run, duration, counts, warnings, and errors. A successful scheduler start is not proof that every node responded; use logs to identify partial results and stale guests.

Problems and history

Problems are retained independently from notification-channel settings. A stable source key prevents duplicate open issues for the same condition, while transitions preserve first detection, updates, and resolution.

Resolved problem history remains available for the configured retention period, including 30-day history where implemented. Use it for trend analysis and threshold tuning rather than deleting evidence of intermittent failures.

Backups

Backup indicators show the observations available from Proxmox and must be compared with the ISP’s policy for frequency, retention, storage separation, encryption, and protected workloads.

The existence of a backup entry does not prove recoverability. Perform controlled restore tests, document results, and investigate stale or missing jobs before relying on a green summary.

Notifications and recipients

Configure recipients and supported channels such as push, WhatsApp, email, and Telegram. Telegram uses shared Bot accounts already linked in the platform. Match each severity to an accountable, monitored recipient.

A test action sends a real message and must be explicitly initiated. Provider acceptance is not proof that the on-call operator read the alert; verify delivery and escalation separately.

Node SSH

SSH is exposed for Proxmox nodes, not for QEMU or LXC guests. Direct nodes allow a session agent choice; private nodes lock the session to the agent assigned in node configuration.

Credentials travel in an encrypted temporary payload and are removed after Agent retrieval or timeout. Do not paste them into documentation, activity notes, or chat.

VM/LXC Console and audit

QEMU and LXC use the Proxmox noVNC Console protected by a fresh two-factor check. For private nodes, both VNC ticket creation and the Console network connection use the assigned agent. The ticket is short-lived and retained in memory while the gateway relays the WebSocket; production requires HTTPS and WSS.

Console Audit records 2FA verification, request, connection, closure, and error events. Review the target and maintenance reason before access. Guests do not expose node-style SSH through this module.

Checklist

• Create least-privilege Proxmox credentials
• Verify HTTPS, routing, and authorization
• Register an Edge Agent where required
• Test a node before saving
• Review cluster discovery and avoid duplicates
• Set actionable synchronization and problem thresholds
• Check last-sync freshness and partial errors
• Verify guest type, node, and VMID before actions
• Prefer orderly Shutdown over forced Stop
• Assign monitored notification recipients
• Test backup restoration, not only presence
• Use SSH on nodes only
• Protect Console with 2FA and audit review