@poddingue
With some trouble shooting with AI this is what I have to come back with.... Prior to posting this it struck me that i might have misconfigured this new xo deployment. I still had previous xo deployment and looked at its config for my installer and saw the xo service account was set to root. On the new deployment i forgot to change that and it used the default none root user. I then switch the user to root and still and issue. Below are the logs and issues from AI while XO service account was none root.
I hit what I believe is the same thing, and I have a stack trace that points at a specific regression rather than the certificate issue from #7496.
Setup: XO from sources, xo-server v5.206.0, XCP-ng pool, non-root service user.
Symptom: identical to the original post — "Importing content into VDI XO CloudConfigDrive" appears to do nothing, the VM boots with no IP, console is unusable, and the exact same cloud-init config works fine on XOA. Nothing is shown in the UI.
The reason nothing shows up in the UI is that the error is caught and downgraded to a WARN, so you only see it in journalctl -u xo-server:
2026-07-29T21:54:49.406Z xo:xapi WARN importVdiContent: {
error: TypeError: stream.on is not a function
at watchUploadProgress (file:///opt/xen-orchestra/@xen-orchestra/xapi/_watchUploadProgress.mjs:25:10)
at Xapi.importContent (file:///opt/xen-orchestra/@xen-orchestra/xapi/vdi.mjs:295:7)
at Xapi.createCloudInitConfigDrive (file:///opt/xen-orchestra/packages/xo-server/src/xapi/index.mjs:1545:5)
at Xapi.createCloudInitConfig (file:///opt/xen-orchestra/@xen-orchestra/xapi/vm.mjs:435:14)
at Xo.<anonymous> (file:///opt/xen-orchestra/packages/xo-server/src/api/vm.mjs:191:26)
at Task.runInside (/opt/xen-orchestra/@vates/task/index.js:204:22)
at Task.run (/opt/xen-orchestra/@vates/task/index.js:188:20)
at Api.#callApiMethod (file:///opt/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:475:18)
(The warning is followed by a very large dump of the pool_master / SR / VDI objects, trimmed here.)
Probable cause: createCloudInitConfigDrive builds the config drive as an in-memory Buffer and passes it to importContent. importContent now calls watchUploadProgress(stream, stream.length, …), and that helper calls stream.on('data', …). A Buffer has .length — so it passes the existing if (stream.length === undefined) guard — but it has no .on() method, so it throws. Every other caller of importContent passes a real stream; the cloud-init config drive appears to be the only one passing a Buffer.
_watchUploadProgress.mjs is new — it has a single commit in its history:
$ git -C /opt/xen-orchestra log -1 --format='%h %ad %s' -- @xen-orchestra/xapi/_watchUploadProgress.mjs
76b45a9b3 Mon Jul 27 10:23:29 2026 +0200 fix(xo-server): ensure import task progress is correctly updated (#10133)
That would explain why XOA is unaffected (it lags master) while XO from sources breaks, and why this started recently.
Knock-on effect: because the failure is swallowed by a .catch(), the deferred VDI cleanup never runs and execution continues to VBD_create. The VM ends up with a config drive attached that was never written to — so cloud-init finds no user-data at all, which matches the "no IP, no DHCP request" symptom. Any VMs created during the failure need to be deleted; fixing XO won't repair them.
Local workaround — in @xen-orchestra/xapi/_watchUploadProgress.mjs, returning early when the input isn't a stream:
if (stream == null || typeof stream.on !== 'function') return
Progress reporting on a 10 MB in-memory buffer isn't meaningful anyway. This is just a local patch that a rebuild will overwrite — posting it as a datapoint, not a proper fix.
