On a c8i instance (2 vCPU, Ubuntu), booting with --mem 512 frequently leaves exec broken: the guest agent prints VMM_AGENT_READY on the console, but the VMM log never shows the agent's vsock connect (vsock: connect REQUEST ... host_port=1024 / vsock exec: guest agent connected are absent). Every exec then times out over vsock and stalls on the serial fallback. Retrying for several minutes does not recover — once the connect is missed at boot, the VM stays exec-dead.
Repro
vmm serve --socket /tmp/x.sock &
vmm --socket /tmp/x.sock create --kernel /tmp/vmlinux.microvm --rootfs rootfs.ext4 --mem 512
vmm --socket /tmp/x.sock exec "echo hi" --timeout 8000 # exit_code -1
Rootfs freshly baked with guest/agent/bake-agent.sh before each boot; server restarted between runs.
Observed rates
- main (49ce4e8),
--mem 512: 0/9 boots had working exec (5 reused-rootfs + 4 fresh-rootfs runs)
- fix/live-snapshot-dma-downtime,
--mem 512: intermittent — 4/9 worked
--mem 256: no failures observed across many boots on either branch
The rate difference between branches is just timing noise; the failure exists on main, so this looks like a boot-time race between the agent's vsock connect and host-side readiness that memory size shifts. Failing boots show zero vsock log lines, so the guest's connect request either was never sent or was dropped before the RX queue was live.
On a c8i instance (2 vCPU, Ubuntu), booting with
--mem 512frequently leavesexecbroken: the guest agent printsVMM_AGENT_READYon the console, but the VMM log never shows the agent's vsock connect (vsock: connect REQUEST ... host_port=1024/vsock exec: guest agent connectedare absent). Everyexecthen times out over vsock and stalls on the serial fallback. Retrying for several minutes does not recover — once the connect is missed at boot, the VM stays exec-dead.Repro
Rootfs freshly baked with
guest/agent/bake-agent.shbefore each boot; server restarted between runs.Observed rates
--mem 512: 0/9 boots had working exec (5 reused-rootfs + 4 fresh-rootfs runs)--mem 512: intermittent — 4/9 worked--mem 256: no failures observed across many boots on either branchThe rate difference between branches is just timing noise; the failure exists on main, so this looks like a boot-time race between the agent's vsock connect and host-side readiness that memory size shifts. Failing boots show zero vsock log lines, so the guest's connect request either was never sent or was dropped before the RX queue was live.