XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. Popular
    Log in to post
    • All Time
    • Day
    • Week
    • Month
    • All Topics
    • New Topics
    • Watched Topics
    • Unreplied Topics

    • All categories
    • P

      RDNA 4 GPU Passthrough

      Watching Ignoring Scheduled Pinned Locked Moved Compute
      22
      0 Votes
      22 Posts
      480 Views
      P
      for future reference here is the xl dmesg at this point xldmesg.txt
    • acebmxerA

      Backups failing back to Full Backups

      Watching Ignoring Scheduled Pinned Locked Moved Backup
      9
      0 Votes
      9 Posts
      109 Views
      olivierlambertO
      Indeed, it should be detected/reported correctly to avoid losing time finding the problem. Let me ping @julienXOVates
    • H

      Potential bug with Windows VM backup: "Body Timeout Error"

      Watching Ignoring Scheduled Pinned Locked Moved Backup
      94
      3
      2 Votes
      94 Posts
      15k Views
      C
      I checked my hosts and the clocks all seem to be very close in time, certainly within a second of each other. The one difference is that the host that is often the target for the backups is set to UTC and the other two are set to MST. Clearly an oversight on my part, unless it is purely a display issue. When I ssh into dom0 and use date, those two show MST and the other shows UTC. If that has ever changed, it would most likely have been in the upgrade from 8.2 to 8.3, which I performed on Jan 28. All that said, this body timeout issue happens to me every day on random VMs within my backup. Occasionally a backup will complete with none of these errors on any VM but that's uncommon. All of the failed backups are from VMs or configs on the two MST hosts and are stored on the UTC host. (To be clear, they are also stored elsewhere.) I also have an XO instance on one of the MST hosts that performs delta backups and those have never failed. I don't know if that's because they are delta or if it's because they don't touch the UTC host. The recent failed backups started on 6/26 for my VM full backups and on 6/29 for the config backups. Prior to that the config backups had never had a problem and the full backups had been fine back into February. From February 21 to March 12, I had a smattering of backup failures due to body timeout error for the full backups.
    • P

      Error mirroring full backups to backblaze b2

      Watching Ignoring Scheduled Pinned Locked Moved Backup
      18
      2
      0 Votes
      18 Posts
      1k Views
      P
      @florent Sorry, missed your previous post. I will return to master and test it (over the weekend). Thank you!
    • pkgwP

      Rolling Pool Update fails with HOST_NOT_ENOUGH_FREE_MEMORY, when it really ought to be fine

      Watching Ignoring Scheduled Pinned Locked Moved Management
      6
      1
      0 Votes
      6 Posts
      145 Views
      A
      @pkgw Planning an RPU as a whole is a nice idea in theory, but it's inherently designed to co-exist with normal pool management operations (you should still be able to migrate VMs between hosts B and C during it, or start new ones), we are not "pre-booking" memory and other resources for groups of VMs, otherwise it can quickly make the rest of the pool hard to manage while some VM migrations could still be far away. Regarding the narrower case - I'll note this down and see if we can improve things, thank you!
    • F

      Dual video adapters - what should I see, and where?

      Watching Ignoring Scheduled Pinned Locked Moved Hardware
      8
      0 Votes
      8 Posts
      678 Views
      F
      Hardware update: Got a couple M9148 (4 port Matrox DP) and Wavlink WL-UG7500DH (4 port DP/HDMI) in to test. Configured a Win11 Pro VM with the Matrox driver. It broke the VM so severely that I had to re-pave. So, I pulled the card, swapped for a Wavlink and created another Win11 Pro VM - to which I assigned the Wavlink card and loaded their drivers. It works flawlessly. Both HDMI displays I had connected were instantly recognized in Device Manager and available. I then shut it down, created another VM with Mint 22.3 and assigned resources exactly per the Windows machine. Installed the Wavlink Ubuntu driver and DisplayLink. Rebooted. Still only see the XOA virtual (Console) screen regardless if I have the VM's VGA option turned on or not. The evdi driver is running as is the DisplayLink service. Looking at Xorg.0.log, I see EDID returns for the two HDMI monitors connected to the Wavlink card along with that from the virtual screen - but no screens other than the virtual one show in Display. Interesting bit: The GT730 card behaves EXACTLY the same way. Works great under Win11, driver initializes correctly in Mint but no display other than virtual. Going to post something on the DisplayLink support forum but find it odd that two different cards behave the same way in two different OSes.
    • itservicesI

      XO Backup Error: VDI_IN_USE(OpaqueRef:.., destroy)

      Watching Ignoring Scheduled Pinned Locked Moved Backup
      23
      2
      0 Votes
      23 Posts
      2k Views
      simonpS
      @itservices Hello, I'm taking this issue from Pierre. Did you perform a full restart of the XCP-ng host since the issue occured ? Or just restarted the toolstask ?
    • A

      Backup fails with "Body Timeout Error", "all targets have failed, step: writer.run()"

      Watching Ignoring Scheduled Pinned Locked Moved Backup
      27
      0 Votes
      27 Posts
      3k Views
      poddingueP
      The 2026-05-28 build still being good narrows the window a lot more than "sometime since November". What I keep coming back to is the shape of the failure: 14 out of 15, then 5 out of 6, so it is always exactly one that falls over and never the whole run. I don't know whether that points at a per-VM timeout or at something the last task in a run does differently, and someone on the XO team will read that better than me. @pierrebrunet still needs /var/log/xensource.log from the pool master covering one failed run's window, so even a slice from a job where only one VM failed should be enough.