Bonjour, et bienvenue dans la communauté. Je suis content (même si je n'y suis pour rien) que les tutos de @bvivi57 et @ataxyanetwork vous aient fait gagner du temps. A priori ce n'est ni normal ni voulu : le support de cd_files a été ajouté par la PR #144 (https://github.com/vatesfr/packer-plugin-xenserver/pull/144), mergée fin juin 2025, donc présent depuis la v0.8.1 du plugin, et la dernière version publiée est la v0.11.4. Ce qui me met plutôt sur une autre piste, d'autant que floppy_files échoue aussi chez vous : le ticket #151 (https://github.com/vatesfr/packer-plugin-xenserver/issues/151) décrit exactement ce symptôme, une image floppy que l'installeur ne voit pas en UEFI alors qu'elle passe sans souci en BIOS legacy. Vos builds RHEL démarrent-ils en UEFI, et avec quelle version du plugin ? Je ne connais pas assez le plugin pour en être certain, donc corrigez-moi si je me trompe.

Thanks for coming back with the actual cause instead of leaving it hanging. To me, a permissions reset on /etc/rc.d/rc.local would explain it completely, and it fails in the worst way, since nothing complains at boot and the VMs just never start. It also looks worth documenting, because our own troubleshooting page tells people to append a clocksource workaround to /etc/rc.local without mentioning the executable bit either, so anyone following that could end up with a workaround that quietly does nothing. I haven't tested whether the 8.2 to 8.3 upgrade resets that bit every time or just happened to in your case, so that half stays your finding, not mine. I'm curious what you turn up on the colon versus equals behaviour.

@poddingue Nothing reported yes since i was able to get the installer working, still in testing mode. I believe in beta only worked in B&R on windows but not in the appliance. I thought i read that support would come to the appliance in 13.1 that is why i was supporised when i did not see the option for it once it got it installed. If i overlooked something in the appliance please share the details.

That's a big jump, XAPI 24.19.2 to 26.1.11. I think the guard is deliberate rather than a bug: a metadata restore overwrites the whole XAPI database, so XAPI refuses when the builds don't line up. The docs at https://docs.xen-orchestra.com/xo5/metadata_backup#performing-a-restore warn about the overwrite but say nothing about version compatibility, which feels like a gap on our side. I don't know if there's a supported way to replay an older metadata backup onto a newer build, and I wouldn't want to guess at hand-editing it. Might be worth a mention to @Team-XAPI-Network, they can say whether a staged path exists, something like installing the matching older build, restoring, then updating. Correct me if someone here has actually pulled this off.

Great, thanks for the feedback!

@olivierlambert Happy to hear that they are providing results to be looked at. If there is anything else I can provide, please don't hesitate to ask. And I'll do my very best to be helpfull

Congrats on getting this out so fast after 6.7, and thanks for the writeup, genuinely interesting approach. The declarative angle instead of wrapper code per endpoint makes sense to me, especially given how often the REST surface grows. One thing I keep wondering about: you framed the auth/audit/fail-closed checks as sitting in front of the gateway. What happens when the model actually asks for something destructive, a VDI delete, a host disable, that kind of thing? Does the gateway block it outright, or does a human need to sign off somewhere in there? I'm asking because that's close to the exact boundary question our own Insights piece touched on this month. I'm community manager here, not a developer, so I'd rather ask than guess at how the security model actually behaves. Want to understand it properly before I say more. Passing this along internally too. No promises on timing, but it's the kind of thing worth a closer look.

A remote is not the same thing as a SR. For a remote, it's simple: disconnect it (click on "Enabled" so it's disabled then), do whatever you need on the NFS server, re-enable.

Excellent! It's really cool to see how XO Backup and Replication can help you to migrate easily

I think this is fixed in 6.7: when a delta backup falls back to a full, the task now shows the actual reason instead of just contradicting itself the way you and Andrew both saw (PR #10148). Worth checking after you upgrade.

Both things reported here look fixed in 6.7: the retry succeeding but the job still showing as failed (PR #10129), and the EEXIST: file already exists error, which happened when a job got recreated after a crash (PR #10139). Curious if upgrading clears it for you all too.

The progress bar issue you and Florent were chasing looks fixed in 6.7 (PR #10133). Worth upgrading and seeing if it moves now instead of sitting still. Separately, since this thread is specifically about QCOW2 backups: 6.7 also fixes an offset bug that could leave incremental backups mostly empty after the first block when NBD isn't enabled. Worth a look at the release notes if that's your setup too.

@florent [image: 1785422247634-backup-metadados3.jpg]

Hello, You can find all the demo dashboards at the following address: https://github.com/steeve-san/OpenMetrics_XCP_Grafana Regard,

This issue should be fixed in the latest release (to be out today).

@acebmxer Thank you for your quick feedback.

Glad the start-delay removal got that VM going again. I checked and it's a real, documented XCP-ng parameter, "the delay to wait before a call to start up the VM returns", so that explains the behavior. I couldn't find auto_poweron_delay documented anywhere in the XCP-ng or XO docs, so I'm not sure if it's something XO's advanced VM settings expose under a different name, or something unrelated you picked up while googling. If you check the VM's Advanced tab in XO and see what's actually set there, that would help pin down which setting you're really dealing with. Either way this looks like a gap in the autostart guide, since it doesn't mention that start-delay can interact with autostart at all.

Hello @anthoineb, We captured another occurrence on the same VM, os-ott-data-3-2 (172.30.52.193), on the same hypervisor and QCOW2 VDI as the incident reported on 2026-07-25. This occurrence is useful because xen_blkfront.max_ring_page_order=3 was definitely active: xenstore showed ring-page-order=3 with eight ring references; the guest queue depth was 256; 255 write requests remained in flight; all 256 blk-mq scheduler tags were busy; wbt_lat_usec=0; I/O PSI full was approximately 98%; completed xvdb counters did not advance between samples. The backend state was nevertheless the same as in the previous capture: tapdisk was sleeping in scheduler_wait_for_events(); tap-ctl reported reqs_outstanding=0; tap request counters were 0/0; req_prod=0 and rsp_prod=0; no tap, image, VBD, map or xenbus errors were reported. One detail may be relevant: GDB still printed n_reqs=32 and n_reqs_free=32, although the frontend had negotiated an order-3 ring and the guest exposed 256 tags. Is this expected because n_reqs represents a separate fixed tapdisk request pool, or could it indicate that tapdisk is not observing the complete multi-page ring? The controller captured GDB and the guest/hypervisor state before reboot. After the ten-minute diagnostic window, the same signature was confirmed three more times and the VM was rebooted. It rejoined the cluster successfully. I have attached: the complete GDB/tap-ctl capture; the guest blk-mq, diskstats, PSI, D-state stack and kernel-journal snapshot; the corresponding tapdisk/xenstore, daemon.log and SMlog excerpt; a README and SHA-256 checksums. The important new result appears to be that increasing max_ring_page_order from 0 to 3 did not prevent the stall; the same mismatch recurred with 255/256 frontend requests/tags occupied while the backend ring and tapdisk remained empty. 20260730-005220-gdb-172.30.52.193.txt 20260730-pre-reboot-guest-172.30.52.193.txt 20260730-pre-reboot-hypervisor-172.30.50.191.txt README.txt SHA256SUMS.txt

@acebmxer all good and thank you again for sharing your discovery on the forums