Good evening all,

Just a quick update. It's been a couple of days now after the rebuild and everything seems to be humming along fine, so I believe this topic can be marked as resolved. I can confidently conclude that this wasn't an XCP-ng issue, although the error message seems a bit misleading.

@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.

@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 Oh nice, hope it's not too cold over there. It's 9AM over here in Maryland and a bit nippy but not too cold.

Nope, no host or pool logs available (both are empty). Then again, I cleared all the alerts from the dashboard earlier this morning, so not sure if that's what wiped all the logs. I'm not too worried, as this is a testing environment so I'm using this host to do a lot of learning.

@julienXOvates Got it.

I didn't get a chance to work on this over the weekend, so sometime this week, I'll just bounce the host and see if it comes back. Right now, while I can SSH into it, the admin console appears to be frozen and unresponsive (over iLO).

Hello Folks,

I encountered a failure while attempting a Rolling Pool Update (RPU) on my two-node pool on Wednesday and wanted to report the logs to see if this is a known mirror issue or an orchestration edge case.

Environment:

Hypervisor: XCP-ng 8.3 (Two-node pool)
Management: Xen Orchestra (Community Edition / From Sources | Commit 5af3268 )
Update Method: Rolling Pool Update (RPU) feature via XO

Issue Description:
I initiated the RPU task via XOCE. The process failed during the host update phase. The RPU task in the XO UI appears hung (running since 2026-04-29 00:39), likely because the underlying yum process exited with an error that wasn't gracefully handled by the RPU state monitoring mechanism.

The Error:
The logs show a yum failure due to an HTTPS 500 Internal Server Error specifically when trying to fetch the xo-lite package from the mirrors. I can confirm there were no network outages at the time (since I was working remotely and my VPN connection to the site network dropped).

Relevant Log Snippet:

stderr: 'http://mirrors.xcp-ng.org/8/8.3/updates/x86_64/Packages/xo-lite-0.20.0-1.xcpng8.3.noarch.rpm: [Errno 14] HTTPS Error 500 - Internal Server Error
Trying other mirror.

Error downloading packages:
  xo-lite-0.20.0-1.xcpng8.3.noarch: [Errno 256] No more mirrors to try.'

Full JSON Log:

forum won't allow the full log, so I put it on pastebin.  Here's the link:  https://pastebin.com/raw/ueL86MiL

Notes:

It seems like a transient mirror issue, but I wanted to report it as it left the RPU task in a hung state in the UI for over 24 hours. I intend to clear the task and attempt a manual yum update on the hosts as a workaround, however, I'm going to hold off until the end of day today. Perhaps this will provide a live production environment, should the XCP-ng team wish to leverage it, for testing a fix.

Has anyone else seen 500 errors on the xo-lite package recently, or is there a specific mirror I should check?

As it stands now - 2026-05-01 04:30 - the RPU task is still hung (as shown in screenshot #1) and the first host (VMH01 - the pool master) is still in a disabled state (screenshot #2).

Thanks for all the work on 8.3!

SCREENSHOT #1 - Showing hung RPU task

SCREENSHOT #2 - Showing master host in disabled state

@dinhngtu Thanks for the fast response, as always.

Good-day Folks,

Running the XenClean.exe utility that ships with xcpng-winpv-9.1.146.0-Release-x64, on a Windows Server 2022 VM (Version 21H2 - OS Build 20348.5020) with Citrix Guest Tools v9.4.2 installed, results in the following error and a subsequent BSOD with stopcode = INACCESSIBLE_BOOT_DEVICE:

• [Alert] Cleanup FAILED: -2147467259 Msiexec failed with code 1605
• [Interactive] Cleanup task status is Error

Also, contrary to what's stated in the release notes, the VM does not automatically reboot. I suspect that's a consequence of the utility not completing successfully to trigger the reboot.

ULTIMATE SOLUTION FOR ME (might be different for you) :

• Mount any Windows ISO to the VM (I used the Windows Server 2022 ISO)
• Navigate to the Advanced tab of the VM and change the boot order so DVD-Drive is first (don't forget to click Save)
• Press any key, as prompted, to trigger a boot into the ISO
• Press next and select "Repair your computer"
• On the next screen select "Troubleshoot" and then "Command Prompt"
• You will now have a command prompt open and at the X:\ drive
• Type C:\ and hit enter to drop to the system drive for the installed OS
• Navigate to the folder holding the XenBootFix utility. For me it was C:\Users<MyUser>\Downloads\xcpng-winpv-9.1.146.0-Release-x64\package\XenBootFix
• Type XenBootFixe.exe C:\Windows and wait for the utility to finish, then reboot the VM.
• Install the XCP-ng Windows Guest Tools and reboot when prompted.
• After the VM boots back into Windows, confirm on the VM's General Tab that you see the message Management agent 9.1.145-77 detected.
• Don't forget to go back into the VM's Advanced tab and disable the DVD-Drive under Boot Order.

Sharing this, in hopes that the Vates team will see and address this issue, and it might help someone else out of a jam.

@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.