[earakely-scale]

What this does

Part of FD-5328 (W8 part 3). When local Docker boots a computer's disk, it now mounts the disk image's disk/ folder read-only into the QEMU launcher, instead of copying the disk into an image of the launcher. This applies where Docker can mount images: Docker 28 and later, on the containerd image store. Elsewhere, the copy (machine_image) stays as the fallback.

• machine_for(disk) returns a Machine: the image to run, plus its arguments.
  • Where Docker can mount images: the launcher itself, with --mount type=image,source=<disk>,target=/disk,image-subpath=disk.
  • Elsewhere: the machine image, as before.
• mounts_images() reads docker info once per process: a server version of 28 or later, and the containerd snapshotter.
• Deploys and gate 3 (LocalSandboxProvider._boot_disk) boot this way. So do Windows composes (windows_disk.compose), including the qemu-img convert against the mounted base.
• The disk's files sit at /disk either way, so the launcher and the backing-file paths are unchanged.

Why. Every launcher change copied each disk into a new launcher image. Any agent-env upgrade that touches the launcher makes such a change. For Windows that meant copying the 11.6 GB base again for each base, and every composed disk got a machine image of its own.

Note. A mounted Windows image shows /disk/admin.key (root-only, mode 600) inside the launcher container; the copy left it out. Only the launcher and QEMU run in that container, and the key is already on this machine, inside the pulled image.

Measured

Box 1: EC2 c8i.4xlarge, Docker 29.9 with the containerd image store.

	Before (copy)	This PR (mount)
A launcher change (any agent-env upgrade that touches it), for each composed Windows disk	356 s to copy the disk into a new machine image	no copy; the new launcher image builds in 1 s
The Windows base, for each launcher	about 8 min to copy it into a machine image of its own (FD-5328)	no copy
A Windows compose with a new key, plus gate 3, with the base on this machine		3 min 2 s, and 3 min 13 s in a second run
A Windows deploy	25 to 30 s	25 to 28 s
Machine images built	one for each disk and launcher	none

The Linux disk desktop's deploy, probe, reset and second probe took 148 s on the mount path. The first install with nothing stored, and a fresh machine pulling what it stored, are measured in a comment below.

Tested

• Unit tests:
  • machine_for mounts or copies;
  • mounts_images across Docker versions and image stores (28 and 29 on containerd, 27, overlay2, Podman);
  • a local disk boot with the mount arguments;
  • qemu-img convert with the mount arguments.
• E2E on box 1 (EC2 c8i.4xlarge, Docker 29.9 with the containerd image store), all on the mount path, with no machine image built:
  • a Windows compose with a new key: the base booted through the mount, the layer converted against the mounted base, then pushed;
  • Windows probe and reset;
  • the Linux disk desktop: deploy, probe, reset, probe again.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no new actionable issues were found.

Summary

Local Docker can mount disk images into the QEMU launcher instead of copying each disk into a launcher image. Unsupported hosts keep the copy path.

• Local Docker mounts computer disks into launchers when its image store supports it.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Deploy or Windows compose] --> B[machine_for]
  B --> C{Cached Docker support answer?}
  C -->|No| D[Query Docker with 30-second timeout]
  D -->|Query fails| E[Copy disk into machine image]
  D -->|Answer received| F[Cache answer]
  C -->|Yes| G{Image mounts supported?}
  F --> G
  G -->|Yes| H[Run launcher with disk image mounted]
  G -->|No| E

Loading

_{Reviews (3) · Last reviewed commit: "fix(computer): ask Docker again after it..." · Reviewed by Greptile}

[earakely-scale]

First runs, measured (W8 part 4)

Box 1 (EC2 c8i.4xlarge, Docker 29.9 with the containerd image store), running agent-env run tst/integration/computer/windows --task probe from this branch.

Run	Before (copy)	This PR (mount)
A fresh machine on a store that holds the disk (empty state and cache, no Windows image in Docker)	252 s; compose check and gate 3 took 3 min 4 s	114 s; compose check and gate 3 took 58 s
A first install with nothing stored: ISO fetch, Windows setup, pack and push the base, compose and push the disk, gate 3		35.5 min in all; gate 3 was ready at 34 min 29 s
The deploy step in either run	25 to 30 s	25 to 27 s

The "before" row is the fresh-machine run from #531's e2e, on the same box, earlier today.

How the first install was set up:

• A bundle's @local envs push to the local registry on :5000 whatever [stores.image] names (namespace routing), so I put an empty registry on :5000 for that run and restored the original after.
• Most of its time is Windows setup itself (about 13 min) and the ISO fetch.

Measured against W8's done-when:

• A fresh machine's first run is under 20 minutes: 114 s on a store that holds the disk.
• An upgrade no longer copies the base: a launcher change copies nothing.