Managed Proxmox Physical-Server Prerequisites

Dedicated hardware, facility, access, and provider inputs needed before onboarding

Physical-server prerequisites

Managed Proxmox depends on the physical environment being operable. Before Assistance builds or takes over a cluster, the customer and Assistance must confirm the hardware, facility, provider, connectivity, and access assumptions that define the operating boundary.

Required decisions before build or takeover#

Area	Must be confirmed
Hardware ownership	Who procures, owns, warranties, replaces, and pays for the physical servers and parts
Site/provider	Customer site, colocation, hosting provider, or Assistance-managed facility model
Remote access	Out-of-band management path such as IPMI/iDRAC/iLO, VPN/bastion access, console credentials, and emergency access path
Network handoff	Public IPs, private subnets, VLANs, routing, firewall ownership, DNS ownership, and any provider limits
Storage layout	Local disks, shared storage, redundancy expectations, usable capacity, spare policy, and backup target
Power and cooling	Rack placement, dual power where available, UPS/generator assumptions, cooling, and maintenance access
Support model	Support hours, severity definitions, escalation contacts, hardware replacement workflow, and maintenance-window policy

Hardware baseline#

The exact bill of materials is scoped per workload, but the assessment should capture:

CPU model, core count, virtualization extensions, and expected consolidation ratio;
memory capacity, growth plan, and per-workload reservation assumptions;
boot disks, VM/storage disks, controller mode, firmware level, disk health, and hot-spare strategy;
NIC count, speed, bonding options, management network, public/private separation, and VLAN support;
vendor warranty, replacement lead time, spare availability, and provider hands-on support process;
hardware age, firmware update history, BIOS settings, and known component alerts.

For production or business-critical workloads, single-host designs should be treated as a conscious risk decision. Clustering, redundant networking, redundant storage, and tested backups reduce risk but do not remove the need for application-level recovery validation.

Access prerequisites#

Assistance needs enough access to operate the agreed boundary and no more:

Access type	Purpose	Customer ownership
Proxmox administrative access	Cluster setup, upgrades, VM operations, storage/network changes, incident response	Approve named users, review access, and remove access when no longer needed
Out-of-band management	Recover hosts when the OS or network is unavailable	Provide emergency approval path and provider contacts
Network devices or provider portal	Implement or verify routing, VLANs, firewall, and public IP changes when scoped	Confirm who can approve network-impacting changes
Backup target	Configure backup jobs, retention, restore tests, and failure alerts	Define data classification, retention rules, and restore acceptance
Monitoring and alerting	Collect metrics, route alerts, and investigate incidents	Confirm escalation contacts and business-impact mapping

Acceptance gate#

Before production workloads move onto Managed Proxmox, record evidence for:

host inventory and serial/provider details;
network diagram or written topology;
storage layout and usable-capacity estimate;
management and emergency-access path;
backup target and first successful backup;
monitoring and alert route;
customer owner for application validation;
planned maintenance window and support channel;
known risks accepted by the customer.

Facility and provider ownership must be explicit

If the customer owns the colocation, hosting provider, power, network circuit, or warranty relationship, Assistance can coordinate and advise, but provider contracts and business approvals remain with the customer unless the engagement explicitly says otherwise.