PVE UPS is an open source appliance designed to shut down standalone Proxmox VE hosts in an orderly sequence when utility power fails. The PVE UPS project repository says it can read UPS information through an RFC 1628 compatible SNMP network card or an existing Network UPS Tools server. It then uses the Proxmox API to shut down configured hosts before battery runtime is exhausted. The project targets a common operational gap. A UPS can keep servers running during a short interruption, but it cannot protect workloads when administrators have no reliable process for ending services before the battery reaches a critical level. This is part of the wider planning covered in a disaster recovery plan, where power failure, service priorities, dependencies, responsibilities, and recovery procedures must be coordinated.
The Appliance Centralizes Shutdown Decisions
PVE UPS normally runs as a small unprivileged Debian LXC container and provides a web based configuration wizard. Administrators can define UPS devices, hosts, power feeds, battery thresholds, notifications, and shutdown policies without maintaining separate scripts on every host. It supports dedicated Proxmox API tokens with only the Sys.PowerMgmt privilege, avoiding root SSH access.
The project also includes dry run behavior, test controls, stored countdown state, and a rule that the host carrying the appliance shuts down last. These controls reduce the risk of deploying an untested shutdown policy. They do not eliminate the need for staged testing. Administrators should simulate loss of mains power, communication failure, restored power, low battery conditions, and an unavailable host before arming the system.
Ordered Shutdown Protects Consistency
A sudden power loss can leave databases, virtual disks, containers, and filesystems in an uncertain state. The risk increases when several workloads depend on each other. An application tier may need to stop before its database, while storage services and network infrastructure may need to remain available until guest shutdown is complete.
PVE UPS focuses on host order rather than full application dependency orchestration. Teams should still document which guests must stop first, how long shutdown takes, and what happens when a guest does not respond. Recovery objectives can help define how much battery runtime is required. The RPO and RTO guide explains how acceptable data loss and restoration time influence architecture, backup frequency, staffing, and testing.
The Current Project Has Clear Limits
The repository states that PVE UPS currently supports standalone hosts and does not integrate with Proxmox cluster or high availability manager behavior. That matters because clustered systems may migrate or restart guests according to rules that conflict with a simple host shutdown sequence. Administrators should not assume that an ordered list of API calls replaces cluster aware maintenance logic.
The appliance also depends on accurate UPS telemetry, network connectivity, valid API credentials, and enough remaining battery time. Its fail safe model does not treat lost UPS communication as a confirmed outage by default, which helps prevent accidental shutdowns but creates another scenario that must be monitored. NUT communication is unencrypted and should remain inside a trusted network.
Community Tools Require Operational Review
PVE UPS is a young community project, not an official Proxmox product. Teams should inspect the code, release process, permissions, update mechanism, logs, and failure behavior before using it in production. The same discipline applies to other Proxmox helper scripts and community tools: convenience must be balanced with security review, version compatibility, rollback, testing, and documentation.
The project addresses a real problem with a practical design. Its value will depend on whether the shutdown policy matches the environment, whether the available UPS runtime is sufficient, and whether administrators test both the power failure and the later recovery process.
Originally published on the Mr.PlanB blog.
Top comments (0)