Infrastructure
The full domain, and the other capabilities within it.
Virtualization
Consolidate without turning one host's bad day into everyone's.
What this is
Virtualisation covers hypervisor cluster design, resource pools and reservations, availability policy, templates and patching. It is the platform most workloads sit on, and its design decides both density and blast radius.
Two things go wrong repeatedly. Clusters are sized so that a single host failure cannot be absorbed, and virtual machines are provisioned once and never revisited — so the estate grows on allocations nobody has checked against actual use.
When you need it
If more than one of these is true, this is usually the right place to start.
- A cluster with no capacity to run through the loss of one host.
- Virtual machines sized at creation and never reviewed, with allocation far above use.
- Snapshots kept for weeks, quietly consuming storage and slowing the machines they protect.
- A licensing model change that makes the current cluster shape expensive.
What the scope covers
- Cluster design and sizing, including the failure case the cluster must absorb without degradation.
- Availability and placement policy: what restarts where, in what order, and what must never share a host.
- Resource policy — reservations, limits and shares — set deliberately rather than left at defaults.
- Templates and patch baselines so new machines start compliant instead of being remediated later.
- Right-sizing review against measured use, with the licensing consequence made explicit.
What you receive
| Deliverable | What it contains |
|---|---|
| Cluster design | Host count and specification, admission control policy, and the failure case it is sized for. |
| Placement policy | Affinity and anti-affinity rules, restart priority, and which workloads must not share failure domains. |
| Template and patch standard | Base images per operating system, hardening applied, and the patch cycle that maintains them. |
| Right-sizing report | Allocation against measured use per machine, with reclaimable capacity quantified and the licence impact stated. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Capacity available under the single-host failure case, expressed as a percentage of normal load.
- Allocated versus consumed CPU and memory across the estate.
- Virtual machines built from the standard template rather than by hand.
Questions we are asked
How much spare capacity does a cluster need?
Enough to run the workload with the largest host gone, plus the maintenance window you need for patching. Admission control should enforce that rather than rely on the team remembering it during a busy provisioning week.
Why does over-allocation matter if the machines are idle?
Because allocation consumes scheduling capacity and, in most licensing models, money. Over-allocated machines also make capacity planning meaningless: you cannot tell what you need when the numbers describe requests rather than use.
Are snapshots a form of backup?
No, and treating them as one is a common and expensive mistake. A snapshot depends on the original storage; if that fails, the snapshot goes with it. They are a short-lived rollback mechanism, and long-lived ones degrade performance.
Should we consider a different hypervisor?
Licensing changes have made that a live question for many estates, and it is worth costing honestly. The migration effort is real — tooling, skills, integrations and backup software all follow the hypervisor — so the comparison has to include those, not just the licence line.
How does this relate to containers?
They coexist in nearly every estate. Containers change how applications are packaged and scheduled; the hypervisor usually remains underneath them. A plan that treats it as replacement rather than layering tends to underestimate the work.
Can right-sizing be automated?
Recommendations can be. Applying them should stay deliberate, because a machine that looks idle for a month may be the one that carries year-end. Automation proposes; a person with context approves.
Continue reading
Data Centre
Power, cooling, cabling and physical resilience designed together — with the environmental monitoring that turns a facility into something you can operate.
Backup & Disaster Recovery
Backup design, immutability and tested recovery against agreed RPO and RTO — because an untested restore is a belief, not a capability.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.