Your metal · my watch

Virtualization that hums while you sleep.

I manage Proxmox and VMware environments end to end: the inherited cluster nobody documented, the VMware bill that tripled overnight, the backup job everyone hopes works. Mapped, patched, monitored — and test-restored on a calendar, not on faith.

VMware → Proxmox migrationsRestore drills, not hopeOn-prem & remote
pve-cluster · 3 nodes · quorate reference view
pve-01online
cpu 42%
ram 61%
14 VMs
pve-02online
cpu 38%
ram 55%
12 VMs
pve-03online
cpu 47%
ram 78%
15 VMs
live-migrating VM 104 (erp-db) pve-03 → pve-01 · no downtime
backup job nightly-all: 41/41 VMs · restore drill passed Sunday
Why this exists

Every company has that one server room

Virtualization is the layer everything else stands on — and usually the layer with the least documentation, the oldest patches, and the most crossed fingers.

The cluster nobody built

The person who set it up left years ago. Now it is a black box everyone depends on and nobody dares touch — upgrades postponed indefinitely.

The VMware bill that tripled

Licensing changes turned a settled cost into a boardroom question. Proxmox is the obvious answer — if someone can migrate without breaking production.

Backups on faith

The job runs every night and emails green. Whether anything can actually be restored — nobody has checked since it was configured.

What I do

Discovery, migration, and the boring routine

The value is not the hero fix — it is the environment that stops needing one.

Discovery & stabilisation

The inherited environment gets mapped into documentation that matches reality, then brought to a known-good, patched state.

  • Full inventory: hosts, VMs, storage, networks, jobs
  • Runbooks for the operations you actually perform
  • Patching plan with maintenance windows
  • Out-of-band access verified before it is needed

Migrations without drama

VMware to Proxmox in planned waves with rollback points — test workloads first, production in windows, the old environment intact until proven.

  • VMware → Proxmox, ESXi import tooling or clean rebuild
  • Hyper-V and plain KVM/libvirt estates covered too
  • Storage design: ZFS, Ceph, or your existing SAN
  • Clustering, HA and live migration configured properly
  • Each wave verified before the next begins

Managed, month to month

Patching, capacity, hardware health, backups — watched continuously, reported monthly, restored on a drill calendar.

  • Hypervisor & firmware patching in agreed windows
  • Capacity and hardware-health monitoring with alerts
  • Proxmox Backup Server / Veeam with restore drills
  • Monthly report: what changed, what is trending
How it works

From black box to boring — in weeks

1

A call, and an honest answer

Twenty minutes on what you run and what keeps getting postponed. If your setup is fine and just needs documentation, I will say exactly that.

Day 0
2

Discovery, read-only

I map hosts, VMs, storage, networking and backup jobs into a written picture of the environment — including the risks you can't currently see.

Week 1
3

Stabilise, then change

Patching, backup verification and monitoring come first. Migrations and upgrades follow in planned waves with rollback points, never as a big bang.

Weeks 2–6
4

On watch, month to month

The routine that keeps it boring: windows, drills, capacity trends, and a human who answers when something breaks. Cancel any month; the docs are yours.

Ongoing
Before you ask

The questions every ops team asks

Proxmox VE and VMware ESXi/vSphere are the daily drivers, and underneath Proxmox sits KVM, which I also run standalone with libvirt where a full platform is overkill. Microsoft Hyper-V environments are covered too — managed as they are, or migrated when consolidation makes sense. Mixed estates are normal; the discovery pass maps whatever combination you actually have.

Yes — that is the most common starting point. The first pass is discovery: mapping hosts, VMs, storage, networking and backup jobs into documentation that finally matches reality. Nothing is restarted or upgraded until that map exists and you have seen it.

Yes. With Broadcom's licensing changes, VMware-to-Proxmox is now a routine request. Workloads move in planned waves with rollback points: test VMs first, then production in maintenance windows, with each wave verified before the next. The old environment stays intact until the new one has run clean.

Patching hypervisors and firmware in maintenance windows, monitoring capacity and hardware health, verifying backups actually restore, keeping the documentation current, and being the person who answers when something breaks. You get a short monthly report of what changed and what is trending toward a problem.

Backup jobs (Proxmox Backup Server, Veeam, or your existing tooling) are scheduled, monitored and — the part most setups skip — test-restored on a calendar. A backup that has never been restored is a hope, not a backup. Restore drills are part of the routine, and you see the results.

Yes, through a hardened VPN or bastion with out-of-band access (IPMI/iLO/iDRAC) for the bad days. I work with your on-site hands for anything physical — disk swaps, cabling — and everything else happens remotely, which is how most of my infrastructure work is done.

Month-to-month, no lock-in. Because the environment is documented and the runbooks are yours, handing over means changing who is on call, not reverse-engineering the setup. Several clients run day-to-day themselves and keep me only for upgrades and incidents.

When did you last restore a backup?

If that question made you uncomfortable, that is the call. Twenty minutes on your environment, and an honest answer about what needs attention first.