Categories

  • All news regarding Xen and XCP-ng ecosystem

    146 Topics
    5k Posts
    J
    @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.
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    gduperreyG
    Hello, We have received your request and thank you for the feedback on this matter. A task card has been created and assigned to one of our teams. It has not yet been assigned to a specific developer, but we will be sure to get back to you once it has been addressed and resolved.
  • 3k Topics
    29k Posts
    J
    @Forza said: @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. It may not do that but since it’s currently based on Debian Linux it’s either version 12 or 13, having been for a long time version 11. Knowing this you may be able find out a lot of what your listing, unless Vates swaps out the vanilla versions for newer or older ones than the base distribution. @poddingue This can be handled quite cleanly by including a simple package inventory (via dpkg -l) for the XVA, saved as a JSON file, along with a "built-on" date within the download portal to accompany the standard checksum. Can this please be developed and implemented on the download portal where we grab the XVA, and/or where the Security Advisories are held? Providing this metadata upfront would solve a major visibility gap for two critical reasons: Pre-Boot Compliance & SBOMs: Many enterprise security teams require an asset and package review before an image is ever imported or booted in a production cluster. Having a verifiable JSON manifest alongside the download allows admins to satisfy compliance and Software Bill of Materials (SBOM) requirements without forcing a "blind" deployment. First-Boot Vulnerability Window: Because the XVA acts as a snapshot frozen in time until it hooks into the Vates update servers and Debian repos, it inherently contains a window of unpatched packages upon its very first boot. A build date and package list give engineers immediate clarity on what baseline versions (like OpenSSH or the kernel) are active during that initial setup window. This wouldn't require changing how the appliance itself updates, but it would provide immense public clarity and enterprise readiness for the deployment process.
  • Our hyperconverged storage solution

    54 Topics
    824 Posts
    J
    @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]
  • 37 Topics
    136 Posts
    J
    @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