XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    huge number of api call "sr.getAllUnhealthyVdiChainsLength" in tasks

    Scheduled Pinned Locked Moved Xen Orchestra
    28 Posts 8 Posters 4.2k Views 8 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F Offline
      flakpyro @olivierlambert
      last edited by

      @olivierlambert

      After i seen the CBT stuff was reverted on github, i updated to the latest commit on my home server, (253aa) i can report my backups are now working as they should and coalesce runs without issues leaving a clean health check dashboard again. :). Glad to see this has been held back on XOA as well as i was planning to stay on 5.95.1 otherwise! Looking forward to CBT eventually all the same!

      M 1 Reply Last reply Reply Quote 0
      • M Offline
        manilx @flakpyro
        last edited by

        @flakpyro Just updated, run my delta backups and all is fine 🎂

        M 1 Reply Last reply Reply Quote 0
        • M Offline
          manilx @manilx
          last edited by

          @manilx Was fine for a short while only: https://xcp-ng.org/forum/topic/9275/starting-getting-again-retry-the-vm-backup-due-to-an-error-error-vdi-must-be-free-or-attached-to-exactly-one-vm

          1 Reply Last reply Reply Quote 0
          • rvreugdeR Offline
            rvreugde
            last edited by rvreugde

            Same problem here 300+ sessions and counting
            07564582-c58a-490e-8921-5f5de0e98fa6-image.png
            XAPI restart did not solve the issue...

            1 Reply Last reply Reply Quote 1
            • ryan.gravelR Offline
              ryan.gravel
              last edited by

              Doesn't seem to be respecting [NOBAK] anymore for storage repos. Tried '[NOSNAP][NOBAK] StorageName' and it still grabs it.

              1 Reply Last reply Reply Quote 0
              • olivierlambertO Offline
                olivierlambert Vates 🪐 Co-Founder CEO
                last edited by

                On the VDI name, right?

                ryan.gravelR 1 Reply Last reply Reply Quote 0
                • ryan.gravelR Offline
                  ryan.gravel @olivierlambert
                  last edited by ryan.gravel

                  @olivierlambert I believe so. It is the Disks tab of a VM. [NOBAK] was working but now the NAS is complaining about storage space. This VM has a disk on the NAS so it is backing it up twice. Added [NOSNAP] just as a test with the same result.
                  24516021-d80c-4418-a539-a89b7ca17797-image.png

                  It is running a full backup if that makes any difference.

                  julien-fJ 1 Reply Last reply Reply Quote 0
                  • olivierlambertO Offline
                    olivierlambert Vates 🪐 Co-Founder CEO
                    last edited by

                    Ping @julien-f

                    1 Reply Last reply Reply Quote 0
                    • julien-fJ Offline
                      julien-f Vates 🪐 Co-Founder XO Team @ryan.gravel
                      last edited by

                      @ryan-gravel I cannot reproduce, both Full Backup and Incremental Backup correctly ignore VDIs with [NOBAK] in their name label.

                      A 1 Reply Last reply Reply Quote 0
                      • A Offline
                        Andrew Top contributor @julien-f
                        last edited by

                        @julien-f It's happening to me too... my [NOBAK] disk is being backed up now (commit 0e4a3) using the normal Backup (running a full).

                        ryan.gravelR A 2 Replies Last reply Reply Quote 1
                        • ryan.gravelR Offline
                          ryan.gravel @Andrew
                          last edited by

                          @Andrew @julien-f Ran a full backup with commit 96b76 and it is working properly now. Started thinking that I was the only one 🙂 Thanks a lot for everyone's help!

                          1 Reply Last reply Reply Quote 0
                          • A Offline
                            Andrew Top contributor @Andrew
                            last edited by

                            With today's update (feat: release 5.96.0, master 96b7673) things are working well again. I have not seen any Orphan VDI/snapshots or stuck Control Domain VDIs (but it may take time to test). Thanks to the Vates team!

                            julien-fJ 1 Reply Last reply Reply Quote 1
                            • julien-fJ Offline
                              julien-f Vates 🪐 Co-Founder XO Team @Andrew
                              last edited by

                              Hello, can you please try the buffered-task-events branch and let me know if that solves the issue?

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post