How the Proxmox Integration Works
The hypervisor module authenticates against the Proxmox VE REST API using a dedicated API token scoped with PVEAuditor and PVEVMAdmin roles. When you ask a question about your virtualization environment, the system's intent classifier routes your request to the Proxmox collector, which translates natural language into the appropriate API calls.
The collector maintains a persistent connection pool to each Proxmox node in your cluster. It does not cache stale data. Every query you run hits the live API, and the response is assembled in real time. This is the same design principle behind every module: the AI layer generates dashboards and analysis from current infrastructure state, never from memory or training data.
Authentication and Access Control
API tokens are stored in an encrypted credential vault and are never exposed in conversation output. The token's role-based permissions in Proxmox determine what the platform can read and modify. For read-only deployments, a PVEAuditor role is sufficient. For environments where you want AI-assisted provisioning, the token needs PVEVMAdmin on the target resource pools. The system never escalates beyond the permissions you configure.
VM and Container Queries
The most common interaction pattern is querying the current state of your virtual machines and LXC containers. You can ask in plain language and the system builds structured output from the /api2/json/nodes/{node}/qemu and /api2/json/nodes/{node}/lxc endpoints.
The tabular output is generated inline by the AI layer, not by a pre-built template. The system reads the raw JSON from the Proxmox API, identifies the fields that are relevant to your query, and assembles a structured response. If you ask a follow-up like "which one is using the most memory," it re-reads the data and answers contextually.
LXC Container Management
Lightweight containers are a core part of most Proxmox environments, and the system handles them as first-class objects. You can query, start, stop, and inspect LXC containers with the same conversational interface used for full VMs.
Resource Monitoring: CPU, Memory, and Disk
Beyond listing VMs, the system pulls real-time resource utilization from the Proxmox RRD (round-robin database) API endpoints. This gives you CPU load averages, memory pressure, disk I/O rates, and network throughput without opening a browser or SSH session.
The warning is not hard-coded. The AI layer computes threshold crossings from the live numbers and raises alerts when utilization exceeds configurable limits (default: 85% RAM, 90% storage). The storage growth projection uses the delta between current usage and the value from the previous polling interval to estimate linear fill rate.
ZFS Storage Health
Most production Proxmox deployments use ZFS for data integrity and snapshots. The platform queries ZFS pool status through the Proxmox API's storage and disk endpoints, surfacing pool health, fragmentation, scrub status, and any degraded vdevs.
ZFS degradation is one of the highest-severity conditions the system can surface. When a pool enters a degraded state, the platform flags it immediately and provides the specific CLI command you would need to investigate further on the host. The system does not attempt to run host-level commands on its own — it operates exclusively through the Proxmox REST API and presents actionable guidance for anything that requires direct shell access.
Cluster Management and HA Status
For multi-node Proxmox clusters, the system monitors cluster quorum, corosync ring status, and HA (High Availability) group configuration through the /api2/json/cluster/ha and /api2/json/cluster/status endpoints.
If a node loses quorum or an HA resource enters an error state, the system reports it with full context: which resource, which node, and what the last known state transition was. This eliminates the need to check the Proxmox web UI or parse ha-manager status output manually.
Backup Monitoring
The platform queries the Proxmox backup job configuration and recent task logs to give you a consolidated view of backup health. It pulls from /api2/json/cluster/backup for schedules and /api2/json/nodes/{node}/tasks filtered to vzdump type for execution history.
The system does not just report pass/fail. It pulls the task log for failed jobs and extracts the error message, so you can understand the root cause without digging through the Proxmox task viewer. In the example above, the AI identifies that the backup target ran out of space for a specific VM and surfaces the exact error string from the vzdump log.
VM Provisioning and Lifecycle Management
When the API token has write permissions, the platform can provision new VMs and containers through natural language. The system translates your request into the appropriate API calls, but critically, it presents the full configuration for your approval before executing anything.
Every write operation — VM creation, resource modification, start, stop, migration — goes through the approval gate. The system never executes destructive or state-changing API calls without explicit confirmation. This is not a configurable setting; it is hard-coded into the architecture.
AI Capacity Planning and Rebalancing
One of the more valuable features of AI-powered server management is capacity analysis. The system examines resource allocation across your cluster and identifies imbalances, over-provisioned VMs, and nodes approaching capacity limits.
These recommendations are computed from the live resource data, not from a pre-defined rule engine. The AI layer compares actual utilization against allocated resources, identifies which migrations would improve overall balance, and validates that the destination node has sufficient headroom before suggesting the move. It will never recommend a migration that would push the target node past its capacity thresholds.
Inline Dashboard Generation
A key architectural feature of the platform is that dashboards are not pre-built panels. When you ask for a resource overview, cluster summary, or backup report, the AI constructs the output format dynamically based on what data the API returned and what your query was asking for. A question about "memory usage across VMs" produces a memory-focused table. A question about "backup health" produces a schedule-and-status view. The same underlying API data is presented differently depending on context.
This means there are no dashboard pages to maintain, no widget configurations to update when you add a new node, and no stale panels showing data from a VM that was decommissioned last month. The output always reflects the current state of the cluster because it is generated on the fly from the current API response.
What the System Does Not Do
The platform operates exclusively through the Proxmox REST API. It does not SSH into your nodes. It does not install agents on guest VMs. It does not require network access to anything other than the Proxmox API endpoint (typically port 8006). If the Proxmox API does not expose a particular data point, the system will tell you that the information is not available through the API rather than guessing or fabricating a response. This constraint is fundamental to the anti-fabrication architecture that governs all modules.