Logs and diagnostics

Logs & Diagnostics under System is the first place to look when the host itself is the problem, rather than a machine on it. It holds five sections: Diagnosis, Run log, Recent failures, Change audit, and Support report.

Run log

The page shows Virtainer Free’s own log, filterable by level and viewable in local time or UTC. Most questions about what the host did and when are answered here.

The log is read from the host’s own journal rather than from the running process, so it survives a restart of Virtainer Free and of the host. Choose This boot or Previous boot to say which stretch of time you want. After the host itself rebooted, the earlier lines are in the previous boot. An agent that was killed and started again without a host reboot leaves its lines in the current one, so look in Recent failures below rather than switching boot. How long anything stays available is the journal’s decision, not the product’s.

Host checks

The Diagnosis tab runs checks against the host itself, computed from what the host can actually observe. Each check reports one of four verdicts: Pass, Warn, Fail, or Unknown.

Unknown is an answer, not a failure

Unknown means the host has no current observation for that check: the probe could not run, its dependency was unreachable, or the reading was too old to trust. It is not a pass with doubt attached, and it is not a failure either. It names a blind spot, and it is sorted above Warn for that reason: a known minor problem is easier to act on than a check you cannot see through.

Every check carries a next step written by the host rather than guessed at by the page, so the row tells you where to look as well as what it found. Checks cover the tools the host runs machines with, its storage paths, pools and snapshot headroom, network and DNS delivery, the boundaries between the host and its machines, disk health, whether the agent’s most recent start followed a clean shutdown, its background tasks, its database schema, and instance-level problems including boot loops and quarantined records. One check reads back the label on the SSH key set up during first-run: if the host rejects that key while password login still works, that check is the one that names the mismatch.

One start, not a crash history

The agent exit check answers a single question: did the agent’s most recent start follow a clean shutdown? A Pass reads “The agent’s most recent start followed a clean shutdown.” A crash holds that row at Warn only until a later start overtakes it, so this is not a record of whether the agent has ever crashed. In earlier builds it was easy to read that way, and on a real host the result was a warning naming the version of a crash several clean restarts old, which nothing you did could clear. The crash itself stays where it belongs: in Recent failures, and in the run log for the boot it happened in.

Anything worth your attention here also appears in the notifications list in the console header.

Recent failures

This is the host’s index of failures it captured, kept in its own store so it survives a restart of Virtainer Free. It is where you look for the crash or the machine failure that the current boot’s log no longer shows. Each row carries a stable code, the component it came from, and a one-line account of what happened, and rows linked to a request open onto that request’s own log lines.

A machine that stopped answering while the process running it stayed alive lands here as vmm_unresponsive, against that machine, with the machine still marked running: the host left it alone rather than destroy it on a missed answer. While a machine stays in that state the host records it at most once every five minutes, because a congested host that keeps failing its probes would otherwise push every other clue out of the list. See Lifecycle and console for what the state means.

Change audit

Every change the host accepted through its API is listed here with who made it, what it touched, and how it ended, along with the request and operation ids that lead back to the log lines and to the durable operation. It keeps that metadata only: no request bodies, query strings, cookies, or credentials. When the question is who changed a machine rather than what the host was doing, start here and follow the request id into the run log.

Machine runtime logs

A machine’s own Diagnostics tab keeps the output of each time the host started it, under Runtime attempts: the machine’s runtime output, its disk runtime output, and its recorded lifecycle events, chosen per attempt. Only the newest eight starts are kept, and older ones are removed when a new start begins, so the evidence from the start that crashed is still there after the host has restarted the machine several times.

Disk health

Storage devices report their health, including early warning when a disk starts to degrade. Check this after any unexpected reboot, and before you plan a storage change. The Storage page shows the same information alongside the pool.

Capacity

The Dashboard reports what the host has and what is committed to machines. It is the quickest check when creation fails for reasons that turn out to be simply running out of room.

Support report

A support report bundles the host’s local evidence for when you are asked for it: what the host and its machines currently are, the diagnosis findings, the run log for this boot and the previous one, the host’s PCI device state, the workload output of AppVMs, recent failures, the request audit, the durable operations, and the retired versions of the active network topology. The PCI part lists the devices the host can see, with each one’s IOMMU group, the driver bound to it, and which machine’s record claims it. If you pass hardware through, read that section before you share the report, because it describes the hardware in your host and what is attached to it.

The host itself has no outbound path for a report: it never sends one anywhere on its own. The Send button in the Support form posts from your browser to Virtainer, not from the appliance. You can also download the report and pass it on yourself. The three newest reports are kept, and each carries the checksum support verifies the file against.

Review a report before you share it

A report is designed to remove known secret formats. That is best effort, not a guarantee: it can still contain hostnames, IP addresses, machine names, and log content. Read it before sending it outside the trust boundary of your own host. The report records how many replacements the scan made, and which parts came out complete, truncated, or missing, so a partial report is still evidence rather than a failure.

Reading a failure

Errors from the host carry a stable code as well as a message, and a few of them point somewhere other than where they seem to:

What you see	Where the problem actually is
An upstream service is unavailable	The host’s own outbound network or DNS, not its storage or VM networking
A storage probe failed	Reading the disks failed. This is different from finding no disks
The operation does not match the current state	The machine is not in a state that allows the action, such as exporting a machine that is not completely stopped
A plan is stale	The disks changed after you reviewed the plan. Review again

The console shows the code alongside the message, so quote both when you report a problem.

Machines that look wrong

Booting, running and failed say different things

A machine stuck at Booting started but was never observed on the network. Open its console. A machine still marked Running that has stopped answering is one the host refused to destroy on a guess: find vmm_unresponsive in Recent failures and decide what to do with it. A machine marked Failed keeps its record and its failure reason on purpose, so read that before deleting it.

For what makes a machine count as dead, see Lifecycle and console. For machines that came back in an unexpected state after a restart, see After a host reboot.