How to check Proxmox VE logs: journalctl, task logs and /var/log/pve

journalctl tells you a Proxmox task failed. It rarely tells you why.

Proxmox writes most of its logs to the systemd journal. The output of each task goes somewhere else: one file per task, under /var/log/pve/tasks/. Backups, migrations, VM starts and snapshots are all tasks. The journal gets a line or two about each one. The file gets everything the task printed.

This guide covers where each log lives, and how to read the ones that matter.

Where each log lives

The web UI’s Syslog view under each node reads the journal. It does not read /var/log/syslog.

Read the journal first

Five units cover most of what goes wrong:

Read the last hour of all of them at once:

journalctl -u pvedaemon -u pveproxy -u pvescheduler -u pve-cluster -u corosync --since "1 hour ago"

Only errors from the current boot:

journalctl -b -p err

Is /var/log/syslog missing? Proxmox VE 8 is built on Debian 12, and Debian 12 stopped installing rsyslog by default. Run dpkg -l rsyslog to see whether you have it. Nothing is lost if you do not. The journal holds the same lines.

Check that the journal survives a reboot, too:

ls /var/log/journal

No such directory? Then the journal lives in /run and is gone after each reboot. Create the directory and restart systemd-journald to keep it. The guide to finding out why a Linux server rebooted covers this, and why it matters most on the one boot you need.

Read a task log

Every task gets an ID called a UPID. It looks like this:

UPID:pve1:0003A2F1:01C7E4B2:66F5A1C0:vzdump:101:root@pam:

The fields are node, process ID, process start time, task start time (hex), task type, guest ID and user.

List recent tasks that did not end OK:

pvenode task list --errors --limit 20

--errors hides tasks that ended OK. Tasks that ended with warnings still show. Narrow it with --vmid 101 or --typefilter vzdump. --since takes a Unix timestamp:

pvenode task list --errors --since "$(date -d '24 hours ago' +%s)"

Then read one task’s full output:

pvenode task log 'UPID:pve1:0003A2F1:01C7E4B2:66F5A1C0:vzdump:101:root@pam:'

Quote the UPID. It ends in a colon, and it is long enough that you will paste it.

The files themselves sit in 16 folders, 0 to F. The folder is the last hex digit of the task start time. 66F5A1C0 ends in 0, so that task is in /var/log/pve/tasks/0/. You rarely need the path. pvenode task log finds it for you.

Proxmox does not keep task logs forever. A daily job deletes the old ones. What survives is roughly the last one to two thousand tasks.

Find a failed scheduled backup

A task started from the web UI logs two lines to the journal:

pvedaemon[1893]: <root@pam> starting task UPID:pve1:...:vzdump:101:root@pam:
pvedaemon[1893]: <root@pam> end task UPID:pve1:...:vzdump:101:root@pam: OK

The end line carries the result. It is OK, WARNINGS: 2, or the error text itself. A backup job with failed guests ends with job errors.

Scheduled backups break that pattern. pvescheduler hands the job to a short-lived child process. The child starts the backup task and exits before the backup finishes. Only the process that started a task logs its end line, so a scheduled backup logs starting task and never logs end task. Search the journal for end task and every failed nightly backup is missing.

vzdump logs its own result lines, though, and those arrive either way:

journalctl --since "24 hours ago" -g 'Backup of VM .* failed|Backup job (failed|finished with errors)'

The lines look like this:

pvescheduler[40112]: ERROR: Backup of VM 101 failed - <the reason>
pvescheduler[40112]: INFO: Backup job finished with errors

For the full story of one guest’s backup, read /var/log/vzdump/qemu-101.log, or lxc-101.log for a container. The file is overwritten on every backup of that guest, so it only ever holds the last run. On directory storage, Proxmox also copies it next to the backup archive as vzdump-qemu-101-<date>.log.

A VM will not start

The web UI shows a red task and a one-line error. The whole error is in the task log. Faster still, start it from a shell:

qm start 101

A task started from the CLI runs in the foreground and prints its output to your terminal. That includes whatever QEMU printed before it exited, and the final line:

start failed: QEMU exited with code 1

There is no separate QEMU log file to go looking for. To see exactly what Proxmox tried to run:

qm showcmd 101 --pretty

A container will not start

Start it with debug logging:

pct start 101 --debug

This runs lxc-start at DEBUG level and prints its output into the task log. It is long. Read it from the bottom, where the ERROR lines are. --debug exists since pve-container 3.2, in the Proxmox VE 6 series.

When a start fails without --debug, Proxmox still prints LXC’s error output into the task log. So read the task log first. Reach for --debug when that is not enough.

Who logged into the web UI

Login failures go to the journal from pvedaemon:

journalctl -u pvedaemon -g 'authentication failure'

pvedaemon[1893]: authentication failure; rhost=::ffff:203.0.113.7 user=root@pam msg=<the reason>

Successful logins log as successful auth for user 'root@pam'.

Every request to the web UI and the API goes to /var/log/pveproxy/access.log. It looks like an Apache log with two differences. The date is numeric, day first: [28/09/2026:09:14:02 +0000]. There is no referer and no user agent. The file rotates daily and keeps seven days.

The firewall log is empty

Firewall logging is off by default. Every rule and every default policy logs at nolog until you change it.

Turn it on for the host or a guest under Firewall → Options, with log_level_in and log_level_out. Or set a log level on one rule. Entries then appear in /var/log/pve-firewall.log and under Firewall → Log in the web UI. The first column is the guest ID, and 0 means the host.

Cluster problems

Cluster trouble shows up in two units:

journalctl -b -u corosync -u pve-cluster

corosync tells you when a node dropped out and when quorum was lost. pve-cluster tells you what the cluster filesystem did about it.

For a quick cross-node view of recent task starts and ends, ask the cluster log:

pvesh get /cluster/log

It is a small ring buffer held in memory, so it only covers recent events.

Read every node’s logs in one place

Everything above happens one node at a time, over SSH. Task logs never leave the node that ran the task. When that node dies, the explanation dies with it.

Central Logging collects the journal from every node with one agent per node. Then one SQL query finds every failed backup across the cluster, and an alert rule tells you the morning it happens instead of the morning you need the backup. The guide to sending Proxmox logs to a central server walks through the setup.

Where to go next

• Why a systemd service failed to start — when pveproxy or pve-cluster itself will not stay up.
• Showing only errors in journalctl — what -p err catches, and what it misses.
• Searching journalctl logs for a specific string — how -g matches, and the case rule nobody expects.
• Fixing /var/log filling up — when the root disk of a node fills and backups start failing with it.