Machines Inside Machines

When you open an app on your phone, load a web page or ask an AI system a question, the request almost certainly ends up running inside a computer that does not physically exist. It runs in a virtual machine or a container: a software construction that behaves like a computer, with its own memory, its own operating system and its own network address, while sharing a physical server with dozens or thousands of others. Amazon reported in 2020 that a single virtualization system it built, called Firecracker, handled “trillions of requests per month” for its serverless computing services.¹ Most people never think about this layer. Nearly everything on the internet depends on it.

There is something philosophically strange about this arrangement. The most important computers in the world are, in a precise sense, pretend computers. Programs run inside them believing they have a machine to themselves, and the illusion is so complete that most software cannot tell the difference. This essay asks why computing came to work this way: why, after inventing a machine that could do anything, engineers decided the best way to use it was to make it pretend to be many machines. The answer runs through sixty years of history, from a small IBM lab in Cambridge, Massachusetts, to the data centres that now train artificial intelligence. It also reveals a shifting philosophy, from a perfect illusion, to honest cooperation, to a world in which the simulated machines no longer fully trust the machine that simulates them.

The world before: a machine everyone had to share

In the early 1960s, a computer was a room-sized, extremely expensive machine, and an organisation typically had one. Its time was precious, so it was used in batch mode. People prepared jobs on punched cards; operators ran them in sequence; results came back hours or days later. Robert Creasy, who would lead the first virtual machine project, later described the experience: “The turnaround time of a job from submission to completion was measured in hours, sometimes days. The prescheduling of jobs resulted in more efficient machine utilization, but the users were more isolated from the machine. Developing and testing programs was a frustrating experience.”²

The first answer to that frustration was time-sharing. At MIT, the Compatible Time-Sharing System, first operational in 1961, let several people at terminals use one computer at once, while ordinary batch jobs continued to run in the background. Creasy singled out its central trick: “The time-sharing supervisor would steal and restore the machine without their knowledge.”³ The batch programs never noticed that the machine was repeatedly taken away and given back. They behaved as if they had it to themselves.

That small deception, a program running unaware that the machine beneath it was being shared, is the seed of virtualization. What came next took it to its logical limit.

The problem of a machine meant to last

In the spring of 1964 IBM announced System/360, a family of computers of different sizes and prices that would all run the same software. Creasy called it “a most amazing turning point in computer development, one which was not universally greeted with enthusiasm.” His group at IBM’s Cambridge Scientific Center reasoned that the architecture “would be around for a significant period of time,” and “speculated that many operating systems and a large number of application programs would be produced over the lifetime of that machine design.”⁴

That raised a design question. “How could we design a single operating system to accommodate all of these programs in a smooth and compatible way? What interface and capabilities could be designed to support such a wide range of applications?”⁴

Their answer was strikingly simple, and it is the founding idea of virtualization. “Going back to basics turned up the answer: The instruction set, the essence of this new machine line as documented by the System/360 principles of operation manual, would be the interface to the time-sharing control program. Each user would have the complete capability of the System/360. Machine sharing and allocation would be accomplished below this level by the Control Program.”⁴

In other words: instead of designing a new interface that every program would have to learn, give every user a complete copy of the machine itself. Any program, any operating system, written for System/360 would run unchanged, because from its point of view it was running on a System/360. The sharing would happen invisibly underneath.

How a machine pretends to be itself

The trick depended on a feature of the System/360 hardware. The processor had two states, which Creasy describes: “privileged and problem.” Ordinary instructions, the ones applications use, “are innocuous to other programs within the same machine and can be safely executed.” But “privileged instructions affect the entire machine as well as report its status. As they are encountered in problem state, the machine blocks their execution and transfers control to a designated program.”⁴

That gave Creasy’s team a way to build a machine inside a machine. “When using CP, each virtual machine program is actually executed in problem state. The effects of privileged instructions are reproduced by CP within the virtual machines.”⁴ Each guest operating system believes it is in charge of the machine. Whenever it tries to do something that would affect the whole machine, the hardware stops it and hands control to the Control Program, which performs the operation on the guest’s behalf, adjusted so that it affects only that guest’s simulated world, and then lets the guest continue. This technique later became known as trap and emulate.

Creasy’s group split the system into two parts. CP, the Control Program, “uses a computing machine to simulate multiple copies of the machine itself.” CMS, the Conversational Monitor System, was a simple operating system for one person, run inside each virtual machine. The point of the split, Creasy explains, was “the bifurcation of computer resource management and user support.” CP “solved the problem of multiple use by providing separate computing environments at the machine instruction level for each user. CMS then provided single user service unencumbered by the problems of sharing, allocation, and protection.”³ Each person got a simple, personal computer, while the hard problems of sharing were solved once, underneath.

