Feature Request (08035060) – Proxmox VE: Restore Progress Visibility, UI Disruption During Restore & Log Export

[donkeymagic]

Hi all,

I have been asked by a senior Veeam support engineer to raise this as a formal feature request following a support case in which the issues below were investigated and confirmed. I am linking this post to that case (08035060) for reference. I want to be clear that this is not a general complaint but a structured request based on hands-on testing across multiple restore scenarios, with video evidence submitted to and reviewed by the Veeam support and R&D teams. I appreciate that some of these may already have topics and posts in other sections but I was advised to post anyway.

All three points relate to the operational experience of the Veeam Plug-in for Proxmox VE and have been structured as separate sections as recommended.

Currently running Veeam Backup and Replication Windows Install not appliance 13.0.1.2067, PVE 9.1.6 and Proxmox Plugin 13.3.1.7

---

1. Restore Progress Visibility

Current behaviour: The Proxmox restore window provides no meaningful real-time feedback during a restore operation. The elapsed time counter was observed to freeze completely at 57 seconds for the entire duration of a 16-minute restore, with only the start and end timestamps updating. No data throughput, processing speed, or progress indication of any kind is displayed during the restore.

Comparison: Every other restore workflow within Veeam (VMware, Hyper-V, M365, Salesforce) provides at minimum a progress bar, data transfer rate, and operational metrics. The Proxmox restore window is a notable departure from this standard.

Impact: In a production environment, having no indication of restore progress, throughput, or whether an operation has stalled creates a significant operational risk. There is currently no way to distinguish between a restore that is progressing normally and one that has genuinely hung.

Request: Please implement restore progress metrics for the Proxmox plugin consistent with other Veeam restore workflows, including progress indication, data throughput statistics, and detection or indication of stalled operations.

---

2. Proxmox UI Disruption During Restore Operations

Current behaviour: During Veeam restore operations via the Proxmox plugin, the Proxmox web interface becomes partially or fully unmanageable. Specifically, all VM display names disappear and are replaced solely with their numeric VM IDs, and VM power state changes made during the restore are not reflected correctly in the interface until the restore completes.

This was reproduced across multiple restore scenarios:

- VMware to Proxmox restore (Test 1): VM names dropped to IDs for approximately 10 seconds during the finalisation phase.
- VMware to Proxmox restore (Test 2): VM names dropped to IDs at the start of the finalisation phase and did not recover for approximately 51 seconds.
- Proxmox to Proxmox restore: VM names remained visible, however stopping and starting VMs during the restore resulted in incorrect power states being displayed in the interface. A VM that was stopped did not show as stopped, and a VM that was started did not show as running, until the Veeam restore completed.

For comparison, none of this behaviour is observed during other Proxmox operations such as native Proxmox backups, clones, or migrations. The issue appears to be specific to how the Veeam plugin interacts with the Proxmox API during restore operations.

Impact: During a restore in a production environment, administrators are unable to reliably manage other VMs on the same host. This is a meaningful operational concern, particularly if other workloads need to be managed concurrently during an incident.

Request: Please investigate and resolve the Proxmox API interaction during restore operations to prevent disruption to the Proxmox interface and ensure VM state is accurately reflected throughout the restore process.

---

3. Log Export Granularity

Current behaviour: When exporting logs from Veeam Backup and Replication for a support case, it is not possible to select Proxmox jobs specifically. The Proxmox job is visible in the export dialog but cannot be selected individually, requiring a full VBR log bundle export regardless of which job or platform is relevant to the issue being investigated.

Impact: This creates unnecessary overhead when submitting logs for support cases, as the full export is significantly larger and more time-consuming than a targeted per-job export would be.

Request: Please add per-platform and per-job log export selection to the log export dialog, consistent with the level of granularity available for other job types.

---

I appreciate that the Proxmox plugin is a relatively early release and that Veeam is actively expanding hypervisor support. These requests are intended to be constructive and are based on real-world testing. I am happy to provide further detail if it would help the product team evaluate any of these points.

This post has been raised at the recommendation of a senior Veeam support engineer following investigation of support case [08035060].

Thanks

Oliver

[david.domask]

Hi Oliver,

Thank you very much for the detailed request, will respond point by point:

1. Restore Progress Visibility

Planned for 13.1, stay tuned.

2. Proxmox UI Disruption During Restore Operations

Will discuss internally on this one, will update the thread later once we have more information.

3. Log Export Granularity

Request is noted, we will discuss internally on the possibility for future releases; this will likely be focused on the WebUI however as we focus our console efforts on migrating completely to the WebUI.