Almost everything in this catalogue was invented once and improved since. This one was invented, abandoned, formally proved impossible on the hardware that mattered, and then built anyway - which makes it the best cautionary tale available about the word impossible.

January 1967: it already worked

CP-40, IBM's research system at the Cambridge Scientific Center, went into production use in January 1967 and is widely credited as the first hypervisor - a program whose job is to run other operating systems. It became CP-67, and then /370 in 1972, which IBM shipped to mainframe sites worldwide.

Two details from the period are worth carrying because they contradict how the technology is usually justified today.

Performance was never the goal. Overhead on VM/370 was estimated at ten to fifteen per cent, and the people who built it did not consider efficient execution a primary objective - the aim was efficient utilisation of an expensive machine. The trade was judged worthwhile partly on security grounds.

Isolation was understood immediately. Running several operating systems on one machine, each unable to touch the others, was recognised as a security property in the 1960s and did not need rediscovering.

The disappearance

Minicomputers and then personal computers collapsed the economics. If hardware is cheap and personal, there is no reason to share it, and virtualisation survived only inside mainframe shops for roughly fifteen years.

That is a pattern worth naming, because it recurs: a technology does not survive on merit, it survives on whether the constraint that produced it still exists. When hardware became expensive again - as a datacentre full of underused servers - the constraint returned and so did the technology.

The formal impossibility

Popek and Goldberg set out the formal requirements for virtualisable architectures in the mid-1970s. Intel's x86 did not satisfy them.

A 2000 USENIX Security paper by John Robin and Cynthia Irvine made this precise: seventeen x86 instructions were sensitive but unprivileged - able to read or alter privileged state, and failing silently in user mode instead of trapping to the supervisor. A hypervisor cannot intercept what does not trap.

For two decades, virtualisation on commodity hardware was considered formally impossible. The proof was correct. The conclusion drawn from it was wrong, and the difference between those two statements is the whole lesson: the analysis showed it could not be done the expected way, and everyone read it as showing it could not be done.

1997 to 1998: doing it anyway

At Stanford, Mendel Rosenblum with doctoral students Edouard Bugnion and Scott Devine published Disco, running commodity operating systems on hardware they were not designed for. VMware followed in 1998, founded by Rosenblum, Diane Greene as chief executive, Bugnion, Devine and Edward Wang.

Their answer was binary translation: rewrite the kernel code as it runs, replacing the instructions that would fail silently. It is an ugly solution to an elegant impossibility, and it made x86 virtualisation commercially viable seven years before Intel and AMD added hardware support in the mid-2000s.

Note the sequence, because it inverts the usual story. The chip vendors added virtualisation support after a software company proved there was a market, not before. Hardware followed demand that software had already created.

The other lineage: containers

Containers did not descend from virtual machines. They descend from a command.

chroot, introduced in Unix Version 7 in 1979, changes the apparent root directory for a process. It was not designed for security or for virtualisation, and it was the first step toward both anyway. FreeBSD jails in 2000 and Solaris containers in 2004 hardened the idea, and and control groups turned it into a general mechanism that Docker made usable in 2013 and made schedulable a year later.

The two lineages answer different questions and the confusion between them is expensive. A virtual machine virtualises the hardware; a container partitions the operating system. One gives you a different kernel and a strong boundary at higher cost; the other gives you a shared kernel and a weaker boundary at almost no cost. Choosing between them is a decision about what you are isolating from, and treating a container boundary as equivalent to a hypervisor boundary is the single most common mistake in this family.

Jobs and practices

This family did more to reshape operational work than anything except the SDN article's subject, and largely by removing scarcity: when a server takes minutes rather than weeks, everything downstream changes.

It created sprawl as a discipline problem. The machine that is trivial to create is trivial to forget, and every estate accumulates instances nobody owns - which is the same accumulation problem as firewall rules and directory entries, appearing for the third time in this series.

It created the image as the unit of work, and with it the supply chain question the industry is still answering: what is in the base image, who built it, and when was it last rebuilt.

And it created the snapshot - the ability to capture and restore state - which changed backup, testing and forensics simultaneously, and which is why virtualisation is discussed in incident response as often as in capacity planning.

The companies

IBM built it and kept it inside the mainframe. VMware defined the commercial market and was bought by Broadcom; Xen and KVM carried the open lineage into the cloud providers, whose entire businesses rest on this technology; Docker created the container market and struggled to monetise it; and Kubernetes, donated by Google to a foundation, became the scheduling layer nearly everyone standardised on.

Where it goes

The boundary keeps being renegotiated. Lightweight virtual machines that start in milliseconds exist because the industry wants container speed with hypervisor isolation, which is an admission that the container boundary was never quite enough for multi-tenant workloads.

Confidential computing extends it to the operator. Encrypted memory and attestation aim at a threat the 1967 design never considered: protecting a guest from the platform running it.

The unit keeps shrinking. Machine, then instance, then container, then function - each step trading isolation and control for density and speed, and each step re-learning the same operational lessons about what happens when creating something becomes free.

And the founding property is unchanged. CP-40 ran other operating systems on one machine so an expensive resource would not sit idle. Every layer since has been a variation on that sentence. The technology disappeared for fifteen years not because it stopped working but because the reason for it went away - which is worth remembering whenever something in this industry is declared obsolete.

Sources