Contrast version
v1.21.0
Deployment platform
All platforms
Issue description + logs
When a confidential VM crashes early during boot, the kata runtime takes ~2 minutes to report the failure. The delay comes from commonDialer in client.go retrying connect() to the dead vsock CID for the full dial_timeout (90-120s).
The root cause spans two layers:
QEMU (10.2): When the guest requests SEV-ES termination, QEMU prints a register dump to stderr and hangs in poll(). It never exits, never closes stderr, and never emits a QMP event. This was fixed upstream in QEMU 11.0 (qemu/qemu@56d89db), which converts SEV-ES termination into a GUEST_PANICKED event and exits cleanly.
Kata runtime: Even when QEMU exits cleanly (with the QEMU fix), kata's existing handleGuestPanic() only attempts a memory dump (which is a no-op when guest_memory_dump_path is empty) and has no mechanism to cancel the pending vsock dial. There is a TODO in the code referencing this gap: kata-containers/kata-containers#1026
Steps to reproduce the behavior
Branch sse/fix-qemu-reporting-v4 includes an OVMF patch that forces SEV-ES guest termination on boot, making the crash 100% reproducible.
# Checkout the branch
git worktree add .worktree/sse/fix-qemu-reporting-v4 sse/fix-qemu-reporting-v4
# With kata fix (error in < 1s):
SET=kata-sev-terminate-test just e2e openssl
# Without kata fix (error after ~2 min):
SET=kata-sev-terminate-test-no-fix just e2e openssl
Watch kata logs on the node:
journalctl -t kata -f | grep -E "Stop logging|hypervisor marked as stopped|Cannot start VM|context canceled|timed out connecting to vsock"
With the fix, each crashed CVM produces:
Stop logging QEMU
hypervisor marked as stopped (reason: QEMU process exited)
Cannot start VM: context canceled
Without the fix, only "Stop logging QEMU" appears, followed by ~2 minutes of silence and then "Cannot start VM: timed out connecting to vsock".
Both tests will fail (the CVM always crashes by design). The difference is how fast and how clearly kata reports the failure.
Contrast version
v1.21.0
Deployment platform
All platforms
Issue description + logs
When a confidential VM crashes early during boot, the kata runtime takes ~2 minutes to report the failure. The delay comes from commonDialer in client.go retrying connect() to the dead vsock CID for the full dial_timeout (90-120s).
The root cause spans two layers:
QEMU (10.2): When the guest requests SEV-ES termination, QEMU prints a register dump to stderr and hangs in poll(). It never exits, never closes stderr, and never emits a QMP event. This was fixed upstream in QEMU 11.0 (qemu/qemu@56d89db), which converts SEV-ES termination into a GUEST_PANICKED event and exits cleanly.
Kata runtime: Even when QEMU exits cleanly (with the QEMU fix), kata's existing handleGuestPanic() only attempts a memory dump (which is a no-op when guest_memory_dump_path is empty) and has no mechanism to cancel the pending vsock dial. There is a TODO in the code referencing this gap: kata-containers/kata-containers#1026
Steps to reproduce the behavior
Branch sse/fix-qemu-reporting-v4 includes an OVMF patch that forces SEV-ES guest termination on boot, making the crash 100% reproducible.
Watch kata logs on the node:
With the fix, each crashed CVM produces:
Stop logging QEMU
hypervisor marked as stopped (reason: QEMU process exited)
Cannot start VM: context canceled
Without the fix, only "Stop logging QEMU" appears, followed by ~2 minutes of silence and then "Cannot start VM: timed out connecting to vsock".
Both tests will fail (the CVM always crashes by design). The difference is how fast and how clearly kata reports the failure.