Feedback from Automation Project (vCPUs, VDI rename, boot order)

[kagbasi-wgsdac]

Hi Vates team,

I'm building an automated deployment tool that provisions VMs via the XO REST API (/rest/v0/). The tool needs to work on both Xen Orchestra from Sources (XOCE) and XO Appliance (XOA). I ran into a few API limitations and wanted to share what I found, along with the workarounds I implemented. Hopefully this feedback is useful.

1. cpus field in create_vm — XOCE vs XOA inconsistency

When calling POST /rest/v0/pools/{id}/actions/create_vm, XOCE accepts a cpus field in the request body to set the vCPU count on the new VM. XOA rejects the same payload with a 400 error citing "excess property".

Workaround: I send the payload with cpus included, and if the response contains "excess property", I retry without it. The VM inherits the template's vCPU count in that case, which is acceptable but not ideal — it means XOA users can't set vCPUs at creation time via the REST API.

Request: Could the cpus field be added to XOA's CreateVmBody schema to match XOCE behavior? Or if there's a different field name XOA expects, documentation would be appreciated.

2. No way to rename VDIs via REST API

When cloning a VM from a template, the new VM's VDIs (virtual disks) inherit their names from the template. In a Storage Repository with many VMs, this creates confusing duplicate names. I wanted to rename VDIs after creation to follow a {vm_name}_Disk0_OS convention, but the REST API doesn't appear to support PATCH or PUT on /rest/v0/vdis/{id}.

I also attempted using the JSON-RPC API (/api/) with vdi.set, but discovered that the JSON-RPC endpoint only supports WebSocket connections — HTTP POST to /api/ returns an HTML redirect rather than a JSON-RPC response.

Workaround: I document that users should name the template's VDIs descriptively before converting to a template, since those names propagate to all clones.

Request: Would it be possible to add PATCH support for VDI properties (at minimum name_label) to the REST API? Alternatively, if there's an existing method I'm missing, I'd appreciate a pointer. I see that this may have been mentioned here as well: https://xcp-ng.org/forum/topic/11970/request-add-patch-vms-id-for-updating-vm-properties-name_description-name_label

3. Boot order altered when cloning without vdis array (XO #4980)

When creating a VM via create_vm with clone: true and no vdis array in the payload, the resulting VM has network boot prepended to its boot order (e.g., "ncn" instead of "cn"). This causes the VM to PXE boot instead of booting from disk.

Including a vdis array in the payload — even if the VM doesn't need a new disk — preserves the correct boot order from the template.

Workaround: When no data disk is needed, I inject a temporary 1 GB dummy VDI in the vdis array to force the correct boot order, then delete it immediately after VM creation (before the first boot). This is obviously a hack, but it works reliably.

I believe this is related to XO issue #4980. Any update on whether this will be addressed in the REST API?

---

Environment

• XO versions tested: XOCE 5.x (built from sources, commit d1736) and XOA (v6.1.2)
• XCP-ng: 8.3
• API version: REST v0 (/rest/v0/)
• Automation context: Bash-based installer using curl for all API calls

Happy to provide payload examples or logs if any of the above would benefit from more detail. Thanks for the great platform — these are relatively minor friction points in an otherwise excellent API.

[olivierlambert]

Let me add @mathieuRA in the loop (and @Team-XO-Backend )

[MathieuRA]

@kagbasi-wgsdac
Hi, thanks for the feedback.

1. That's normal. It was a bug, and the fix was merged into the master branch two weeks ago. It's therefore available for XOCE, but for XOA, it will be available from version 6.3 (release in a few days).

2. Having PATCH enpdoint for all objects (VMs/VDIs/Networks/...) is already in our backlogs but need to be planned. (cc @gregoire XO-2232). Please also note that you can update a inherited VDI directly during VM creation if you know the VDI's user device. (For example: {userdevice: "0", name_label: "foo-bar"})
   

3. This fix is already planned to be part of the 6.4 release (cc @gregoire XO-1909)

[olivierlambert]

Thanks for the quick answer @mathieura