The system was first called a “pseudo-machine time-sharing system,” and was renamed a virtual machine system, Creasy notes, “from the description of similar but independent ideas.”³ The term stuck.

Recursion and reproduction

Creasy’s account includes an unusual intellectual influence. “Recursive systems, such as biological reproduction and to some extent the early LISP design, exhibit powerful, elegant concepts which influenced the CP/CMS system design. In reproduction, the cell is duplicated including the duplication mechanism.”³ A virtual machine that is a complete copy of the real machine can, in principle, run its own Control Program, which creates further virtual machines inside it. The system could reproduce itself, mechanism and all. This idea, now called nested virtualization, is used in cloud computing today.

From experiment to product

CP-40 ran in 1966 on a specially modified System/360 Model 40 at Cambridge. CP-67 followed on the Model 67, the first System/360 with hardware for virtual memory, and went into production use in 1967. IBM released VM/370 as a product in 1972 for the System/370 line, all of whose machines included virtual memory hardware. By 1981, Creasy reported, CP and CMS had seen “continuous production use since 1967 with over 2500 systems now in operation.”³

Virtual machines found several uses. They let many people share a mainframe interactively. They let system programmers develop and test new operating systems without taking the machine away from everyone else. They let organisations run several different operating systems on one machine at once. And they turned out to be a strong form of isolation: a crash in one virtual machine affected no other.

Creasy, writing in 1981, saw something else coming. Personal computers were arriving, “machines dedicated to a single user,” and he predicted that “these machines will not be isolated in laboratories. They will be interconnected in many ways.” Computing, he wrote, “has come full circle to repeat history.”² He was right in ways he could not have foreseen. The interconnected personal computers would eventually lead back to giant shared machines, and those machines would be virtualized.

The theory: when is a virtual machine possible?

By the early 1970s virtual machines worked on IBM hardware, but there was no general account of what a computer needed in order to support them. In 1974 Gerald Popek and Robert Goldberg published “Formal Requirements for Virtualizable Third Generation Architectures,” which gave one.⁵

They defined a virtual machine monitor, the program that creates virtual machines and is now usually called a hypervisor, by three properties. Equivalence: a program running under the monitor should behave essentially identically to the way it would on the real machine. Resource control: the monitor must be in complete control of the machine’s resources; no guest can take them without permission. Efficiency: the great majority of the guest’s instructions must run directly on the hardware, without the monitor’s intervention, so that the virtual machine is not much slower than the real one.

To state when this is possible, they divided instructions into kinds. Privileged instructions are those that trap, hand control to the operating system, when executed in the unprivileged user mode. Sensitive instructions are those that either change the configuration of the machine, or behave differently depending on that configuration, such as which mode the processor is in. Their central theorem said, in essence, that an efficient virtual machine monitor can be built if every sensitive instruction is also privileged. If that is true, any instruction that could reveal or disturb the illusion will trap, and the monitor gets the chance to handle it. If it is not true, some sensitive instruction can execute quietly in a guest, and the guest will see the real machine, or change it, without the monitor knowing.

The theory explained why Creasy’s approach had worked on System/360, and it gave hardware designers a checklist. A machine that met it could be virtualized by trap and emulate. A machine that did not would need some other, harder method.

The eclipse: when every user had a machine

Then, for a long time, virtualization mostly disappeared outside the mainframe world. The reason was the success of the very thing Creasy had predicted. As minicomputers and then personal computers became cheap, the problem virtualization solved, sharing one scarce machine among many people, became less pressing. If everyone has their own computer, there is no need to pretend that one computer is many.

The processors that came to dominate personal computing, Intel’s x86 family, were not designed with virtualization in mind. In 2000, John Scott Robin and Cynthia Irvine published a careful analysis of the Pentium’s instruction set against the Popek and Goldberg requirements. Their finding was blunt: “the Pentium instruction set contains sensitive, unprivileged instructions. The processor will execute unprivileged, sensitive instructions without generating an interrupt or exception. Thus, a VMM will never have the opportunity to simulate the effect of the instruction. After examining each member of the Pentium instruction set, it was found that seventeen instructions violate” the requirement, which “make the Intel processor non-virtualizable.”⁶

A simple example illustrates the problem. On the x86, an instruction called POPF restores a set of processor flags, including one that controls whether hardware interrupts are enabled. When an operating system kernel runs it in privileged mode, it changes that flag. When the same instruction runs in unprivileged mode, it does not trap; it simply, silently, leaves the interrupt flag unchanged. A guest kernel, running unprivileged inside a virtual machine, would execute POPF believing it had disabled interrupts, the monitor would never be told, and the guest’s view of reality would quietly diverge from the truth. Trap and emulate cannot handle an instruction that never traps.

