Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    A
    @michael.manley Would it be possible to backport the XSA-498 fixes? I've tried updating the SDK as a whole but it resulted in a lot of churn and caused errors elsewhere: https://github.com/xcp-ng/xenadmin/pull/271 The fixes to the SDK have been posted here https://github.com/xapi-project/xen-api/pull/7176 and here: https://xenbits.xen.org/xsa/advisory-498.html last-genius opened this pull request in xcp-ng/xenadmin draft Update the SDK to 26.16.0 #271 alexbrett opened this pull request in xapi-project/xen-api open [SDK] Corrected certificate validation for HTTP calls #7176

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    I
    My Windows Server 2025 Standard VM randomly becomes completely unresponsive. No response via VNC console, RDP, or any network service. The VM shows as "Running" in XO/XCP-ng Center. RAM/CPU graphs in XO freeze at the last value. No errors or relevant logs in Windows Event Viewer (daemon/kernel), XCP-ng host logs, or hypervisor logs. Only solution is a forced reboot (or power off/on via XO). After reboot, the VM works normally for hours/days until the next freeze. This matches known Windows Server 2025 + Xen issues. Environment Hypervisor: XCP-ng (version: please add yours, e.g. 8.3.x) Orchestrator: XO (XOA) VM Details (from XO API / XO): { "id": "adf48a15-0b02-6fee-21d8-895190077680", "name_label": "<VM name>", "power_state": "Running", "virtualizationMode": "hvm", "os_version": { "name": "Microsoft Windows Server 2025 Standard", "uname": "10.0.26100" }, "CPUs": { "max": 4, "number": 4 }, "memory": { "size": 17179820032 }, "viridian": true, "pvDriversVersion": "9.1.145-77", "pvDriversDetected": true, "managementAgentDetected": true, "management agent": "9.1.145-77", "NIC type": "Realtek RTL8139", "VGA": "cirrus", "boot": { "firmware": "bios", "order": "cd" }, "other": { "base_template_name": "Other install media" } } Hardware Virtualization: PVHVM with paravirtualization drivers enabled. Storage: (please specify: local SR, NFS, iSCSI, etc. + VBD types) Network: Realtek RTL8139 (emulated) Steps Already Taken Viridian extensions are enabled (viridian: true). Latest XCP-ng Windows PV Drivers + Management Agent 9.1.145-77 installed. Windows Server 2025 is fully updated. Checked host logs (xl dmesg, journalctl), guest Event Viewer — nothing at the time of freeze. VM uses BIOS boot (not UEFI). Additional Context The freeze is completely random (no specific workload, time of day, or high load trigger observed). Reboot always resolves it temporarily. Similar reports exist for Windows 11 24H2 / Server 2025 on XCP-ng (Viridian synthetic timer, PV drivers, emulated devices). Questions Are there any known issues with Realtek RTL8139 NIC on Server 2025? Should I switch to a PV network driver / different emulated NIC? Any recommendations on VGA (cirrus) or other VM settings? Should I try forcing a kernel memory dump next time it hangs (xl trigger <domid> nmi)? Any other diagnostics or logs I should collect? Thanks in advance!

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    poddingueP
    Thanks, that complicates the large-VM theory in a good way. If these are long-established VMs that backed up fine for years, "too much free space on a new VM" probably isn't the whole story here. Your deltas run from a completely different XO instance, on a different host, to different remotes, at non-overlapping times, so "deltas never fail, fulls do" might not be purely about job type, it could be tangled up with which instance or remote is doing the work. If you ever get the chance to run a full from the XO instance that normally handles your deltas, that would help tell whether the timeout follows the job type or the instance. I could easily be wrong, though, but that split feels worth isolating before we lean too hard on the free-space angle in https://github.com/vatesfr/xen-orchestra/issues/9181 . MajorP93 created this issue in vatesfr/xen-orchestra open Full backup fails on large VMs / VMs with lots of free disk space #9181

  • Our hyperconverged storage solution

    49 Topics
    767 Posts
    poddingueP
    That it's stayed quiet since you throttled Velero is a good sign, and it lines up with the concurrency theory rather than anything about the specific volumes. Bumping dom0 RAM makes sense too, since linstor-satellite spiking to roughly 8,700 log lines around the panic suggests dom0 was under real pressure right then. If it does come back, a xen-bugtool --yestoall bundle from the host that panicked, plus the Loki window you already have, would give @Team-Storage something concrete to line up against the DRBD side. I'm not sure whether the real fix sits in Velero's pacing or in how LINSTOR handles concurrent create/delete, but the reproduction you've narrowed down is genuinely useful. Fingers crossed it stays boring from here.

  • Non-English speakers

    36 Topics
    117 Posts
    B
    Merci beaucoup pour vos retours ! @nathanael-h : C'est l'étape suivante !!! J'ai découvert cluster API le mois dernier et j'ai déja testé sur d'autres plateforme ! ça déchire !!! Je ne savais pas qu'il y avait un support de XCP-ng ! Je finis ma série d'article pour une installation classique et je bascule sur cluster API ! @ataxyanetwork Merci pour ton repo. Je vais regarder ça