Logs:
Line 3234: [19.10.2026 14:02:58.552] <558> Error (1) Original volume name is not specified for the shadow ( shadow volume id: '{00000000-0000-0000-0000-000000000000}'). (System.Exception)
Line 3242: [19.10.2026 14:02:58.553] <558> Error (1) Original volume name is not specified for the shadow ( shadow volume id: '{00000000-0000-0000-0000-000000000000}'). (System.Exception)
Zu dieser Problematik habe ich internen KB Artikel gefunden.
Environment
VBR v13
Veeam Plug-in for Proxmox VE / Veeam Plug-in for Oracle Virtualization / Veeam Plug-in for HPE VME
Backup job with guest processing enabled
Windows VM
QEMU Guest Agent / QEMU Guest Agent VSS Provider 110.2.3
Cause
QEMU agents starting from version 110.2.1‑1 (currently versions 110.2.1‑1 and 110.2.3‑2) got an update with known error in which instead of returning "VSS_E_OBJECT_NOT_FOUND" it returns "S_OK" with empty structure.
The QEMU Guest Agent VSS Provider is registered in the guest OS as a software VSS provider. Windows uses this provider during VSS snapshot creation, including snapshots requested by Application-Aware Processing. In this case, the provider returns a shadow copy without the original volume name, causing Veeam guest processing to fail when mapping the shadow copy back to the source volume.
"Failed to enumerate paths to shadow volumes."
"Original volume name is not specified for the shadow (shadow volume id: '{00000000-0000-0000-0000-000000000000}')."
The issue is resolved by using the previous QEMU Guest Agent version from December 2025. Removing the QEMU Guest Agent VSS Provider also allows the backup to complete, but this is not a recommended permanent solution because it affects Proxmox guest VSS functionality.
Resolution
1. On each affected Windows VM, downgrade QEMU Guest Agent from version 110.2.3 to the previous version from December 2025.
- Use the QEMU Guest Agent installer package provided by your Proxmox/VirtIO distribution source.
- Reboot the VM after the downgrade.
- Note: This change requires local administrator permissions in the guest OS and should be tested during a maintenance window.
2. Verify that the QEMU Guest Agent is installed and enabled according to Proxmox requirements:
- Proxmox host configuration:
https://pve.proxmox.com/wiki/Qemu-guest-agent#Windows:~:text=Installation-,Host,-You have to
- Windows guest installation:
https://pve.proxmox.com/wiki/Qemu-g...xt=reboot the guest.-,Windows,-First you have
3. On the affected Windows VM, verify the QEMU Guest Agent VSS Provider setting:
- Open Registry Editor as Administrator.
- Go to `HKLM\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider`.
- Set `VssOption` as `REG_DWORD` with value `5`.
- Reboot the VM.
- Proxmox reference:
https://pve.proxmox.com/wiki/VM_Backup_Consistency
- Note: QEMU Guest Agent updates can reset this registry value.
4. Rerun the backup job with Application-Aware Processing enabled.
5. Workaround only: If the downgrade cannot be performed immediately, temporarily unregister the QEMU Guest Agent VSS Provider inside the affected Windows VM:
- Open an elevated Command Prompt.
- Run: `qemu-ga.exe -s vss-uninstall`
- Confirm removal with: `vssadmin list providers`
- Rerun the backup job with Application-Aware Processing enabled.
- To restore the provider, run: `qemu-ga.exe -s vss-install`
- Warning: Do not use this as a permanent fix unless you accept the impact to Proxmox features that rely on the QEMU Guest Agent VSS Provider.
