administrators group | XCP-ng and XO forum

olivierlambert

@john.c I really liked your "Jean C." signature before your edit You should keep it

poddingue

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.

poddingue

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

Nested RDP eating the arrow keys is not something I'd have guessed, and @AtaxyaNetwork's post probably explains why I went the wrong way too.
If the default selection is reinstall rather than install, that fits your log better than my disk-naming guess did, since the thing that aborted was ReinstallLayoutGenerator looking for an existing SYSTEM volume a fresh disk wouldn't have.
So the LVM error was probably the installer doing the right thing in the wrong mode, and my xvda theory was, at best, misleading.
I'm less sure about the other part, that the appliance doesn't support XCP-ng while B&R on Windows does, since AtaxyaNetwork seems to have the appliance running.
Where did that one come from, the Veeam docs or your support case?

Worth pinning down before it gets repeated.

poddingue

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.

olivierlambert

Great, thanks for the feedback!

poddingue

Thanks for the screenshot, that's a lot more useful than just telling us it failed. Reading it, I'm not sure it's failing to boot at all: anaconda starts fine, then Veeam's own pre-installation disk layout script gives up with "Could not find data volume group in the system LVM spec" and never writes the /tmp/pre-storage.cfg it then tries to read.
That would at least explain why Generic UEFI and Rocky 9 behave the same way. Your screen says there's a shell on TTY2, and if you run lsblk there I'd be curious whether the disks show up as xvda and xvdb rather than sda and sdb, which is how they usually turn up under XCP-ng.
That's a wild guess and I don't know their installer at all, but it might be worth putting in the Veeam ticket either way.

poddingue

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.

olivierlambert

Logs are providing interesting results. Discussing internally about it in the next week to see what could be improved about it.

administrators

Posts

Member List