VBR REST API vSphere Entire VM Restore fails with 500 when using network mapping (cross-vCenter)

[mv@cloudio.dk]

Subject:
VBR REST API vSphere Entire VM Restore fails with 500 when using network mapping

TLDR:
I can successfully start a VMware vSphere Entire VM Restore through the VBR REST API when the network block is omitted. However, when I include explicit source-to-target DVS network mapping, the API returns 500 ServiceUnavailable / Unknown error. The original/source vCenter is not available at restore time, so the sourceNetwork object is built from restore point metadata/AuxDataRaw, while the targetNetwork object is resolved from live target vCenter REST inventory. I would like to confirm whether this scenario is supported and what the correct JSON structure should be.

Hi,

I am testing automated VMware vSphere Entire VM Restore using the VBR REST API.

Endpoint:
POST /api/v1/restore/vmRestore/vSphere

VBR REST API version:
1.3-rev1

Scenario:
I want to restore a VM to a customized vSphere location and select a new target network during restore.

The restore works when I omit the network block from the REST body.

When I include explicit network mapping, the restore fails immediately with:

{
“errorCode”: “ServiceUnavailable”,
“message”: “Unknown error”,
“title”: “Unknown error”,
“status”: 500
}

Additional important detail:
At restore time, the original/source vCenter is not available or not connected to the VBR server. The restore point still contains source network metadata, and I am building the sourceNetwork object from restore point metadata/AuxDataRaw. The target host, datastore, folder, resource pool and target DVS port group are all resolved from live REST inventory on the target vCenter.

What has been validated:

* restorePointId is valid
* destinationHost is valid
* datastore is valid
* destination folder is valid
* resource pool is valid
* destination host, datastore and resource pool are in the same vSphere cluster
* target network is visible in Veeam REST inventory
* restore starts successfully when the network block is omitted

Working case:
The restore starts successfully when the REST body does not include the network section.

Failing case:
The restore fails with 500 when I include network mapping like this:

“network”: {
“networks”: [
{
“sourceNetwork”: {
“type”: “DVSNetwork”,
“hostName”: “source-vcenter.example.local”,
“name”: “source-portgroup-name”,
“objectId”: “dvportgroup-123456”,
“urn”: “vc:source-vcenter.example.local;dvsnetwork:dvportgroup-123456”,
“platform”: “VSphere”,
“size”: “N/A”,
“isEnabled”: true,
“metadata”: []
},
“targetNetwork”: {
“type”: “DVSNetwork”,
“hostName”: “target-vcenter.example.local”,
“name”: “target-portgroup-name”,
“objectId”: “dvportgroup-654321”,
“urn”: “vc:target-vcenter.example.local;esx:host-123456;dvsnetwork:dvportgroup-654321”,
“platform”: “VSphere”,
“size”: “N/A”
}
}
],
“disconnected”: false
}

The source VM backup originally came from one vCenter:
source-vcenter.example.local

The restore target is another vCenter:
target-vcenter.example.local

Question:
Is network mapping supported for VMware vSphere Entire VM Restore through the VBR REST API when restoring to a different vCenter / DVS, especially when the original/source vCenter is not available at restore time?

If yes, what is the correct JSON structure for mapping the source NIC/source network from restore point metadata to a target DVS port group?

If no, is this an API limitation, a known issue, or should this be handled as a support case?

The main goal is:
Restore the VM as a new VM to a customized vSphere location and attach it to a selected target network during the restore operation.

Thanks.

[mv@cloudio.dk]

**Update after further testing**

I've tested two variations of `sourceNetwork` — one with `hostName` and one without:

Code: Select all

"sourceNetwork": {
  "type": "DVSNetwork",
  "hostName": "source-vcenter.domain.local",
  "name": "source-portgroup-name",
  "objectId": "dvportgroup-111111",
  "platform": "VSphere"
}

Both return the same 500. I also normalised `targetNetwork` to match the same field shape (explicit `type`, `hostName`, `name`, `objectId`, `platform`, no `urn`). Still 500.

One thing I noticed: the failing request consistently takes **9-10 seconds** before returning 500, regardless of what's in `sourceNetwork`. An instant failure would suggest a validation error — the delay makes me wonder if something is trying to reach out to the source vCenter internally.

Does anyone know if network mapping in this endpoint requires the source vCenter to be reachable? Or is there a different way to structure the request for cross-vCenter DR scenarios?