@olivierlambert & @mathieura thanks for the speedy response. Duly noted, very much appreciated.

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.

@dinhngtu Yeah, I suspected that as well. So I inspected the SR and it showed connected to both hosts (at least in the XO UI - I didn't drop to the CLI to really confirm).

By altering my workflow a bit and slowing down, I seem to have found the right "sweet spot" of delay and the issue hasn't resurfaced. Here's what I'm doing now, when I need to revert the snapshots of all three VMs:

• In the XO VM list, I select the three VMs and power them off at the same time.
• I then start with VM1 and eject the ISO, VM2 and eject the ISO, then VM3 and eject the ISO. By the time I circle back to VM1 for the next step, about 10-15 secs have elapsed.
• I then start with VM1 and revert the snapshot, and repeat the same on VM2 and VM3. By the time I circle back to VM1 for the next step, another 10-15 secs have elapsed.
• I re-attach the ISO to all three VMs in sequence. Another 10-15 secs elapse.
• I then start with VM1 and power all three VMs sequentially.

The entire workflow takes about 30-45 secs, and I'm finding that by doing this, the issue hasn't resurfaced.

Hello Folks,

I need help understanding why a VM, restored from snapshot, randomly cannot see any ISOs from any SRs.

My Environment:

HOSTs: XCP-ng 2-node pool at v8.3.0 on HP (ProLiant DL360p Gen8) - All patches applied
XO: Community Edition at commit d1736
NETWORKING: 1Gbps Management only (no dedicated storage LAN yet - coming soon)
STORAGE: Shared NFS Storage Repository (hosted on a separate TrueNAS Server. Dataset for ISO SR is showing 13 TiB capacity, ~90 GiB used)

Background of the Situation:

I'm developing an automated solution that leverages both SSH and the API to either provision VMs or directly SSH into a running VM and run my script. Both paths require the use of a VM Template, which I've created and have been successful in using to build the cloned VMs. As part of my development work, I've been testing functionality incrementally, and this involves sometimes starting with a fresh VM. So I will revert a snapshot and then start over. I started noticing that, at random times, one of the VMs will simply stop seeing the ISO SR. No amount of rescanning the SR seems to resolve it (see screenshot below). My only resolution, to date, has been to simply remove the VM and create a new one from the template. At first I thought this was isolated to a specific VM, but it has happened on a second VM a few moments ago, so I no longer think this is isolated.

I can confirm that the ISO is present on the ISO SR and I can see it in XO. Also, that specific ISO is mounted to other VMs, so I don't suspect that the ISO is the problem - could be, but I don't think it is.

Has anybody run into this problem before? If so, what did you do to resolve it?

.

QUICK UPDATE (shortly after posting this) :

So I was about to delete the VM and rebuild it from template, when a thought occurred to me - "Kismet, why not try the snapshot reversion one last time?" So I did, and wouldn't you know it, the VM is now able to see the ISO SR and attach the ISO. Strange. I don't understanding what just happened; perhaps some kind of delayed processing in the background? Or perhaps, I'm moving too fast and need to slow down? Here's a screenshot.

@johnny I think the Vates VMS (whether you go with paid support or not) would fit your use case perfectly. Since each host is essentially a pool of one, you would pretty much have multiple pools managed by a single Xen Orchestra instance (giving you a single pane of glass, if you will). You could augment this with XCP-ng Center.

As @olivierlambert correctly inquired, you should contact the Vates Team and have an in-depth discussion into your situation.

@olivierlambert Yes sir, it is and I'm glad I confirmed this for myself. Thanks also for helping me understand how the VM Suspend process works. Hopefully this post helps other newbies with the same understanding in the future.

Here's the latest, and probably last, test. Disabling compression had no appreciable impact on performance. I am now fully convinced that SYNC is the major player here.

@olivierlambert Oh okay, thanks for responding.

So I turned off SYNC and COMPRESSION on the dataset and retested (by suspending 11 VMs), I immediately noticed a whopping performance improvement (essentially sustained wire speeds AND 50% faster completion time*) :

• Roughly 984 Mb/s sustained WRITE speeds (during VM suspension)
• Roughly 984 Mb/s sustained READ speeds (during VM resumption)
• Transfer time for both READ and WRITE is about 20 minutes (down from 40-45 mins)

Gonna retest with SYNC disabled and COMPRESSION re-enabled and see if it degrades performance; standby for another report.

@olivierlambert Yes, I do plan on testing with SYNC disabled and then again with several permutations of dataset changes on the TrueNAS side (like compression on/off, etc.).

Do you guys have a best practices document for setting up an NFS SR using TrueNAS? I browsed through the published XCP-ng documentation site but didn't find anything specific to TrueNAS or maybe I missed it.

Sharing this so others might benefit from what I'm learning.

So, I looked at the network performance on TrueNAS during the Smart Reboot of the second XCP-ng host (screenshot below). What I saw seems to suggest that I'm getting near wire speed during READ operations. However, WRITE operations seem to be hitting a ceiling and I have a feeling it might be due to me having SYNC enabled on the dataset.

@olivierlambert Aaah, I've always wondered what the Suspend SR on the Advanced tab of the Pool meant......now I know.

So, the NIC capacity/pipe between the hosts and the SR does really matter here.

Good-day Folks,

I need help understanding the VM Suspend process: why does it take so long for XO to suspend a VM, triggered by a Smart Reboot of a Host?

My Environment:

HOSTs: XCP-ng 2-node pool at v8.3.0 on HP (ProLiant DL360p Gen8)
XO: Community Edition at commit c5ba7
NETWORKING: 1Gbps Management only
STORAGE: Shared NFS Storage Repository (hosted on a separate TrueNAS Server)

Today, while applying the latest host patches, I wanted to try doing a Smart Reboot. After pressing the button and acknowledging the prompt that VMs will be suspended and then un-suspended after the reboot, and quickly navigated to the Tasks page to monitor the progress. I immediately saw one VM quickly show progress from 0%, 10%, 30%.......100% and boom, it was suspended. The others, however, not so much. As you can see from the two screenshots below, they are still pending suspension and the Estimated End keeps shifting to the right.

I don't have a 10Gb Storage Network between the hosts yet (working on it). However, I didn't think that should have such an impact. Anyway, I don't think I have a proper understanding of how the suspend operation should be working, so if anyone cares to educate me, I would really appreciate it. Thank you.

Screenshot Taking After Pressing Smart Reboot on the Master Host

Screenshot Taking After Pressing Smart Reboot on the Master Host (10-minutes later)

@olivierlambert Yep.

Here's the video of the test - https://www.youtube.com/watch?v=tiVdR74PNjw

@olivierlambert Just ran the test on both XOCE and XOA, and looks like it takes about 8 minutes to get to 8.6GB downloaded before the transfer rate drops to zero. I also observed the transfer rate drop to zero at 8.3GB for a short while before picking back up and stalling at the 8 minute mark.

I made a video of the test - it's uploading to my YouTube channel now, when it finishes I'll update this post with the link.

@olivierlambert I didn't time it. I'm leaving home to drop the kids off at school, then off to work afterwards. I'll run it again and time it and report back.

@olivierlambert You were right. Looks like while we were troubleshooting this issue (about two days ago), I ran an xe vm-export command, though it failed, enough of the XVA file got created and that was sufficient to fill the partition up.

This didn't become obvious until I opened XCP-ng Center today and saw the following alarm:

Disk Usage for Control Domain on server 'WGSDAC-SV-VMH01' has reached 92%. 
XCP-NG's performance will be critically affected if this disk becomes full. 
Log files or other non-essential (user created) files should be removed.

So I deleted the culprit file and freed up the storage space, and now the export is downloading. However, it's timing out before all the file is downloaded. It gets all the way up to about 8.6 GB downloaded then the transfer rate drops to 0 B/s.

I suspect this is due to the file being deleted on the host before the transfer completes. Is there a quick way to increase the timeout?

From XOCE Instance:

From XOA Instance:

@Danp Unfortunately, I don't see any errors in the log of the VM or on the Host. Within the browser's console, the only thing that comes up is the following:

Fortunately, when I attempt the operation via the xe cli, it results in the following error:

Yet the XOCE pool tasks showed that it completed successfully:

@Danp As requested:

My Use Case:
I am performing a Proof-of-Concept within an air-gapped environment at work. One of tests I'm performing is to validate the VM Export/Import functionality. So I exported this VM from the air-gapped lab environment I've setup at work and brought it home to test if I could import into the pool running at my church (on a physical host). However, it suffered a catastrophic drive failure and I ended up having to rebuild it. With the rebuild done, I was able to import the VM successfully. Now I'm attempting to export it so I can take it back to work and import it, to complete my testing.

As requested, neither clicking the Download VM link nor the OK button result in a successful download. I'm using Chrome, and have also tried Edge. I don't have Firefox on my PC, but I could install and test if you think it's necessary.

@Danp Just got in the car to drive to work. I'll try doing what you've asked when I get to work (in about an hour).

@Danp Yes, understood - but a short period of time is a rather vague statement, don't you think?

I tried doing the download immediately after I copied the link, failed each time. So I decided to wait for the export task to complete then execute the download - it also fails. Do you know where the xva file is stored temporarily? Perhaps I can access the file system and move it to another location before it gets deleted.

I recall that when I exported this VM from the test lab at work, I experienced a similar issue and I simply paused the download (within the browser) and then resumed it, and that's how I got the transfer to start. Unfortunately, I wasn't tracking the precise timing of that, as it seemed rather random. I also tried that on this system, to no avail.

Also, does the temporary file get stored on XO or on one of the hosts?