vm: keep qcow2 overlays buffered so a shared base stays in the page cache

[CMGS]

Problem

Cloud Hypervisor used to open a qcow2 backing file with buffered I/O regardless of what the disk asked for. Every cloudimg and Windows VM layers a per-VM qcow2 overlay over one shared base blob (prepareCloudimg runs qemu-img create -f qcow2 -F qcow2 -b <base> <overlay> and attaches only the overlay), so that base was served from a single host page-cache copy no matter how many VMs ran on it.

Upstream now opens the backing file with the disk's own direct flag, and cocoon sets direct=on for every writable disk, so each VM reads the shared base straight from storage instead.

Measurement

16-core host, 700 MiB base image, qcow2 overlays, guest reads 1 GiB from /dev/vda. Page-cache residency of the base measured with mincore, files evicted with posix_fadvise(DONTNEED) before each cell.

cloud-hypervisor	direct	base resident after read
before the upstream change	on	310.1 MiB (44.3%)
before	off	310.1 MiB
after	on	0.0 MiB
after	off	310.1 MiB

8 VMs reading 1 GiB each, 3 repetitions: direct=on 2.47-2.67 s against direct=off 1.86 s.

This is not a host-memory regression — O_DIRECT uses less host RAM. The cost is read amplification: N VMs on one base each fetch it from storage instead of one fetch plus N-1 cache hits. A second pass over the same blocks was not faster in either configuration on this NVMe, so the measured time difference is O_DIRECT losing readahead rather than cache reuse.

Change

Default direct=off for a qcow2 disk that layers over a base image, in effectiveDirectIO. Both the launch path and the restore-time config patch derive direct from that function, so they stay in agreement.

The overlay itself loses O_DIRECT, so its writes land in the host page cache as well as the guest one. That memory is reclaimable and the residual cost is one extra copy per written byte — the cheaper half of this trade, since without it every VM refetches the shared base from storage.

Unchanged: raw COW disks, read-only layers, data disks, and an explicit direct_io on a data disk.

Why not keep O_DIRECT on the overlay

Expressing the split the old Cloud Hypervisor gave us by accident — a direct overlay above a buffered base — needs a per-backing-file cache policy that no released version has. It is requested upstream as cloud-hypervisor/cloud-hypervisor#8718, with an implementation parked on the fork branch qcow-backing-direct. This PR deliberately takes the approach that works against stock Cloud Hypervisor, so cocoon does not become dependent on a fork-only --disk key.

Second commit

asl flags RefuseManifest for splitting the Store type from its first method. Layout-only move, no behavior change. It was already failing on master.

Verification

• go build ./...
• go test -race -count=1 ./...
• make lint — 0 issues on GOOS=linux and GOOS=darwin
• golangci-lint fmt --diff — clean
• asl ./... — clean on both GOOS (was 1 finding on master, fixed here)