@acebmxer
Can you suspend the vm ?
If its not possible its most likely a kernel thing inside the vm.
If you can suspend the vm however, it points more to a timing/timeout issue with the migration.
Thanks for opening https://github.com/xcp-ng/xcp/issues/851.
I checked an 8.3 lab host with every update applied and it's the same there: tzdata-2024a-1.el7, and nothing newer in the updates or testing repositories. zdump -v America/Winnipeg on that host still has Manitoba falling back to CST on November 1st, so a host set to that zone would show local times an hour off from then on (UTC itself isn't affected).
I don't know how the team usually handles tzdata on the CentOS 7 based dom0, so a mention to @Team-OS-Platform-Release might help get #851 looked at before the 31st.
@poddingue said:
For the XVA, I'm not aware of release notes for the appliance image itself: it updates itself after import, and the notes that exist are per XO version, in the monthly blog post and the changelog, both linked from https://docs.xen-orchestra.com/getting-started/releases#release-cadence-and-channels .
The blog doesn't usually mention the base OS image itself, including things like openssh stuff, os version, server software, kernel, etc.
@poddingue Turns out it is all secondary-to-secondary out of sync. So that makes it less intense, though if primary dies I wonder how it will resolve this, or if it will become split brained. Still unsure of how it happened, but the ones I manually cleaned up have not come back. Going to continue to manually clear them up. If it happens again I will have an alert setup to notify me, and I have all the xcp-ng logs and everything to be able to see what happened.
If that happens I will post here with details and logs for the resource so we can see how it occurs.
[image: image.jpeg]
@AtaxyaNetwork Merci pour tes recherches !
Oui "cd_label" serait cool comme ajout au plugin ce qui permet sur les distro type Fedora/Redhat de ne pas avoir de boot_command à gérer
