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

    VDI not showing in XO 5 from Source.

    Scheduled Pinned Locked Moved Unsolved Management
    32 Posts 14 Posters 2.0k Views 12 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.
    • W Offline
      wilsonqanda @Pilow
      last edited by wilsonqanda

      @Pilow Check the iso does it have a snapshot icon in the drive?

      Next it show up fine until u want to create a vm in the new vm pg it think they are snapshots and you cant select the ISOs. This is when the problem arise.

      Yep the dev here are super reaponsive. Have been a long term user and here and love their support 🙂 . I mostly just been playing with things and learn so much by tinkering 🙂

      P 1 Reply Last reply Reply Quote 0
      • P Offline
        Pilow @wilsonqanda
        last edited by

        @wilsonqanda it's an SMB iso SR on my end, I think this is why it is not impacted

        can't snapshot a file on Microsoft SMB share 😃

        W 1 Reply Last reply Reply Quote 0
        • W Offline
          wilsonqanda @Pilow
          last edited by wilsonqanda

          @Pilow my is SMB too but it saw the issue. I use windows to login and drag all iso into a new created folder in the iso folder and drag it back out delete the newly created folder and all my iso is back to normal. It was a quick thing.

          P 1 Reply Last reply Reply Quote 0
          • P Offline
            Pilow @wilsonqanda
            last edited by

            @wilsonqanda HAHA. problem resolved instantly for me on last SR I had the troubles
            6593f43e-d85b-4865-8797-e9f949e07b88-{B255D2FD-7E51-4E65-B85F-05A24582BBF0}.png

            playing with the "rescan all ISO SRs" made the guest tools iso reappear

            AND ALL MY OTHER VDIs ON THIS SR/HOST that were invisible

            donnnnn't ask me HOW... 😄

            01c9cf72-44fb-4e96-abd5-c39290d20784-{535A410A-4F18-4281-A1D9-23113829E6C4}.png

            but this trick didn't work on other local RAID5 SR that have the problem 😕

            1 Reply Last reply Reply Quote 0
            • GheppyG Offline
              Gheppy
              last edited by Gheppy

              I have the same problem with 2 servers.
              The solution for me was to:

              • migrate the VM between servers with different SR or to a 3rd one.
              • export-import, virtual machines that are not that important and may have downtime.
              P 1 Reply Last reply Reply Quote 0
              • P Offline
                Pilow @Gheppy
                last edited by

                @Gheppy if you can have downtime snapshot/revert works

                1 Reply Last reply Reply Quote 0
                • L Offline
                  limezest
                  last edited by

                  I'm seeing this same problem in my lab, and I've found a symptom that I'm calling "VDI super-parents"

                  There is a VDI metadata field called "snapshots:" if your VM has snapshots, this field will be populated with a list of the snapshot VDI UUIDs.
                  If your VM has no snapshots, this field will be empty.
                  If your VM is a super-parent, it will have a list of VDI UUIDs that are actually the primary disk for other, unrelated VMs. In this case, XO5 will hide those VDIs from the list of disks because they've been determined to be snapshots.

                  As far as I can tell, XO5 has two methods for figuring out which VDI are snapshots:

                  1. It looks at the "is-a-snapshot:" field
                  2. It builds a map of parents and children from the "snapshot-of:" and "snapshots:" metadata fields (as @pilow found)

                  XO6 seems to only look at the "is-a-snapshot:" metadata field.

                  Now here's the question: why is this happening? I only started seeing this behavior after installing XO6 preview.
                  Maybe it was due to an incomplete backup operation?
                  I have a bunch of VMs which are clones of a template.
                  I use iSCSI SRs.

                  Doing a xe vdi-copy to a new SR collapses the snapshot chain and makes new VDI metadata, and then I did a vbd unplug and destroy, then connected the copied VDI to a new VBD. This fixed the problem for the first test VM that I messed with.

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

                    @anthoineb have we found a possible explanation?

                    W 1 Reply Last reply Reply Quote 0
                    • W Offline
                      wilsonqanda @olivierlambert
                      last edited by wilsonqanda

                      Hello All,

                      This issue seem to completely go away on a older branch/tag if i build it from below for XO:
                      xo-lite-v0.17.0

                      So the issue I would think is coming from the newer version of XO. Not sure best way to test this. So I am going back to an older commit.

                      If anyone has any suggestion I can try helping as its an annoying issue.

                      1 Reply Last reply Reply Quote 0
                      • andrewperryA Offline
                        andrewperry
                        last edited by andrewperry

                        We have been quietly suffering without the time to try and resolve it for the past couple of months.

                        I have now spent the day trying to resolve it in our environment, as we have one SR having this problem with some hundreds! of vdi.

                        I am having the same problem whether running the docker container version of XO CE or the local install on a VM we've been using for ages.

                        It seems that the api call from the VDIs tab in v6 (Disks in v5) may be triggering a call to the wrong url, without the /rest/v0 prefix:

                        sudo journalctl -u xo-server -n 300 --no-pager

                        2026-02-26T06:01:57.169Z xo:rest-api:error-handler INFO [GET] /vms/[[UUID]]/vdis (404)

                        I had the same experience as some others for a while, a couple of months ago, where it would not show up in the v5 UI but was showing in v6, but very quickly after that it stopped working in either.

                        I know that these are VDIs with a snapshot in the chain, for example a parent VDI that may have two snapshots from it.

                        I had thought the issue may have been had something to do with https://github.com/vatesfr/xen-orchestra/pull/9381 as it was around this time that I saw the problem in v5 before it also trickled through to v6 - but now I see that this topic was started just before Christmas so there must have been something else too.

                        If I run curl with the /rest/v0 prefix to the url I don't get the 404.

                        I hope this helps to track it down!

                        MathieuRA opened this pull request in vatesfr/xen-orchestra

                        closed fix(rest-api): fix getVmVdis and enhance the type #9381

                        florentF 1 Reply Last reply Reply Quote 0
                        • florentF Online
                          florent Vates 🪐 XO Team @andrewperry
                          last edited by

                          @andrewperry hi this is an identified issue on xapi / storage side
                          this commit is making it visible .

                          Pinging @anthoineb here for more info

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