What is a temporary virtual machine?

A virtual machine is a computer built out of software. Something pretends to be a processor, some memory, a disk and a screen, and an operating system runs on top without ever discovering that none of it is real. A temporary virtual machine adds one property: nothing about it is meant to survive. Close it and it is gone — no disk left behind, no state to clean up. Those two properties usually arrive bundled together in people's heads, and they should not. Virtualisation is a technique. Disposability is a policy. The industry worked the second one out on servers a decade before anyone applied it to a browser tab.

What a hypervisor actually is

A hypervisor is not a program that simulates a computer. It is a program that gets out of the way. The guest's instructions run on the real processor at real speed, and the hypervisor only intervenes when the guest tries something that would affect the rest of the machine — touch a device register, change a page table, execute a privileged instruction. Those attempts trap, control passes to the hypervisor, it fakes an answer, and the guest carries on none the wiser. Popek and Goldberg formalised this in 1974: a processor is virtualisable if every sensitive instruction is also privileged, so that every sensitive instruction traps.

x86 failed that test for twenty years. Robin and Irvine counted eighteen instructions in the Pentium's set that were sensitive but not privileged — SGDT, SIDT, SMSW, POPF and friends, which quietly do the wrong thing in user mode instead of faulting. POPF is the famous one: pop a flags word that would change the interrupt flag while unprivileged, and the processor simply ignores that bit. A trap-and-emulate hypervisor never sees it happen. VMware's answer in 1999 was binary translation, rewriting guest kernel code on the fly so the awkward instructions did trap. Intel's answer in 2005 was VT-x: a processor mode underneath ring 0, letting the guest kernel keep believing it is the most privileged thing in the building. AMD-V followed in 2006.

Type-1, type-2, and the blurry bit

Goldberg's 1973 taxonomy is still the one everyone uses. A type-1 hypervisor runs on bare metal and is itself the operating system of the box: Xen, ESXi, Hyper-V. A type-2 runs as an application on a normal operating system: VirtualBox, VMware Workstation, Parallels. The line is blurrier than it sounds. KVM is a Linux kernel module, which looks type-2, but once loaded it turns the kernel into the hypervisor. Hyper-V boots first and then demotes Windows to a privileged guest, which is why enabling it changes how everything else on the machine behaves.

None of that applies in a browser tab. A tab cannot execute VMXON; it has no VT-x, no /dev/kvm, no ring 0 of any kind. So TempMV runs no hypervisor at all. It runs an emulator — software that decodes and executes guest instructions rather than letting your processor run them. That is a different mechanism with different costs, and virtual machine, container or emulator works through it properly.

Why "temporary" is its own idea

Servers got here first. The phrase usually credited to Bill Baker and popularised by Randy Bias around 2012 is cattle, not pets: a pet has a name, gets nursed back to health when it is ill, and its history matters; cattle have numbers, and a sick one is replaced. A pet server accumulates a decade of undocumented ssh sessions until nobody dares reboot it. A cattle server is built from an image, and if it misbehaves you destroy it and build another from the same image.

The tooling around that idea is the modern deployment stack. Golden images: build once, bake into an AMI or a qcow2, launch identical copies. Immutable infrastructure, the phrase Chad Fowler used in his 2013 post "Trash Your Servers and Burn Your Code": never modify a running server, only replace it. Snapshots: capture a machine's entire state at an instant so you can return to it. Netflix's Chaos Monkey took it to the logical end and killed production instances at random, on the grounds that if replacement is routine it had better be tested.

# The pet: fix the running box, hope you remember what you did
ssh web01
  apt-get install -y nginx
  vi /etc/nginx/nginx.conf
  systemctl restart nginx

# The cattle: rebuild the image, replace the machine, discard the old one
packer build web.pkr.hcl        # -> ami-0a1b2c3d4e5f
terraform apply                 # launches new instances, terminates the old

# The disposable desktop: same instinct, one machine, no infrastructure
# open a tab, boot, use it, close the tab

A temporary virtual machine is that instinct applied to one machine you will use for twenty minutes. The point is not tidiness. It is that a long-lived VM slowly stops being isolated: you install things in it, configure it, come to rely on it, and end up maintaining a second computer with all the problems of the first — including no longer remembering how it reached its current state. A machine that resets removes the temptation. You cannot accumulate state, so you never depend on it, and every session starts from a point you can describe.

The lifecycle of a machine that does not persist

