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.

Deploy and authorize an Edge Agent when the platform cannot directly reach the virtualization network or when node SSH and guest Console need a controlled private path.

Add a node

Enter a recognizable name, host or cluster address, API port and protocol, realm, user, and required token or password. Select the Edge Agent path where needed.

Run Test connection before saving and distinguish DNS or routing, TLS, authentication, and authorization failures. After save, review any cluster nodes discovered by synchronization instead of creating duplicates.

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 from the last synchronized local state. Nodes show online state, guest count, CPU, RAM, and backup indicators and start collapsed to keep large clusters readable.

Search by node, guest name, or VMID and let the interface open the owning node. Always read the last synchronization 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. Select the correct node and Edge Agent, verify the target fingerprint and authorization, and enter credentials only in the protected terminal flow.

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. The VNC 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