Feature request: Allow PS/REST vSphere restores to use restore point network metadata when the source vCenter is unavail

[mv@cloudio.dk]

Feature request: Allow PS/REST vSphere restores to use restore point network metadata when the source vCenter is unavailable

Hi,

Following up on this topic after review with Veeam Support.

Support confirmed that there is an expected behavioral difference between restores started from the VBR UI and restores started through PowerShell or the REST API.

In my scenario, the original/source vCenter is intentionally unavailable during a DR restore test. The restore point still contains the original NIC/network metadata, including the source DVS port group MoRef, network name, and related metadata.

The VBR UI can successfully restore the VM and map/connect the NIC because it can fall back to network information stored in the VMX/backup metadata.

However, PowerShell and REST currently appear to depend on live source vCenter inventory:

- PowerShell uses `Get-VBRViServerNetworkInfo`
- REST validates `sourceNetwork` through inventory lookup
- If the source vCenter is offline, REST fails with HTTP 400:
`Cannot find target network: [hostName: source-vcenter.example.local, objectId: dvportgroup-xxxxxx]. (Mapping rule number: 0)`

Also see my post here: restful-api-f30/vbr-rest-api-vsphere-en ... 03269.html

Feature request:

Please add a supported fallback path for PowerShell and REST API vSphere restores so that network mapping can use source NIC/network information already stored in the restore point metadata, the same way the VBR UI can.

Expected behavior:

When starting a customized vSphere Entire VM Restore through PowerShell or REST API, it should be possible to map a backed-up source NIC/network to a target vSphere network even if the original/source vCenter is unavailable, as long as the source network identity exists in the restore point metadata.

Possible implementation options:

1. REST API accepts a source network reference from restore point metadata without requiring live source vCenter validation.
2. REST API allows network mapping by source NIC index/device key plus target network.
3. PowerShell exposes a supported way to retrieve and use the restore point source network metadata for `Start-VBRRestoreVM`.
4. A restore option is added to let PS/REST use the same VMX/backup metadata fallback behavior as the VBR UI.

Why this matters:

In DR testing or real DR scenarios, the original vCenter may be offline or intentionally unavailable. Automation through REST API or PowerShell should still be able to restore VMs to a DR vCenter and attach them to the correct target networks. Today this works from the UI, but not through PS/REST automation.

Support case reference: 08102510

Thanks,
Martin