So by the late 1990s, the world’s most common computers could not be virtualized by the classic method, at the very moment when a new problem was about to make virtualization valuable again.

The revival: making the unvirtualizable virtual

The new problem was the data centre. As businesses moved onto networked servers in the 1990s, it became common practice to run one major application per server, because running several applications on one operating system risked conflicts and failures. The result was large numbers of servers, each mostly idle, consuming power, space and administration. The old mainframe problem had returned in a new form: expensive machines, underused.

At Stanford, a research project called Disco, published in 1997 by Edouard Bugnion, Scott Devine and Mendel Rosenblum, revived the virtual machine monitor as a way to run ordinary operating systems efficiently on large multiprocessor machines. In 1998 Rosenblum, Bugnion, Devine and colleagues, together with Diane Greene and Edward Wang, founded VMware, and in 1999 it shipped VMware Workstation, which virtualized the x86 despite its unvirtualizable instructions.

How they did it was described in detail years later in a retrospective by the original engineers.⁷ The core idea was a combination of direct execution and dynamic binary translation. Ordinary application code ran directly on the processor, as fast as normal. Guest kernel code, which might contain the troublesome sensitive instructions, was translated on the fly: before it ran, the monitor scanned it, replaced the problematic instructions with safe sequences that did the right thing in the virtual world, cached the translation, and ran that instead. The guest operating system was never modified and never knew. VMware also made a pragmatic decision to run alongside an existing operating system on the user’s computer, a “hosted” design, so that it could use that system’s device drivers rather than writing its own for the vast variety of PC hardware.

This was an engineering achievement that made virtualization usable on the computers everyone already owned. VMware followed with server products, including ESX Server in 2001, which ran directly on the hardware without a host operating system, and in 2003 vMotion, which could move a running virtual machine from one physical server to another without stopping it. That last capability marked a philosophical turning point: a computer, with everything running on it, had become something that could be moved between pieces of hardware while it worked.

Xen: asking the guest to cooperate

A different answer came from the University of Cambridge in England. In 2003 a group led by Ian Pratt and including Paul Barham, Keir Fraser, Steven Hand and others published “Xen and the Art of Virtualization.” Their goal was a hypervisor that could host many commodity operating systems on one server safely, “but without sacrificing either performance or functionality.”⁸

Xen’s approach, paravirtualization, inverted VMware’s. Instead of fooling an unmodified guest, Xen asked the guest operating system to be modified slightly so that it cooperated with the hypervisor: rather than executing sensitive instructions and hoping to be caught, the guest kernel would call the hypervisor directly when it needed privileged operations. The applications inside the guest remained unchanged.

The paper set out its design principles, and they include a sentence that captures a genuine philosophical position. “Paravirtualization is necessary to obtain high performance and strong resource isolation on uncooperative machine architectures such as x86.” And: “Even on cooperative machine architectures, completely hiding the effects of resource virtualization from guest OSes risks both correctness and performance.”⁸ In other words, a perfect illusion is not always desirable. An operating system that knows it is virtualized can make better decisions, about time, about memory, about input and output, than one kept in the dark.

Xen was also motivated by a specific vision. Its authors were building toward what they called the XenoServer project, an infrastructure in which servers around the world would host untrusted code from anyone, safely. It was, in outline, a description of public cloud computing, three years before the term became common.

The hardware catches up

The difficulties of virtualizing the x86 had a direct solution: change the processor. Intel introduced its virtualization extensions, VT-x, in 2005, and AMD followed with AMD-V in 2006. These added a new mode of operation in which a guest operating system could run with what it believed was full privilege, while the hardware itself trapped the sensitive operations to the hypervisor. With these extensions, the x86 finally satisfied the Popek and Goldberg requirements.

The consequence was that virtualization became simpler to build and could become a standard feature of operating systems. In October 2006 Avi Kivity of the startup Qumranet announced KVM, the Kernel-based Virtual Machine, which turned the Linux kernel itself into a hypervisor using the new hardware features. It was merged into the mainline Linux kernel in version 2.6.20, released in February 2007.⁹ Microsoft shipped its own hypervisor, Hyper-V, in 2008. What had required heroic engineering in 1999 had become an ordinary operating system feature a few years later.

The cloud: computers rented by the hour

In 2006 Amazon launched Elastic Compute Cloud, EC2, which let anyone rent virtual machines by the hour. It was built initially on Xen. The idea Creasy had pursued, giving each user a complete machine carved out of shared hardware, had become a business that anyone with a credit card could use, at almost any scale.