1. Your browser fetches the firmware ROMs — a BIOS and a VGA BIOS — then either the disk image or a snapshot taken after the boot had already finished.
2. The emulator allocates guest RAM as a flat buffer in the page. A machine configured with 128 MB costs the tab 128 MB, for as long as it runs.
3. The guest boots. Disk reads come from that buffer, or stream in as HTTP range requests for the sectors actually asked for. Writes go to the buffer and are never sent anywhere.
4. Hot stretches of guest code are compiled into WebAssembly modules and handed to the browser's optimiser, which is why a machine drags for a few seconds and then visibly quickens.
5. You close the tab. The buffer is garbage, the modules are discarded, nothing was written to your disk. There is no cleanup step because there is nothing to clean.

Four kinds of machine, compared

What a disposable machine is right for

• Seeing an operating system before committing to it. Ten minutes of Haiku or Plan 9 beats an hour of screenshots. What a system is like to use has no textual answer.
• Teaching. A class boots the same machine from one link, breaks it, and reloads. No lab images, no USB sticks, no student whose firmware refuses to enable virtualisation.
• Watching the machine underneath. A boot sequence you can pause, on hardware whose state you can dump, teaches differently from reading about the A20 gate.
• Opening something you do not trust — an old binary, a suspicious floppy image, shareware from an abandonware site. The worst it can do is fill a buffer in a tab.
• Reproducing a bug from a clean state. Every attempt starts identical, which is what makes a bug report worth reading. Start one at /new.

And what it is wrong for

Temporary is not the same as powerful, and it is not the same as private-from-everything. A machine that resets cannot be where your work lives: the reset that protects you from accumulated state also destroys the state you meant to keep.

• Anything 64-bit. v86 implements roughly a Pentium 4 with SSE3 and no long mode. A modern desktop distribution has nothing to boot into.
• Compiling anything large. A kernel build that takes four minutes natively will not take forty here; it will take longer than you will leave a tab open.
• Anything needing UEFI, a TPM or secure boot. The firmware here is a BIOS, so such systems have nothing to start from.
• Serious networking. A tab cannot open raw sockets, so guest packets must be tunnelled over a WebSocket relay. It works, it is experimental, and it is not how you run a service.
• Malware analysis you would stake something on. The isolation is genuinely good, but a tab is not a purpose-built analysis sandbox and the emulated hardware is trivially detectable from inside.

What "no server" actually buys you

Most browser-based VM services are thin clients. A machine runs on someone's fleet, the pixels arrive as video, your keystrokes go back the other way. That model can be fast and can run 64-bit guests, but everything you type crosses infrastructure you do not control, and the operator can see your session because seeing your session is how the product works.

TempMV has no server to send anything to. The emulator is WebAssembly in your tab, disk images are fetched by your own browser from wherever they are hosted, and a file you drag in is read locally and never uploaded. That is a structural guarantee rather than a promise in a policy document: there is no upload endpoint, so there is nothing to audit. What it does not buy you is invisibility — your browser still makes HTTP requests, so whoever hosts the images and whoever carries your traffic can see which you asked for. Statelessness is not anonymity. The privacy page says the same in fewer words.

The performance ceiling, honestly

Three layers of tax sit between guest code and your processor. Every guest instruction is decoded by software rather than silicon — v86 mitigates that by translating hot blocks into WebAssembly modules at runtime, but the translation must still model x86 semantics faithfully, flags included, and flags are expensive. Every memory access goes through a software MMU walking the guest's page tables, because there is no EPT or nested paging to do it in hardware. Every device access is a function call into a device model instead of a write to a real register.

In practice a text-mode system feels responsive, a lightweight X desktop is usable but slightly underwater, and anything redrawing a full screen at speed is painful. There is no graphics acceleration; the VGA card is a framebuffer the emulator copies to a canvas. The trick that makes the catalog feel quick is not speed at all — most machines start by restoring a snapshot taken after the boot finished, skipping the slowest part entirely. Snapshots and machine state covers how, and the glossary covers the terms.

The middle ground

Disposability rarely has to be absolute. What TempMV keeps is the recipe rather than the machine: the hardware configuration, how much RAM, which images go in which slot, what to pass on the kernel command line. That is a small JSON document, it survives reloads, and it can be shared as a link — which is how a lecturer hands thirty people an identical starting point. You can also export a full snapshot to your own disk and restore it later, which is persistence without giving anyone else custody of it.

That split is the honest version of the idea. The recipe is cheap, portable and worth keeping. The running machine is expensive, unreproducible and worth throwing away. To see a recipe as text, /json will build a machine from one.