Monitoring and logs
Monitoring connects a symptom to the VM, Host or Task responsible for it. Use console metrics for current workload behavior, Tasks for operation results and Host logs for service and boot failures. Before investigating, record the time, object identifiers and installed release so records from different Hosts can be compared.
Read the console
Open the VM's Metrics tab for resource history and Activity for operations. Memory is allocated capacity; Memory used (guest) depends on guest tools reporting usable information. A missing guest report is not a measurement of zero memory use. Check the agent inside the VM before interpreting an empty guest-memory chart.
Project and Silo Utilization pages show provisioned resources and quotas. These answer capacity and ownership questions rather than replacing runtime metrics. Fleet roles can inspect System, Tasks, Alerts, Observability and Audit log.
- Find the affected VM or Host and note its Pool and current state.
- Open the related Task and read its final state, progress and diagnostic.
- In Observability, inspect Overview, Network map, Flows or VM metrics for the relevant interval.
- If the page reports Some Hosts could not be read, investigate those Hosts before treating aggregate results as complete.
- Use Audit log to establish which management action was requested and by which Account.
Canceling a Task requests cancellation; check its eventual state before taking recovery action. Acknowledging an Alert does not repair its cause.
Inspect a host
The installed services use OpenRC and syslog. From an authorized Host shell:
rc-status
rc-service hv status
rc-service hv-agent status
rc-service xapi status
tail -n 100 /var/log/messageshv and hv-agent records appear with their service tags in /var/log/messages. xapi diagnostics also use /var/log/xensource.log. Correlate timestamps instead of assuming the last line explains a failure. Avoid distributing entire logs without reviewing them for private deployment data.
For slow boot, /run/hv/boot-timeline.tsv records events relative to kernel uptime. Completed records are copied to /var/log/hv/boot/, retaining the last ten. The timeline distinguishes a listening port, xapi initialization and Host enablement; these milestones are not equivalent. It is a diagnostic record, not a guaranteed boot-time target.
Verify and resolve gaps
After a repair, repeat the failing operation once and confirm its Task, metrics and application outcome. If charts remain empty, check agent reachability and sample availability. For a stalled queue, confirm one execution engine owns the intended database. Starting a second engine is not a way to accelerate or repair it.
For suspected audit corruption, hv audit verify checks the chain and configured anchors. Preserve the database and independent anchors when verification fails. Restoring an older database before retaining diagnostic records can remove the very history needed for investigation. See troubleshooting for a compact diagnostic sequence.