The cloud changed what a computer was in practice. A server no longer had to be purchased, installed and maintained for years; it could be created in minutes, used for an afternoon and discarded. Machines became, in the phrase popularised in the industry, “cattle, not pets”: interchangeable instances created from a template, rather than individual servers with names and histories. Software was increasingly written to expect that any particular machine might disappear at any moment.

Over the following decade, cloud providers pushed virtualization deeper into hardware. Amazon’s Nitro System, first used for an entire instance family in 2017, moved the work of virtualizing storage and networking onto dedicated hardware cards and replaced the earlier Xen-based design with what its security documentation describes as “a custom-developed, minimized hypervisor based on KVM.”¹⁰ This closes a circle that Creasy anticipated in 1981, when he wrote that the apparent replication of the machine for each user “provided an avenue for future machine development whereby resource control could be incorporated into the machine architecture.”⁴ Forty years later, the machine had been redesigned around its own virtualization.

Containers: isolation without a second operating system

Virtual machines are heavy. Each runs a complete operating system, with its own kernel, memory and boot process. A different line of development asked whether isolation could be achieved more cheaply, by having many programs share one operating system kernel while each sees only its own restricted world.

The earliest step was small. Unix gained the chroot system call in 1979, which changes the directory a process sees as the root of the file system, so that it cannot see files outside a given subtree. It was a limited tool; a process with administrator privileges could escape it. In 2000 the FreeBSD developers Poul-Henning Kamp and Robert Watson introduced jails, which extended the idea to processes and networking, in a paper whose title stated the goal: “Jails: Confining the omnipotent root.” Solaris Zones followed in 2004. In Linux, the necessary pieces arrived over several years: namespaces, which give a group of processes their own view of system resources such as process numbers and network interfaces, and control groups, cgroups, which limit how much processor time, memory and input and output a group can use. Engineers at Google contributed cgroups, which they used internally to run many jobs on shared machines.

At Google, those mechanisms supported Borg, a cluster manager described publicly in 2015. Its paper explains that Borg “runs hundreds of thousands of jobs, from many thousands of different applications, across a number of clusters each with up to tens of thousands of machines,” and achieves high utilization by combining admission control, efficient task packing, over-commitment and “process-level performance isolation.”¹¹

What turned containers into a mass movement was not a new isolation mechanism but a new way of packaging software. In March 2013, Solomon Hykes, the founder of a hosting company called dotCloud, gave a five-minute lightning talk at the PyCon conference titled “The future of Linux Containers” and introduced Docker. Docker’s contribution was the image: a standard, layered package containing an application and everything it needs, which could be built once and run anywhere a Docker engine ran. Containers became a unit of software delivery, not just of isolation. In 2014 Google released Kubernetes, an open-source system for running containers across clusters, drawing on the lessons of Borg.

Containers and virtual machines embody different trade-offs. A virtual machine virtualizes the hardware: each guest has its own kernel, so a flaw in one guest’s kernel does not compromise another. A container virtualizes the operating system: all containers on a host share one kernel, which makes them far lighter and faster to start, but means that a flaw in the shared kernel can, in principle, break the walls between them.

The convergence: virtual machines as light as containers

By the late 2010s, cloud providers faced a dilemma that the Firecracker paper states precisely. Serverless computing, in which customers upload a function and the provider runs it on demand, requires running code from many customers on the same hardware, very quickly. “The traditional view is that there is a choice between virtualization with strong security and high overhead, and container technologies with weaker security and minimal overhead. This tradeoff is unacceptable to public infrastructure providers, who need both strong security and minimal overhead.”¹

Amazon’s answer, Firecracker, is a minimal virtual machine monitor built on KVM. It strips away almost everything a general-purpose hypervisor provides, emulating only a handful of devices, so that a microVM can boot to application code “in less than 125ms” and a single host can create “up to 150 MicroVMs per second.” It has run in production for AWS Lambda since 2018, where, the paper reports, it “powers millions of workloads and trillions of requests per month.”¹ Other approaches pursue the same convergence from the other side, adding stronger isolation around containers.

The two lines of development, heavy virtual machines and light containers, have come to meet in the middle: machines as quick to create as processes, with walls as strong as separate computers.

The limits of the illusion

In January 2018, researchers disclosed two families of security vulnerabilities, Meltdown and Spectre, rooted in the way modern processors speculatively execute instructions to run faster. The details are complex, but their significance for virtualization was simple. The walls between virtual machines are enforced in software and by the processor’s rules about what code may access. Speculative execution, it turned out, could leave traces in shared hardware, such as caches, that code on the other side of those walls could measure. Virtual machines sharing a physical processor were not as perfectly separated as the theory assumed.

The response included software patches, processor changes and, more fundamentally, a new idea about trust. In classic virtualization, the hypervisor is the trusted authority: it sees everything inside every guest. For customers running sensitive work on someone else’s hardware, that is itself a risk. Confidential computing technologies, such as AMD’s Secure Encrypted Virtualization and Intel’s Trust Domain Extensions, use hardware to encrypt a virtual machine’s memory so that even the hypervisor and the cloud operator cannot read it, and let customers verify remotely what software is running. Researchers continue to find side channels in these systems too, and their designers do not claim to eliminate all of them. But the direction is philosophically striking: the guest, once the object of the hypervisor’s benevolent illusion, now wants protection from the hypervisor itself.

What virtualization is today

Virtualization is now so pervasive that it is easier to say where it is absent than where it is present. Public cloud platforms run almost entirely on virtual machines and containers. Enterprises run large private virtualized infrastructures; VMware, the company that revived x86 virtualization, was acquired by Broadcom in a deal completed in November 2023. Developers run containers on their laptops; Windows runs Linux inside a lightweight virtual machine for developers. Functions in serverless platforms live for milliseconds inside microVMs.

Containers and Kubernetes have become the default way to run software at scale. The Cloud Native Computing Foundation’s survey for 2025 reported that “82% of container users now run Kubernetes in production, up from 66% in 2023,” and that “98% of surveyed organizations reported that they have adopted cloud native techniques.”¹²

Artificial intelligence has given virtualization a new frontier. The same survey found that “66% of organizations hosting generative AI models use Kubernetes to manage some or all of their inference workloads.”¹² Graphics processors, the most valuable hardware in a modern data centre, are now virtualized too. NVIDIA’s Multi-Instance GPU technology, introduced with its A100 processor, can partition a single GPU “into up to seven GPU instances, isolated and secured at the hardware level,” each with its own compute units, memory and cache.¹³ The logic is exactly Creasy’s: a scarce, expensive machine, divided so that many users can each act as if they had their own.

Understanding the philosophy

Virtualization raises philosophical questions more directly than almost any other technology, because its entire purpose is to create convincing appearances. What follows takes the main ideas embedded in its history one at a time. Each is explained in plain terms, connected to the philosophical tradition that has thought hardest about it, traced in the history above, tested against its strongest objection, and related to computing today. The connections to named philosophers are interpretations offered to make the ideas understandable; except where noted, the engineers involved did not cite them.

1. If no test can tell them apart, are they the same?

The idea in plain terms

A virtual machine counts as a machine because, from the inside, nothing distinguishes it from a real one. If every instruction behaves the same, every result comes out the same, and no program can detect a difference, then for the program there is no difference.

The tradition

The philosopher Gottfried Wilhelm Leibniz proposed a principle now called the identity of indiscernibles: if two things share all their properties, so that nothing could distinguish them, they are the same thing. A more modern relative is Alan Turing’s 1950 proposal to replace the question “can machines think?” with a test of whether a machine’s conversation could be distinguished from a person’s. Both make indistinguishability the measure of identity, or at least of what matters.

Where it shows up

Popek and Goldberg’s first requirement, equivalence, is a precise engineering version of this principle: a program under the monitor should behave “essentially identically” to the way it would on the real machine.⁵ Creasy’s design goal, that “each user would have the complete capability of the System/360,” rests on the same idea: a virtual System/360 that no program could distinguish from a real one is, for every practical purpose, a System/360.

The strongest objection

Virtual machines are never perfectly indistinguishable. Timing reveals them: some operations take longer under a hypervisor, and a program that measures carefully can often tell. Security researchers in the mid-2000s demonstrated simple “red pill” techniques for detecting virtualization, named after the film The Matrix. Spectre and Meltdown showed that shared hardware can leak information across the boundary. Equivalence is, in practice, equivalence for well-behaved programs, not for every possible observer.

What it means today

Virtualization works because almost all software is content to judge its world by the results of its instructions, not by stopwatches. When software does start measuring closely, as malware sometimes does to avoid analysis, or as attackers do to probe for leaks, the philosophical gap between “indistinguishable for practical purposes” and “identical” becomes a security question.

2. The demon in the machine

The idea in plain terms

A guest operating system has no way to step outside its virtual machine and check what is really there. Everything it knows about its hardware comes through the hypervisor, which could, in principle, show it anything.

The tradition

In his Meditations on First Philosophy (1641), René Descartes imagined an evil demon “of the utmost power and cunning” devoting all its energies to deceiving him, so that the sky, colours, shapes and sounds he perceived might all be illusions. The thought experiment was meant to find what could be known for certain if everything else were doubted. Later philosophers updated it as the brain in a vat, connected to a computer that feeds it experiences, and in 2003 Nick Bostrom’s simulation argument asked whether we ourselves might be living in a computer simulation.

Where it shows up

