Proxmox

What we configure on Proxmox VE

On Proxmox VE we build virtualisation clusters starting from two or three physical nodes, with shared storage on Ceph or on a dedicated NAS when the budget does not stretch to a SAN. We configure the virtual network with bridges and separate VLANs for management, storage and application traffic, so a fault on one segment does not bring down the whole infrastructure. Every virtual machine starts from a verified template, sized against the real workload measured during the initial assessment, not a generic estimate.

We almost always pair it with Proxmox Backup Server, running incremental, deduplicated backup jobs scheduled outside production hours. Where the workload justifies it we enable high-availability clustering: if a node fails, virtual machines restart automatically on another node in the cluster, with downtime measured in minutes rather than hours. On some projects we use ZFS as the filesystem for local disks, for instant snapshots and block-level data integrity checks.

• Clusters of 3 or more nodes with quorum and automatic failover, or 2 nodes plus an external QDevice
• Shared storage on Ceph or iSCSI to a dedicated NAS
• Proxmox Backup Server with encrypted incremental backups
• ZFS snapshots for instant rollback before any change

When Proxmox is the right choice, and when it is not

Proxmox is the right choice when you need to consolidate several under-used physical servers, cut licensing costs against a proprietary platform, or build a virtual infrastructure from scratch for a new site. We also recommend it when you need a test environment separate from production, because spinning up and tearing down virtual machines costs little in time or resources. With Windows-native applications that require direct vendor support on certified hypervisors, we assess it case by case before proposing it.

It is not the right choice if you already hold a multi-year support contract on a proprietary platform and the migration ROI does not cover the project cost in the short term, or if the business has no in-house staff and no support contract to look after the infrastructure after installation. In these cases we work out a gradual path together, often starting with a single non-critical workload before moving all production over.

How we run a Proxmox project

We start with an assessment of the existing workload: number of virtual machines, storage in use, CPU and RAM peaks during busy hours. On that basis we size the hardware and plan the migration in waves, moving less critical services first to test the method before touching anything that cannot afford downtime. Every phase has a verified rollback plan: if something does not work as expected, we roll back without leaving the business without services.

Testing happens in our Melzo lab before the hardware even reaches your site, where the equipment allows it, and always again on site before we consider the project closed. After go-live we keep supporting the infrastructure with ongoing maintenance: scheduled updates, backup verification and monitoring of the cluster nodes, not just a callout when something breaks.

Security, updates and lifecycle

We plan Proxmox VE updates in agreed maintenance windows, testing patches on a secondary node first whenever the cluster allows it. AES-256 encryption on Proxmox Backup Server protects your data even if the physical media is removed from the premises, and it is a requirement more and more clients ask for because of NIS2 security obligations, where we support businesses with their compliance work.

The hardware Proxmox runs on has its own lifecycle: we offer Dell, HP and Lenovo servers on operational rental too, so refreshing the fleet is not a single upfront investment and stays covered by warranty. When a node reaches end of life, we plan the migration of virtual machines to the new hardware with no production downtime, using the very portability that is one of the reasons clients choose this platform.