Logs, exec, and redeploy
Updated
An AppVM has the same lifecycle actions as a classic VM, plus three things that matter for application workloads.
The workload’s output is captured on the host and shown on the machine’s page, so you do not need a terminal to see why something failed. Logs survive a Virtainer Lite restart, and the stream resumes on its own if the connection to the guest drops.
Exec opens a terminal inside the running machine, which is the fastest way to check what the workload actually sees.
Redeploy
Section titled “Redeploy”Redeploy rolls the machine onto the current build of its template. It stops the machine, applies the new image’s process settings, gives it a fresh copy of the system disk, and boots it.
| Kept | Reset |
|---|---|
| Data volumes, with their contents | The system disk |
| Environment, including secrets | |
| Network configuration and volume attachments | |
| Keepalive and process overrides |
If a redeploy fails partway, the machine is put back the way it was: the old disk returns and the record is untouched, so you can fix the cause and try again.
Health and exit codes
Section titled “Health and exit codes”The workload’s exit code and signal are reported into the machine’s state, so a machine that stopped tells you how it stopped. If the guest stops responding while the machine is still running, the console flags it rather than continuing to show it as healthy.
No snapshots
Section titled “No snapshots”AppVMs do not have snapshots. A restored guest would come back holding a connection to the host that no longer exists.
Redeploy is the rollback mechanism: point the template at the build you want and redeploy onto it. Your data volumes come through untouched.
Restart and reboot behaviour
Section titled “Restart and reboot behaviour”Restarting or upgrading Virtainer Lite does not disturb a running workload. After a host reboot, machines that were running come back automatically and keep their addresses. See After a host reboot.