The hypervisor is, quite literally, the demon of Descartes’s thought experiment relative to its guests. It controls every input a guest receives from its hardware: the clock, the memory, the disks, the network. CTSS’s supervisor that would “steal and restore the machine without their knowledge” was a benevolent version of the demon.³ So is every hypervisor since.

The strongest objection, and the turn toward honesty

The demon’s deception is benevolent, but deception has costs. Xen’s designers argued that “completely hiding the effects of resource virtualization from guest OSes risks both correctness and performance,” and chose paravirtualization, in which the guest knows it is virtualized and cooperates.⁸ A guest that knows the truth about its situation can make better decisions, about timekeeping, about scheduling, about memory. Modern systems combine both approaches: hardware support provides the illusion where it is useful, while paravirtualized drivers and interfaces tell the guest the truth where honesty works better.

What it means today

The history of virtualization moved from pure illusion toward selective honesty. That is a design principle worth noting beyond computing: systems that conceal their nature completely from their users can be elegant, but systems that tell users enough of the truth often work better.

3. Universality made practical

The idea in plain terms

In principle, any general-purpose computer can imitate any other. Virtualization is the art of doing that efficiently, and in particular of having a machine imitate itself many times over.

The tradition

Alan Turing showed in 1936 that a single universal machine, given a description of any other machine, could simulate it. That is the theoretical foundation of all programmable computing. Creasy added a biological image: “In reproduction, the cell is duplicated including the duplication mechanism,” and he cited this, along with the self-describing structure of LISP, as an influence on CP/CMS.³

Where it shows up

A virtual machine is Turing’s universality made fast enough to be useful, by running most instructions directly on the hardware rather than simulating them step by step. Nested virtualization, a virtual machine running its own hypervisor and its own virtual machines, is Creasy’s self-reproducing cell made real.

The strongest objection

Universality in principle is not universality in practice. Simulating one machine on another can be thousands of times slower, which is why Popek and Goldberg’s efficiency requirement was essential, and why the x86 needed binary translation, paravirtualization and finally new hardware before virtualization became practical. Theory said it was possible; economics decided when it happened.

What it means today

Virtualization illustrates a pattern explored in the essay on compute on this site: universality is a mathematical fact, but its price is set by physics and engineering, and the history of computing is the history of that price changing.

4. A computer separated from its matter

The idea in plain terms

With virtualization, a computer becomes a pattern rather than a physical object. The same running machine can be moved from one physical server to another, copied, paused, restored or started from a template thousands of times.

The tradition

Aristotle analysed objects as compounds of matter and form. A bronze statue is bronze (its matter) shaped in a particular way (its form). The form is what makes it this statue; the bronze could, in principle, be melted and recast. This view, called hylomorphism, raises a question that virtualization makes concrete: is a thing its form or its matter?

Where it shows up

vMotion, which moved a running virtual machine between physical servers in 2003, separated the form of a computer, its running state, from its matter, the hardware, while it worked. The cloud industry’s “cattle, not pets” principle goes further: a server’s identity lies in the image it was created from, not in any particular instance. If an instance fails, another is created from the same description. Containers made the image, the form, the unit of software delivery.

The strongest objection

Not everything can be treated as interchangeable. Databases, user files and long-running services carry state that is particular and cannot simply be recreated from a template. The cattle principle works for the stateless parts of a system and becomes dangerous when applied to the parts that remember. Matter, in the form of stored data, reasserts itself.

What it means today

Modern architectures deliberately separate what can be disposable, the computation, from what must persist, the data. That separation is a direct consequence of virtualization’s detachment of form from matter, and it shapes how almost all large systems are now built.

5. Who guards the guardian?

The idea in plain terms

Virtualization makes the hypervisor a guardian that protects guests from each other. But the guardian itself sees everything inside every guest. If you do not trust the guardian, the protection becomes a vulnerability.

The tradition

The Roman poet Juvenal asked, “Quis custodiet ipsos custodes?” Who will guard the guards themselves? The question became central to political philosophy: any power strong enough to protect people is strong enough to harm them, so protection requires mechanisms that constrain the protector.

Where it shows up

Popek and Goldberg’s resource control requirement makes the hypervisor the complete authority over its guests.⁵ For decades this was simply assumed to be good. In the public cloud, where the hypervisor belongs to a provider and the guests to its customers, the question changed. Confidential computing, which encrypts virtual machine memory so that even the hypervisor cannot read it and lets customers verify remotely what is running, is a technical answer to Juvenal: it constrains the guardian with hardware and makes its behaviour checkable.

The strongest objection

Constraining the guardian moves trust rather than removing it. Confidential computing asks customers to trust the processor manufacturer’s hardware and attestation systems instead of the cloud operator, and researchers continue to find side channels in these systems. There is always some final layer that must simply be trusted.

