Admit the existing runner with an explicit guest and QEMU memory budget

This commit is contained in:
dh
2026-10-05 13:09:47 +02:00
parent bcb24e82eb
commit ec5508e978
2 changed files with 26 additions and 3 deletions
+2
View File
@@ -4,6 +4,8 @@ The isolated RAW Recovery comparison starts from Full candidate `2e2d702e294c39f
The existing pinned container's `qemu-img` converts the already-patched DMG, requires sector equality with `qemu-img compare`, and checks that conversion preserved the DMG's SHA256. Both images stay in this run's owned storage. A retained JSON receipt binds both hashes and the successful comparison. The original readonly virtio attachment and I/O thread are preserved; cleanup removes both images with that owned volume. Local `--validate --full --recovery-format raw --source <pristine-pinned-dockur-checkout> --output <fresh-folder>` exercises conversion failures, source mutation and strict backend selection with a mocked QEMU boundary. The generated `raw-recovery-real-qemu-fixture.sh` accepts an already-patched **disposable writable DMG copy** plus destination for an actual container QEMU comparison; it does not patch, mount or boot a guest. This comparison does not yet prove faster guest operation or native application tests.
Run 4204 stopped before creating a VM because the shared host exposed 5,138,696 KiB available memory, just below the previous arbitrary 5-GiB admission threshold. Admission now budgets the unchanged 4-GiB guest plus 512 MiB for QEMU (4.5 GiB); previous guest recordings peaked below 3 GiB. The 6-GiB container cap and all guest parameters remain unchanged. Offline validation replays that captured host value and still rejects a host with only 4 GiB available. This is an admission budget, not a reservation against other host workloads; actual performance and memory remain subject to the remote result.
This manual candidate uses the existing Ubuntu/x64 Docker runner. Before downloading Apple Recovery it tests actual AVX/AVX2 instruction execution in the pinned QEMU binary, then probes a fresh macOS 14+ Recovery guest. It does not install macOS, erase a disk, provision .NET/CLT or run Meeting Assistant tests. Readiness is only a prerequisite for full native CI.
## Profile and evidence