XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. AlexD2006
    3. Topics
    A Offline
    • Profile
    • Following 0
    • Followers 0
    • Topics 4
    • Posts 24
    • Groups 0

    Topics

    • A

      XenOrchestra not showing VM Disks on Pool (on single Server working) - XCP-ng Center is showing them

      Watching Ignoring Scheduled Pinned Locked Moved Xen Orchestra
      19
      2
      0 Votes
      19 Posts
      2k Views
      poddingueP
      Here's the short version: this looks like the known "VDIs show up as snapshots" bug, and you haven't done anything wrong. What happens is a metadata flag on the VDI, is-a-snapshot, gets flipped to true after some of the recent 8.3 host updates, so XO (both 5 and 6) thinks those disks are snapshots and hides them from the per-VM Disks tab, even though the VDIs are fine and xe / XCP-ng Center still show them. A few older threads track the same thing, the main one is https://xcp-ng.org/forum/topic/11715/vdi-not-showing-in-xo-5-from-source . From what's said there, the fix is expected in two parts: stopping it from happening again, and a way to repair the flag on VDIs that are already affected. I don't have a timeline and could be off on the details, so please don't take that as official. In the meantime people have made the disks reappear by migrating the affected VDI to another SR, or snapshot then revert then delete the snapshot, but it's a visual fix and can come back. The VDI_IN_USE you're now hitting on start does sound worth its own detailed report, so yes please file it with the xapi/sm versions and that malformed is-a-snapshot field, and it'd be good to loop in @Team-Storage. Sorry you're stuck on this.
    • A

      Continuous Replication isnt deleting old Replikas anymore since Update

      Watching Ignoring Scheduled Pinned Locked Moved Solved Backup
      9
      1 Votes
      9 Posts
      1k Views
      olivierlambertO
      okay weird. Let's see if there's other reports then
    • A

      Delta Backups not working anymore on a single host

      Watching Ignoring Scheduled Pinned Locked Moved Backup
      11
      0 Votes
      11 Posts
      2k Views
      F
      Hi, sorry for the long break. i'll continue here for my colleague AlexD2006. We have now also tried with the current version (deeb3) of Xen-Orchestra, the problem remains the same. But we have now noticed other error messages (also with the old version) that appear during a delta backup ("base VDI is not a vhd; cannot compute differences"): May 23 16:40:35 xcp-mono02 xapi: [error||7644621 HTTPS 10.32.1.159->:::80|[XO] Exporting content of VDI test-vm.test 1 R:2e892fda7776|vhd_tool_wrapper] base VDI is not a vhd; cannot compute differences May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] [XO] Exporting content of VDI test-vm.test 1 R:2e892fda7776 failed with exception (Failure "base VDI is not a vhd; cannot compute differences") May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] Raised (Failure "base VDI is not a vhd; cannot compute differences") May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 1/14 xapi Raised at file stdlib.ml, line 29 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 2/14 xapi Called from file ocaml/xapi/vhd_tool_wrapper.ml, line 206 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 3/14 xapi Called from file ocaml/xapi/export_raw_vdi.ml, line 50 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 4/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 5/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 35 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 6/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 7/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 35 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 8/14 xapi Called from file ocaml/xapi/export_raw_vdi.ml, line 90 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 9/14 xapi Called from file ocaml/xapi/export_raw_vdi.ml, line 116 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 10/14 xapi Called from file ocaml/xapi/server_helpers.ml, line 101 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 11/14 xapi Called from file ocaml/xapi/server_helpers.ml, line 122 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 12/14 xapi Called from file lib/xapi-stdext-pervasives/pervasiveext.ml, line 24 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 13/14 xapi Called from file string.ml, line 115 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] 14/14 xapi Called from file src/sexp.ml, line 113 May 23 16:40:37 xcp-mono02 xapi: [error||7644621 :::80||backtrace] Can anyone say anything about the cause of the problem or any ideas for further analysis?
    • A

      Backup-NG Error "invalid header checksum" after VM-Disk-Resize and reaching retention Limit.

      Watching Ignoring Scheduled Pinned Locked Moved Xen Orchestra
      8
      0 Votes
      8 Posts
      2k Views
      julien-fJ
      @olivierlambert said in Backup-NG Error "invalid header checksum" after VM-Disk-Resize and reaching retention Limit.: So the issue appeared just when the oldest extended delta had to be merged in the full I suppose. This is exact, but we need to have a proper process to reproduce it. This might be related to: increasing the size of the disk above a certain threshold increasing the content of the disk above a certain threshold