Skip to content

fix: restore --force relaunches under the launch-scoped VNC contract - #36

Merged
CMGS merged 5 commits into
masterfrom
batch0/restore-vnc
Sep 2, 2026
Merged

fix: restore --force relaunches under the launch-scoped VNC contract#36
CMGS merged 5 commits into
masterfrom
batch0/restore-vnc

Conversation

@CMGS

@CMGS CMGS commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Problem

vm restore --force on a running VM terminates QEMU, reverts the disks, then calls launch with the loaded record. VNCPass is never persisted (json:"-"), but VNCDisp is, so the relaunch carried a display number with an empty password:

  • CNI VM: requireCNIVNCPassword refused the launch after the disks were already reverted, and saveRec was never reached, so the record kept the dead PID.
  • Non-CNI VM: QEMU came back with VNC on 127.0.0.1:590n and no password, where the previous incarnation required one.

Stop already encodes the contract (r.PID, r.VNCDisp, r.VNCPass = 0, -1, "" plus stopVNCProxy); Start re-enables VNC only from its own flags. Restore was the one launch path that did not follow it.

Change

Restore's wasRunning branch stops the VNC proxy and clears the three launch-scoped fields before relaunching, exactly as Stop does.

Evidence

GOWORK=off make lint (linux + darwin): 0 issues ×2. make fmt-check: clean. asl ./... both GOOS: clean. go test -race ./...: green. The restore path has no unit harness (it drives a real QEMU); the change mirrors the stop path line for line.

CMGS added 5 commits September 2, 2026 15:03
The record never persists VNCPass, but restore --force kept VNCDisp
from the terminated QEMU and relaunched with it: a CNI VM then failed
requireCNIVNCPassword after its disks were already reverted, leaving a
stale PID on disk, and a non-CNI VM came back with VNC listening
without a password. Stop already clears both and stops the VNC proxy;
restore now does the same before launch.
…ch owns the stale VNC proxy

A restore that failed after terminating QEMU (a missing tag on one
disk, a failed apply, a failed relaunch) left vm.json with the dead PID
and the old display; the cleared record is saved as soon as the VM is
down. A previous launch's detached VNC proxy survived QEMU's exit, so a
relaunch without --vnc (the supervisor's cold relaunch after a guest
reboot) left 590n listening; launch now stops any proxy before it
boots, which also covers restore.
restore's snapshot validation and apply can fail after QEMU is gone
and before launch runs, leaving the detached proxy listening until the
next start or stop. Terminate and proxy stop are one step, as in Stop.
…unch already did

Stop and restore both wrote "stop the proxy, clear PID and VNC, save";
saveStopped owns that tail. launch's error branch stopped a proxy that
its own unconditional stop a few lines above had already removed.
@CMGS
CMGS merged commit 522635d into master Sep 2, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant