Managed Proxmox Day-2 Operations and Support

Change workflow, support intake, maintenance, troubleshooting, incidents, and ownership boundaries

Day-2 operations and support

Day-2 operations keep Managed Proxmox reliable after onboarding. The goal is a predictable workflow for changes, incidents, maintenance, access, troubleshooting, and ongoing ownership decisions.

Operating cadence#

Cadence	Activities
Continuous	Monitor alerts, backup status, host/storage health, support tickets, and security signals
Weekly or biweekly	Review open changes, capacity trends, failed jobs, documentation gaps, and customer requests
Monthly or quarterly	Access review, restore exercise where scoped, patch planning, capacity forecast, and risk register update
Before major changes	Confirm backups, maintenance window, affected workloads, rollback plan, and customer approver
After incidents	Publish notes, root-cause or contributing-factor summary, and follow-up actions

Change requests#

Use planned changes for:

new VM/LXC provisioning;
CPU, memory, disk, or storage pool changes;
VLAN, firewall, public IP, DNS, or reverse-proxy updates;
backup scope or retention changes;
restore requests;
Proxmox, firmware, kernel, or host package updates;
user or service-account access changes;
hardware replacement, host addition, or storage expansion.

A complete change request includes business reason, environment, affected workloads, requested window, approver, validation step, rollback plan, and communication expectations.

Support intake#

For support requests, include:

Field	Example
Environment and VM	`production`, `staging`, VM name, or cluster name
Business impact	Users affected, release blocked, revenue impact, internal-only issue
Urgency	Critical outage, degraded service, planned question, advisory request
Recent changes	Deployments, firewall updates, host maintenance, storage expansion, user changes
Evidence	Error messages, timestamps, screenshots, logs, monitoring links, ticket links
Desired outcome	Restore VM, add capacity, confirm health, investigate alert, schedule migration

Troubleshooting quick reference#

Symptom	First checks	Likely handoff
VM down	Proxmox task log, host health, storage availability, guest console, recent changes	Assistance for platform; customer for guest OS/app root cause unless scoped
VM slow	Host contention, storage latency, backup job, guest CPU/RAM, application load	Shared: Assistance checks platform, customer checks application behavior
Disk full	VM disk usage, storage pool usage, snapshots, backup retention, logs	Customer approves data cleanup; Assistance expands platform storage when scoped
Network unreachable	VLAN/bridge, guest IP/gateway, firewall, DNS, public IP, provider status	Depends on firewall/provider ownership
Backup failed	Target capacity, credentials, VM locks, snapshots, storage health	Assistance fixes platform job; customer validates data policy impact
Restore needed	Backup availability, target isolation, overwrite approval, validation owner	Assistance restores; customer accepts application/data result
Suspected compromise	Preserve logs, isolate if approved, review access, recent changes, affected VMs	Incident workflow; customer owns application/legal communications unless contracted

Maintenance workflow#

Identify maintenance need and affected hosts/VMs.
Confirm backup status and rollback considerations.
Request customer approval if impact is possible.
Announce maintenance window and expected symptoms.
Apply change, monitoring throughout.
Validate platform and named workloads.
Record outcome, known issues, and follow-up actions.

Ownership boundaries#

Topic	Assistance owns	Customer owns
Proxmox platform	Host and cluster operations, storage/network configuration in scope, monitoring, backups, and runbooks	Approvals, risk acceptance, application priority, business timing
Guest OS	Only if explicitly included	OS packages, users, services, agents, and hardening inside customer-managed VMs
Applications	Only if separately contracted	Code, configuration, releases, data correctness, and customer-facing behavior
Data policy	Implement scoped backup/retention controls	Classification, legal retention, deletion, and restore acceptance
Provider/facility	Coordinate if scoped	Contracts, billing, remote hands, circuits, warranties, and provider escalations unless contracted
Security/compliance	Technical controls and evidence in scope	Legal conclusions, internal policy, access approvals, audit submissions, and breach communications

Incident workflow#

For critical issues, use the agreed incident channel and define roles: incident lead, platform operator, customer application owner, communications owner, and provider/vendor contact. Preserve evidence, stabilize first, avoid destructive changes without approval, and document the timeline as the incident unfolds.

After recovery, record customer impact, technical cause or contributing factors, what worked, what failed, and actions for monitoring, backup, architecture, documentation, or process improvement.

Offboarding or scope change#

When Managed Proxmox scope ends or changes, agree the handoff: final inventory, backups, credentials, documentation, outstanding risks, support end date, provider ownership, and data deletion/retention steps. Assistance should not retain access beyond the agreed period.