@poddingue Fistst of all I appreciate your answer and your position. The thing is that, even though the proxy code itself is opensource, the functionality of the plugin is basicaly behind a paywall. We are not talking about support. Actual functioning of the plugin after compiling from sources depends on license availability and there is no option to select no support or something along the lines "I built it myself from sources". Without patching the code even though the proxy is otherwise functional the backups won't work because of missing license. Hopefully the powers that can will provide an acceptable albeit community supported way to use the proxy cleanly, without touching license checks. Best regards!

Pour l'ISO montée deux fois : My bad, j'ai ajouter un truc en trop sur mon précédent fix. Une PR est en cours pour corriger ça. Pour le problème principal : J'ai identifié la cause, mais je n'ai pas encore de solution. Sans les drivers Xen (non initialisés avant l'installation), une VM est limitée à 4 périphériques. La séquence de boot ne peut donc pas détecter le second disque contenant le fichier Kickstart (ks). Côté Packer, on semble être bloqués par cette contrainte XCP-ng. Les seules alternatives actuelles seraient de se limiter à : 2 disques + 2 CD ou 3 disques + 1 CD + HTTP (Note : L'installation manuelle fonctionne car l'installateur démarre directement, avec le driver xen_blkfront, alors qu'avec Packer, l'injection de notre fichier interrompt le flux de démarrage classique). Je vais fouiller encore un peu, mais sans certitude d'un contournement possible. (et je regarde pour ajouter le CDlabel)

We had the same problem during our maintenance window last night: HOST_NOT_ENOUGH_FREE_MEMORY error during "Migrate VMs back" phase. Pool usage data: Hosts 10 VMs 358 RAM Usage: 2.64 TiB (of 5 TiB=10x512GB) CPUs Usage 759 vCPUs (of 960 CPUs=10x96 CPU) latest XO from sources version 6.7.1 commit ID 40dede9 Log of RPU task: Rolling_Pool Update-HOST_NOT_ENOUGH_FREE_MEMORY.json.txt According to the log "Migrate VMs back" process was successful for all 10 hosts, still the final outcome of the RPU task is failure. We are still analysing the situation. Any advice is welcome! Actually we do not need the "Migrate VMs back" process at all. It is time consuming and prone to this error. We do not care where a certain VM runs. Is there an option to disable "Migrate VMs back" phase of RPU? That would be the best workaround for us! Obviously we could cancel the RPU task when "Migrate VMs back" starts, but it would not be a nice practice.

I put both of your questions on a spare host, because I couldn't answer either from memory. On colons: xe creates a key literally called auto_poweron:true with an empty value, so the entries you saw were three separate keys and none was the real auto_poweron, and typing false afterwards just made another one. It exits 0 and prints nothing every time, which I'd call a rough edge rather than a feature, though other-config is free-form by design so I don't know that the CLI is meant to validate keys at all. On the sleep: with rc.local executable and no sleep, it fired at 16 seconds of uptime and xe appliance-start came back with Error: Connection refused (calling connect ), exit 1, in under a tenth of a second. The VM stayed halted and nothing was reported anywhere, since rc.local has no terminal to print to. rc-local.service only orders after basic.target and network.target, nothing toolstack-related, while xapi-wait-init-complete.service took 30 seconds on that host, which is presumably why 60 was barely enough for you. There's an xapi-init-complete.target that looks like the right thing to order a unit against instead of guessing at a delay, though I haven't tried it so treat that as a lead rather than advice. The executable-bit half is in the docs now, it went onto the troubleshooting page after you reported it: https://docs.xcp-ng.org/troubleshooting/common-problems

@yomeyo It's a client shutdown being misreported as a client error. I'll fix this in the next release. The warning on upgrade should be harmless and you can simply close the application/click OK as you've done.

On a Lenovo SR630 V4 it took Power/Performance Bias set to OS Controlled, and on an HPE DL380 Gen 11 it was the iLO Power Regulator moved off Dynamic Power Savings to OS Control Mode, with a host reboot. Both then returned real values from xenpm get-cpufreq-para instead of the failure line. @bleader is right that two vendors is not enough to document, so if your host works, could you post the vendor, the exact setting name, where it lives, and whether you needed a reboot? Dell, Supermicro and anything AMD are the obvious gaps. I don't know whether the firmware is withholding p-state control outright or just not publishing the ACPI objects Xen looks for, so I would rather collect settings than write up a mechanism I can't back. Thanks!

@poddingue Here is the ouput of the command: $ xe host-list params=uuid,name-label,address uuid ( RO) : 8b0ac09d-a723-4a18-85ae-86660746d8aa name-label ( RW): frodo address ( RO): 192.168.1.13 uuid ( RO) : 2b1579d3-d45a-4d67-a423-20ddbbd61e00 name-label ( RW): meriadoc address ( RO): 192.168.1.12 uuid ( RO) : 7641f7a2-5774-4303-939f-afc3b6b4e35e name-label ( RW): samwise.somezone.net address ( RO): 192.168.1.10 With moving it to the Docker container, I only did that after I was already experiencing the same issue with a system that used the script to setup XO. I had hoped it was something on the XO side but it's seems more like it's the XCP-NG side.

Version 4.7 build 105 works fine with applied fix (modules/path). I have made upgrade form 4.5 -> 4.7, before update I have uninstall all plugins than upgrade to 4.7. Apply fixes and install plugins.

I put this on a spare host rather than guess at it twice. The delay runs after the start, not before it. With start-delay=20 the VM was up in about a second and the call then sat there for the rest of the twenty before returning. So the VM you set it on is already running, and what waits is whatever was going to happen next. Ordering does exist, but it belongs to vApps: an appliance groups VMs and order decides which goes first (https://docs.xcp-ng.org/vms/vm-lifecycle#vapps). The part that surprised me is that nothing starts an appliance when the host boots. I put both test VMs in one, rebooted, and they stayed down. Autostart is a single bulk start of everything flagged for auto power on, it walks them one at a time, and it ignores order. I set order=2 on a VM and it still went first. So a delay does hold up the VMs behind it at boot, which is probably what you were seeing, but you cannot pick which one goes first. For your NAS and seedbox I do not think there is a clean answer today. There is an open request for exactly that, a VM that waits on another VM: https://github.com/vatesfr/xen-orchestra/issues/8433, and your case would be a good one to add to it. What I still cannot explain is why yours stopped starting at all. A delay stalling the ones behind it would explain a late start, not one that never comes up.

@acebmxer No problem, that's excellent news, thanks for the feedback!

I forgot to mention: XOA Premium Current version: 6.6.2 (stable channel)

The July updates batch that went out on 28 July carries xapi-26.1.11-1.3.xcpng8.3, and @kagbasi-wgsdac has since confirmed on https://github.com/xcp-ng/xcp/issues/825 that three days after patching his disks are all visible again and reverting a snapshot no longer duplicates VDIs. The blog entry for that batch names the fix as non-snapshotted VBDs staying attached after VM.revert, a regression from xapi-26.1.4-3.3: https://xcp-ng.org/blog/2026/07/28/july-2026-updates-1-for-xcp-ng-8-3-lts/. Host reboots are needed. That stops new damage, but it does not unstamp VDIs that were already hit, so if disks are still hidden after you patch you probably still want the repair script at https://xcp-ng.org/forum/post/105564. My post above also had the mechanism wrong, and @kagbasi-wgsdac corrected it: the field being wrongly written is snapshot-of on base disks, not is-a-snapshot. If anyone is still watching disks disappear on a fully updated pool, please say so here, because that would be something new rather than the tail of this one.

XO 6.7.0 went out on 30 July, and the changelog carries Bastien's fix under Backups as "Fix failed status on successful retry", pointing at PR https://github.com/vatesfr/xen-orchestra/pull/10129 and back at this thread: https://xen-orchestra.com/blog/xen-orchestra-6-7/. Given what you said about keeping the backup XOA on a version you trust, I would not rush it, but that is the version to look for when you do move. I have not exercised the retry path myself, so if a retried VM still reports the job as failed after you upgrade, it is worth saying so here.

@christopher-petzel Great news! I will test and report after it is available in a global update. Thank you Christopher.

@andriy.sultanov @andriy.sultanov said: @pandusen As Teddy said above, you can't passthrough a PCI bridge, so there's no PCI devices xapi shouldn't omit here. I am not trying to pass through the bridge only the end points. The Intel arc's have 2 end points: The GPU and the Sound device. "xe pci-list" only reveals the GPU, not the sound device. (this works for nvidia and AMD) But "going the xen-cmdline way" shouldn't break anything, that's what xe pci-disable-dom0-access does behind the scenes. What issues did you see? Which steps did you follow? the sound device is available in the lspci list and can be passed through using CLI. But doing so, (using CLI for passtrough) undoes everything done using xe or the passthrough gui in XO. and results in this: https://xcp-ng.org/forum/topic/10609/xcp-ng-8.3-pci-passthrough-issue so yes, its does break something.

@djingo Hi ! Does all your VMs have guest tools ?

@pierrebrunet Hi! I'm on vacation now, so sorry for the delay. In the meantime I've been analyzing these issues and it seems these are somewhat expected and still happen with minpartsize set to 100M. My next step is to increase the AWS_MAX_ATTEMPTS from the default 3 attempts to 10. This might reduce the number of failed VMs and avoid the need to retry the full VM backup. From AI research, it seems rclone uses 10 attempts instead of the AWS SDK default. Here are some stats of my weekly full backup to B2: "00 Weekly Full Backblaze" ran xxxx → xxxxx — 34.1 hours total, moving ~2.86 TiB across 89 VMs. Final status: failure (more on that below, because it's misleading) -> this is related to XO reporting the backup as a failure even though the follow up retry succeded which is a known issue. Every one of the 7 first-attempt errors shows attempts: 3 in the SDK metadata — the default budget was exhausted in all cases -> 7 of 89 VMs failed on the initial attempt. Error mix: 5× Backblaze InternalError 500, 1× ECONNRESET, 1× EPIPE The 7 failed first attempts burned ~7.1 hours of cumulative transfer time Even though XO does not expose AWS_MAX_ATTEMPTS parameter I might be able to set it using an environment variable. I'll give a try when I'm back at the office. Tks, Pedro

@benapetr Good news, seems like the latest version for SM will implement vdi_revert which should work nicely with Ceph RBD. The only thing now is to have the newer Ceph kernel drivers in XCP-ng since the current driver is very old... (v12 I believe, we're now at v20, soon v22)