Server virtualisation: what it buys and what it does not

Virtualisation stopped being a decision some years ago. New physical servers running a single operating system directly are now unusual outside specific cases, and for good reasons.

What has not settled is what businesses believe it provides. Two beliefs in particular cause real damage: that a virtualised estate is inherently more available, and that snapshots are a form of backup. Neither is true, and both are usually discovered during the incident that disproves them.

What it genuinely provides

The real gains are worth stating precisely, because they are the ones to design around.

Two of those are more valuable than they first appear. Independent patching is what makes proper role separation practical — the reason businesses pile roles onto one machine is usually that separating them meant buying hardware. And hardware abstraction removes the specific pain of a server refresh, which otherwise means rebuilding and re-testing every workload on new physical machines.

Snapshots are not backups

This is the single most costly misunderstanding in the subject, and it is nearly universal.

A snapshot records a point in time by capturing subsequent changes separately, so the machine can be returned to that point. It is genuinely useful for exactly one thing: reverting a change you are about to make, within minutes or hours.

It is not a backup, for reasons that are structural rather than incidental.

• It lives on the same storage as the machine. Storage failure takes the snapshot with the original.
• It depends on the original. It is a record of differences, not an independent copy — losing the base disk makes the snapshot worthless.
• It is reachable by anyone who compromises the hypervisor, which is exactly what ransomware operators target once they have administrative access.
• It degrades performance the longer it exists, because every read must reconcile the difference chain.
• Left in place for weeks it can consume enough storage to fill the datastore, which takes down every machine on it — a snapshot causing the outage rather than preventing one.

Virtualisation is not availability

Consolidating ten servers onto one host does not make them more available. It makes them share a failure. The host is now a single point of failure for ten workloads that previously failed independently.

Virtualisation makes availability achievable, which is a different claim. Clustering, live migration and replication are the features that provide it, and they must be deliberately configured. A single host with ten virtual machines and no cluster is a concentration of risk, not a reduction of it.

This matters most where redundancy was assumed. Two domain controllers, two application servers, two of anything — running on the same host, they are one hardware fault away from none. The redundancy exists on the diagram and not in the failure domain.

Sizing: the part that goes wrong quietly

Virtualisation permits overcommitting resources — allocating more to virtual machines than the host physically has — on the reasonable basis that workloads do not all peak together. How far that can be taken differs sharply by resource, and treating them the same is the usual error.

Storage is where estates actually run into trouble. CPU and memory are watched because the console displays them prominently. Storage throughput is not, and it is shared by every machine on the host, so one noisy workload degrades everything else in a way that looks like a general slowness with no obvious cause.

Thin provisioning deserves its own warning. Allocating more storage than exists works until the machines actually use it, and the failure is not gradual — the datastore fills and every virtual machine on it stops. Monitoring actual consumption against physical capacity, with enough headroom to react, is not optional where thin provisioning is used.

Where virtualisation is not the right answer

• Workloads requiring direct hardware access or precise timing. Some telephony, industrial control and specialist hardware cases still run better on physical machines, and pass-through is a partial answer with its own constraints.
• A single workload on a single machine. If the business runs one server, virtualising it adds a layer to administer and patch for no consolidation benefit. The abstraction benefit may still justify it; the consolidation one does not exist.
• Licensing that punishes it. Some vendors license by physical core on the host regardless of what the virtual machine is allocated, which can make a small virtual machine on a large host surprisingly expensive. Check before designing.
• Where the real answer is containers. For multiple instances of the same application stack, containers provide isolation with far less overhead. They are not a replacement for virtualisation — they usually run on it — but they are the better unit for that specific case.

Running it properly

1. 1

   Keep the host doing one job

   The hypervisor host runs the hypervisor. Nothing else installed, nothing else logged into. It is the machine that can see and alter every workload you have.

2. 2

   Check what shares a failure domain

   Anything you consider redundant should be on separate hosts, separate power and separate storage. This is the single most common design fault in virtualised estates.

3. 3

   Back up the guests properly, not just the host

   With a backup product that understands the hypervisor and can restore an individual machine. And test that restore — the whole-estate backup that has never been restored is the same assumption as any other.

4. 4

   Enforce a snapshot policy

   Take before a change, delete after. Alert on snapshots older than a defined age. This prevents both the storage incident and the false sense of protection.

5. 5

   Monitor storage throughput, not just capacity

   It is the resource most likely to be the actual constraint and the one least likely to be watched.

6. 6

   Patch the hypervisor on a schedule

   It is exposed, privileged, and frequently the least-patched software in the estate because upgrading it means moving workloads.

7. 7

   Document what runs where

   Virtual machines are easy to create and therefore easy to forget. An estate accumulates machines nobody can identify, which are unpatched, consuming resources and holding data.