Task Center
The Task Center is the one page where every long-running ProxCenter operation is listed, followed and, where the product can act on it, cancelled. Rolling updates, DRS moves, Site Recovery replication jobs and plan executions, and migrations from another hypervisor to Proxmox all report there, whichever cluster they run against.
Open it from Operations > Task Center.
The Task Center is part of the Enterprise edition. On a Community install the menu entry is hidden and the page shows the upgrade prompt instead of the table.
Overview
The Task Center does not read Proxmox task logs directly. It aggregates the work ProxCenter itself drives, from five sources, and presents it as one list of jobs with a common status vocabulary, a progress bar and a detail dialog.
| Type | What it is | Where the rows come from |
|---|---|---|
| Rolling Update | A cluster-wide Proxmox package update, node by node | The orchestrator |
| DRS | A VM move decided by Distributed Resource Scheduling | The orchestrator |
| Replication | A Site Recovery replication job and its sync state | The orchestrator |
| Site Recovery | One execution of a recovery plan: failover, failback or test failover | The orchestrator plan history |
| Migration | A migration from ESXi, vCenter, Hyper-V, Nutanix or XCP-ng to Proxmox | The ProxCenter database |
Migrations joined the list in v1.4.8. Until then the page aggregated the four orchestrator sources only and never the migration jobs table, so the Migration filter it already offered could never match a row: a migration to Proxmox was invisible here and could not be cancelled from this page.
In the same release, a recovery plan execution stopped being filed under Maintenance and is reported as Site Recovery, which is what an operator actually ran. The type filter now lists exactly the five types the page can emit; Backup, which no source ever fed, is gone.
Proxmox's own tasks (qmstart, vzdump, qmsnapshot, a manual migration started from the Proxmox web interface) are not Task Center jobs. They are listed in the tasks bar at the bottom of the ProxCenter window, on its Proxmox tab, with the start and end time, the node, the target, the Proxmox user, the description and the status. The ProxCenter tab of that same bar carries the Task Center jobs, see The ProxCenter tab of the tasks bar.
Job States
| State | Description |
|---|---|
| Running | The job is in progress, with a live percentage in the Progress column |
| Queued | The job exists but has not started yet |
| Success | The job completed |
| Failed | The job ended in error |
| Cancelled | The job was stopped by an operator. The Failed filter matches it too |
| Paused | A rolling update held between two nodes, or a paused replication job |
A migration reports the vocabulary above rather than its own pipeline step: any state that is neither terminal nor still queued reads as Running, and the step it is really in (delta_sync, awaiting_root_choice, transferring, ...) is shown in the Detail column and in the detail dialog.
The table
Four cards at the top of the page count the whole perimeter: Total, Running, Pending and Failed. They are computed over every job the endpoint returned, not over the filtered table.
The table itself carries seven columns: Job, Type, Status, Progress, Started, Target and Detail. Target is the hostname of the Proxmox server the job runs against, resolved from the connection. Detail is the one-line summary of the job: the node counter of a rolling update, the source and target node of a DRS move, the route of a migration (ESXi -> pve1 (VMID 101)) followed by its current step.
The list is capped at the 50 most recent jobs, most recent first. The stat cards above it keep counting everything.
The orchestrator keeps a plain cluster id in its own rows rather than a foreign key, so a Site Recovery plan whose clusters had been deleted used to print bare internal ids in the Target and Detail columns. Such a reference now reads Deleted connection (<first 8 characters>), which stays traceable without pretending to be a hostname.
Filtering and Search
The toolbar above the table carries four controls:
- Search -- matches the job name, the detail line and the target.
- Type -- All types, Rolling Update, Replication, DRS, Migration, Site Recovery.
- Status -- All statuses, Running, Queued, Success, Failed, Paused. Success also matches a completed job, Failed also matches a cancelled one, and Queued also matches a pending one.
- Reset filters and Refresh, the two icon buttons at the right end of the row. Refresh shows a spinner while the read is in flight.
Filtering is applied to the rows already loaded, so it never triggers a new read.
Job Details
Double-click a row to open its detail dialog. It shows:
- the type and status chips and the job name in the title bar;
- the progress bar, with the node counter for a rolling update and the job's own detail line for every other type;
- the target, the start time and, on a finished job, the end time;
- the actions the job's type actually supports, see Actions;
- the error the job recorded, or the error an action just returned;
- the per-node status list of a rolling update, with the version before and after and whether the node rebooted;
- the Logs panel.
The Logs panel shows the last 100 lines, colours error, warning and success lines, and refreshes every 3 seconds while the job is running.
Where the logs come from
Until v1.4.8 the dialog fetched its logs from the rolling-updates route whatever the job type, so the panel was empty for every type but one. Each type is now read from the store that actually holds its log:
| Type | Log source | Additional permission |
|---|---|---|
| Rolling Update | The orchestrator's rolling-update detail | automation.view |
| Replication | The orchestrator's replication job logs | automation.view |
| Migration | The shared migration task history, over the full history rather than the tasks bar's 30-minute window | tasks.view |
| DRS | The Proxmox task log, addressed by the UPID the orchestrator recorded, on the node the UPID names | connection.view |
| Site Recovery | Nothing to fetch: a recovery execution carries no log column, so the panel is synthesized from the per-VM results the row already holds | none |
A Site Recovery line reads as one entry per VM: its status, the target node and VMID, the step it reached or the error it raised, and the restore point it used.
A refused read is reported as such under the Logs panel, with its HTTP status, instead of looking like a job that produced no output. This is what a role holding tasks.view but not automation.view sees on a rolling update or a replication job.
Actions
Actions are routed per type, and only the ones the backend can honour are offered. A button that did nothing when clicked was the rule before v1.4.8; there are none now.
| Type | Actions offered | Endpoint | Permission |
|---|---|---|---|
| Rolling Update, running | Pause, Cancel | The orchestrator rolling-update routes | automation.execute |
| Rolling Update, paused | Resume, Cancel | The orchestrator rolling-update routes | automation.execute |
| Migration, not finished | Cancel migration | The migration cancel route | vm.migrate |
| Migration, finished | none: the cancel route answers 400 on a terminal job | -- | -- |
| DRS, Replication, Site Recovery | none | -- | -- |
Cancelling a migration asks for a confirmation first, in the dialog itself, and states what cancelling really does: the pipeline stops, the volumes already copied stay on the target storage and have to be removed by hand, and the source VM is never modified. It is the same warning the inventory panel shows.
When an action is refused, the reason is displayed in the dialog: a 403 for a role without vm.migrate, a 400 on a job that has already finished. Before v1.4.8 a refused action looked exactly like a click that did nothing.
A replication job can be paused and resumed, but from Automation > Site Recovery, where the job and its schedule live. The Task Center deliberately offers no action for it, and none for a DRS move or a recovery plan execution, because the orchestrator exposes no way to stop those once they are running.
The ProxCenter tab of the tasks bar
The tasks bar at the bottom of the window has two tabs. Proxmox lists Proxmox's own tasks. ProxCenter lists the work ProxCenter drives: your own in-flight uploads and downloads, the migrations shared with your tenant, and, since v1.4.8, the same Task Center jobs over the whole history rather than the last 30 minutes only.
Each row carries its type icon, the job name, the detail line and a progress bar. Double-click a job row to open the very same detail dialog as the Task Center table, with its logs and its actions, from any page. A migration that is already listed as a shared task keeps its shared row, which carries the initiator's name and its own dialog, so the same migration never appears twice.
That feed is Enterprise-only, like the Task Center itself. It is polled once a minute, scaled by the global refresh interval of your account, and paused while the browser tab is hidden.
Operational Use
Use the Task Center during long-running operations such as migrations, rolling updates, replication syncs and DR tests. It is the fastest place to confirm whether ProxCenter is waiting on Proxmox, on the orchestrator, on storage I/O, on a failed command, or on you: a warm migration held for a manual cutover, a source VM that refused to shut down, and a virt-v2v conversion parked on a choice of system all surface here as a running migration whose detail names the wait. The buttons that resolve those waits live in the migrate dialog and in the VM panel, see Migration.
When investigating a failed job:
- Open the failed job with a double click.
- Read the last log lines first, and the error banner above the Logs panel.
- Check the target and the start time.
- Compare the timestamp with Events and the Audit Log if you need the user-action context.
Real-Time Updates
While at least one job is running, the page refreshes itself every 5 seconds. Otherwise it reads once and waits for the Refresh button. A row updates in place; there is no page reload and no toast.
Tenant Scope
A provider administrator sees every job on the connected infrastructure.
Every other caller is filtered deny-by-default: a job is kept only when every connection it references resolves inside the caller's perimeter, and a job that references no connection at all is dropped rather than passed through. This is what keeps a multi-cluster job (a replication, a failover, a cross-cluster migration) with one endpoint outside the perimeter from leaking the other cluster's name and per-VM results.
Migrations are the one deliberate exception to the shape of that rule, not to its strictness: they are scoped on the target Proxmox connection alone. The source is a hypervisor connection that a vDC tenant never owns, so requiring it inside the perimeter would have hidden every migration from the tenant that ordered it.
Permissions
| Permission | Description |
|---|---|
tasks.view | Open the Task Center and list its jobs. This is the only permission the page itself requires |
automation.view | Read the logs of a rolling update or of a replication job |
automation.execute | Pause, resume or cancel a rolling update |
connection.view | Read the Proxmox task log behind a DRS move, and list the tasks bar's Proxmox tab |
vm.migrate | Cancel a migration |
A role holding tasks.view alone therefore sees every job in its perimeter and can open any of them; it simply gets an explicit refusal in the Logs panel of the types whose log lives behind another permission.