What it means today

As more sensitive computation, including AI training on private data, runs on shared infrastructure, the question of who guards the guardian has moved from political philosophy into chip design and procurement contracts.

6. Efficiency that leads to abundance

The idea in plain terms

Virtualization made servers far more efficient by filling idle machines with work. One might expect that to reduce the number of servers the world needs. Instead, computing grew enormously.

The tradition

In The Coal Question (1865), the economist William Stanley Jevons observed that more efficient steam engines had not reduced Britain’s consumption of coal; they had increased it, because efficiency made coal-powered work cheaper and therefore more widely used. This Jevons paradox has been observed for many resources since.

Where it shows up

Server consolidation was one of virtualization’s first commercial justifications in the 1990s and 2000s: fewer physical machines doing the same work. But by making computing cheap, elastic and available by the hour, virtualization and the cloud enabled vast new uses of computing, and the total number of servers and data centres grew. The same pattern recurs with containers, which made running many small services cheaper, and with GPU partitioning, which makes AI hardware available to more users.

The strongest objection

The Jevons effect does not mean efficiency is bad. Each unit of useful work uses less energy and hardware than it otherwise would. The paradox describes total consumption, which grows because people find more valuable things to do. Whether that growth is good depends on what the computing is used for.

What it means today

As data-centre energy use becomes a public concern, the Jevons paradox is a reminder that efficiency alone does not reduce total consumption. Decisions about what to compute matter as much as how efficiently it is done.

7. From owning a computer to having access to one

The idea in plain terms

For most of computing’s history, using a computer meant owning one. Virtualization made it possible to rent a slice of a computer for an hour, or a millisecond, and the cloud turned access into the normal arrangement.

The tradition

In The Age of Access (2000), the social theorist Jeremy Rifkin argued that economies were shifting from the ownership of goods to paid access to services and experiences. The philosophical question behind it is what changes when people use things they do not own: who controls them, who is responsible for them, and what happens when access is withdrawn.

Where it shows up

Creasy’s CP/CMS was already an access model: users did not own the mainframe but each had a machine within it. The personal computer era reversed this, making ownership normal. The cloud reversed it again, at a far larger scale. Serverless platforms push it to the limit: a customer’s code exists only while it runs, on hardware they will never see.

The strongest objection

Access brings real freedom: no up-front cost, unlimited scale, no maintenance. Many organisations could not afford to own what they now rent. And ownership has its own burdens, which is why the cloud spread so quickly.

What it means today

Organisations increasingly ask what they should own and what they should rent, weighing flexibility against dependence on providers. Some workloads have moved back to owned hardware for cost or control. The question Rifkin raised about society is, in computing, a daily architectural decision.

Bringing the threads together

Virtualization’s history traces a philosophical arc. It began with an illusion: the machine pretends to be many, and each user acts as if alone. Popek and Goldberg made indistinguishability a formal requirement, a Leibnizian test of identity. When the illusion became too costly to maintain on uncooperative hardware, Xen chose honesty, telling guests the truth about their situation. When hardware caught up, the illusion became cheap and universal, and the cloud separated computers from their matter, turning them into forms that can be copied, moved and discarded. And when the guardians of the illusion became other companies, the guests began to demand protection from the guardian itself.

The question at the start was why computing decided that the best way to use a computer was to pretend it was many. The answer is that sharing is efficient, isolation is safe, and a computer separated from its hardware is free to move, multiply and disappear as needed. But the deeper lesson is about appearances. Every layer of virtualization is a convincing appearance resting on something real, and every generation has had to decide how much of the reality behind the appearance its occupants should be allowed to see, and whom they must trust to keep it true.

Selected bibliography

