zeekayandHanzo Dev 26aefb5729 A guest can be put down and picked up again ...

can_pause and can_resume returned a hardcoded false, so the capability was
declared absent while the client that would perform it already existed —
api::put against the cloud-hypervisor socket, the same call vm.create and
vm.boot already go through.

Four verbs, and the pairing matters more than any one of them:

  pause     stops the vCPUs. Memory stays mapped, devices stay configured, so a
            resume is the guest CONTINUING rather than the guest booting. This
            is the half of suspend that costs nothing — nothing written, nothing
            freed.
  snapshot  writes the paused guest under a directory. It pauses first, and that
            is not an optimisation: cloud-hypervisor refuses to snapshot a
            running VM, because memory captured at one instant and device state
            at another is a machine that never existed. It leaves the VM paused,
            so the caller decides whether it continues or goes away.
  restore   replaces vm.create/vm.boot rather than following them — a restore
            carries its own configuration, so a VMM that has already created a
            VM has nowhere to put this one. The guest arrives PAUSED, the same
            state snapshot left it in, so the round trip is symmetric.
  resume    the other end of pause.

VmState gains Paused at discriminant 2, which is Apple's
VZVirtualMachineStatePaused and what crates/vm-darwin already uses. The
discriminants stay aligned so one state channel means the same thing on both
backends.

vm-ch checks clean. vm-linux's failures are its own and predate this; vm-darwin
does not build on Linux at all.

Co-authored-by: Hanzo Dev <[email protected]>

2026-09-08 14:34:24 -07:00

..

src

A guest can be put down and picked up again

2026-09-08 14:34:24 -07:00

Cargo.toml

release: 2.0.2

2026-09-06 00:47:14 -07:00