• Creasy, R. J. “The Origin of the VM/370 Time-Sharing System.” IBM Journal of Research and Development 25, no. 5 (September 1981): 483–490. doi:10.1147/rd.255.0483
• Popek, Gerald J., and Robert P. Goldberg. “Formal Requirements for Virtualizable Third Generation Architectures.” Communications of the ACM 17, no. 7 (1974): 412–421.
• Bugnion, Edouard, Scott Devine, and Mendel Rosenblum. “Disco: Running Commodity Operating Systems on Scalable Multiprocessors.” Proceedings of SOSP (1997).
• Robin, John Scott, and Cynthia E. Irvine. “Analysis of the Intel Pentium’s Ability to Support a Secure Virtual Machine Monitor.” Proceedings of the 9th USENIX Security Symposium (2000): 129–144. PDF
• Barham, Paul, et al. “Xen and the Art of Virtualization.” Proceedings of SOSP (2003). PDF
• Bugnion, Edouard, Scott Devine, Mendel Rosenblum, Jeremy Sugerman, and Edward Y. Wang. “Bringing Virtualization to the x86 Architecture with the Original VMware Workstation.” ACM Transactions on Computer Systems 30, no. 4 (2012). doi:10.1145/2382553.2382554
• Kamp, Poul-Henning, and Robert N. M. Watson. “Jails: Confining the Omnipotent Root.” Proceedings of SANE (2000).
• Verma, Abhishek, et al. “Large-Scale Cluster Management at Google with Borg.” Proceedings of EuroSys (2015). Google Research
• Agache, Alexandru, et al. “Firecracker: Lightweight Virtualization for Serverless Applications.” Proceedings of NSDI (2020). PDF
• Amazon Web Services. The Security Design of the AWS Nitro System. Whitepaper. docs.aws.amazon.com
• Cloud Native Computing Foundation. Annual Cloud Native Survey 2025. January 2026. cncf.io
• NVIDIA. “Getting the Most Out of the A100 GPU with Multi-Instance GPU.” NVIDIA Technical Blog. developer.nvidia.com
• Descartes, René. Meditations on First Philosophy. 1641.
• Turing, Alan M. “Computing Machinery and Intelligence.” Mind 59 (1950).
• Bostrom, Nick. “Are You Living in a Computer Simulation?” Philosophical Quarterly 53 (2003).
• Jevons, William Stanley. The Coal Question. 1865.
• Rifkin, Jeremy. The Age of Access. Tarcher/Putnam, 2000.

Research limitations

Creasy’s 1981 paper is a participant’s account written fifteen years after the events, and is used here for IBM’s design reasoning; the name of the parallel IBM project from which the term “virtual machine” was taken is not given in that paper and is not asserted here. Popek and Goldberg’s definitions are summarised from standard descriptions of their paper rather than quoted from its full text. Robin and Irvine count seventeen problematic Pentium instructions; other summaries give eighteen, depending on how instructions are grouped, and the primary paper’s figure is used. The account of Disco and the founding of VMware draws on the engineers’ 2012 retrospective and company histories. EC2’s initial use of Xen and the dates of the Intel and AMD virtualization extensions are stated from widely documented history rather than primary announcements. The “cattle, not pets” phrase is an industry metaphor whose origin is attributed in different ways and is not attributed here. The CNCF survey describes its respondents, not all organisations. The philosophical section’s connections to Leibniz, Turing, Descartes, Bostrom, Aristotle, Juvenal, Jevons and Rifkin are the author’s interpretation, offered to make the ideas understandable; only Creasy’s reference to biological reproduction and LISP comes from the engineers themselves.

Footnotes

1. Alexandru Agache et al., “Firecracker: Lightweight Virtualization for Serverless Applications,” Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’20), abstract and §1. ↩ ↩² ↩³

2. R. J. Creasy, “The Origin of the VM/370 Time-Sharing System,” IBM Journal of Research and Development 25, no. 5 (1981), p. 484. ↩ ↩²

3. Creasy (1981), p. 485. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

4. Creasy (1981), pp. 485–486, section “Hardware influence.” ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

5. Gerald J. Popek and Robert P. Goldberg, “Formal Requirements for Virtualizable Third Generation Architectures,” Communications of the ACM 17, no. 7 (1974): 412–421; definitions as summarised in Wikipedia: Popek and Goldberg virtualization requirements. ↩ ↩² ↩³

6. John Scott Robin and Cynthia E. Irvine, “Analysis of the Intel Pentium’s Ability to Support a Secure Virtual Machine Monitor,” Proceedings of the 9th USENIX Security Symposium (2000), §3. ↩

7. Edouard Bugnion et al., “Bringing Virtualization to the x86 Architecture with the Original VMware Workstation,” ACM Transactions on Computer Systems 30, no. 4 (2012). ↩

8. Paul Barham et al., “Xen and the Art of Virtualization,” Proceedings of the 19th ACM Symposium on Operating Systems Principles (2003), abstract and §2. ↩ ↩² ↩³

9. Wikipedia: Kernel-based Virtual Machine; LWN.net retrospective on KVM’s first decade. ↩

10. Amazon Web Services, The Security Design of the AWS Nitro System, “The Nitro System journey.” ↩

11. Abhishek Verma et al., “Large-scale cluster management at Google with Borg,” Proceedings of EuroSys (2015), abstract. ↩

12. Cloud Native Computing Foundation, “New CNCF Annual Cloud Native Survey reveals near-universal adoption of Kubernetes,” 20 January 2026. ↩ ↩²

13. NVIDIA, “Getting the Most Out of the A100 GPU with Multi-Instance GPU,” NVIDIA Technical Blog. ↩