VDI not showing in XO 5 from Source.

[johnhabs]

I just noticed I am seeing the same thing on some of my virtual machines. When I view the Disks tab for a vm in the Xen Orchestra 5 ui it shows no items found but XO6 will lists the disks associated with this vm. It only appears to be affecting 2 out of the 4 hosts that I have connected to the xoa instance but is not affecting all the virtual machines of those hosts. It seems to be impacting disks on both local and nfs storage pools.

There are no errors reported and the vm's are running fine and I can take snapshots and execute backup tasks, stop and start the vms without any problems. It just seems that the XOA v5 vm disks display is no longer able to find the disks for certain vms.

I am running version 6.0.2 XOA build: 20251101 from the latest channel.

[Andrew]

@Danp I have also seen this problem with XO, but currently do not have an example to test. This was an issue on both local SR and shared SR on NFS.

[olivierlambert]

Let me ping @team-xo-frontend

[MathieuRA]

@wmazren Hi.
Weird,i am unable to reproduce the issue..

Can you show us the output from the following command?
xe vbd-param-list uuid=c6f4c7fa-4f6f-7999-d13c-3a29d887d828

[florent]

@wmazren said in VDI not showing in XO 5 from Source.:

       is-a-snapshot ( RO): false
         snapshot-of ( RO): d31f2db0-be21-4794-b858-1bea357869c8

this disk is now recognized as a snapshot by xo
is it a disk from a restored VM ?

[abudef]

Hi,
I’m afraid I’ve encountered the same problem:

• Xen Orchestra, commit 0b52a
  

• v6
  

[Pilow]

I am also impacted on some SRs, latest XOA 6.0.3

In the VM DISKS tab, no disk

VM is running OK. can snapshot, can backup.

on the impacted SR (local RAID5 for this one) I noted that there is no more green progress bar as if SR is empty, but showing 47 VDIs and occupied space OK :

DISKS tab of the SR is showing the VDIs on the running VMs :

as @danp asked, check of params on one impacted VDI & VBD :

# xe vdi-param-list uuid=a81ecd87-3788-4528-819d-7d7c03aa6c61
uuid ( RO)                    : a81ecd87-3788-4528-819d-7d7c03aa6c61
              name-label ( RW): xxx-xxx-xxxxxx_sda
        name-description ( RW):
           is-a-snapshot ( RO): false
             snapshot-of ( RO): f9cbd30f-a261-4b95-97db-b6846147634a
               snapshots ( RO): cb65b96a-bed9-4e9a-82d3-e73b5aed546d
           snapshot-time ( RO): 20250912T17:38:57Z
      allowed-operations (SRO): snapshot; clone
      current-operations (SRO):
                 sr-uuid ( RO): b1b80611-7223-c829-8953-6aa2bf5865b3
           sr-name-label ( RO): xxx-xx-xxxxxxx RAID5 Local
               vbd-uuids (SRO): 51bb1797-c6c7-50f0-13a9-dfaad4c99d90
         crashdump-uuids (SRO):
            virtual-size ( RO): 68719476736
    physical-utilisation ( RO): 30686765056
                location ( RO): a81ecd87-3788-4528-819d-7d7c03aa6c61
                    type ( RO): User
                sharable ( RO): false
               read-only ( RO): false
            storage-lock ( RO): false
                 managed ( RO): true
     parent ( RO) [DEPRECATED]: <not in database>
                 missing ( RO): false
            is-tools-iso ( RO): false
            other-config (MRW):
           xenstore-data (MRO):
               sm-config (MRO): vhd-parent: daeee201-3891-443e-8bdb-b00ed1051279; host_OpaqueRef:3e7283ba-5a42-1881-958a-9f96b71fb98f: RW; read-caching-enabled-on-f2868da5-4509-43d7-9ef9-2bb3857e1ba5: true
                 on-boot ( RW): persist
           allow-caching ( RW): false
         metadata-latest ( RO): false
        metadata-of-pool ( RO): <not in database>
                    tags (SRW):
             cbt-enabled ( RO): true

# xe vbd-param-list uuid=51bb1797-c6c7-50f0-13a9-dfaad4c99d90
uuid ( RO)                        : 51bb1797-c6c7-50f0-13a9-dfaad4c99d90
                     vm-uuid ( RO): 108ad69b-1fa5-d80b-fb16-a62509ad642a
               vm-name-label ( RO): xxx-xxx-xxxxxx
                    vdi-uuid ( RO): a81ecd87-3788-4528-819d-7d7c03aa6c61
              vdi-name-label ( RO): xxx-xxx-xxxxxx_sda
          allowed-operations (SRO): attach; unpause; pause
          current-operations (SRO):
                       empty ( RO): false
                      device ( RO): xvda
                  userdevice ( RW): 0
                    bootable ( RW): false
                        mode ( RW): RW
                        type ( RW): Disk
                 unpluggable ( RW): false
          currently-attached ( RO): true
                  attachable ( RO): true
                storage-lock ( RO): false
                 status-code ( RO): 0
               status-detail ( RO):
          qos_algorithm_type ( RW):
        qos_algorithm_params (MRW):
    qos_supported_algorithms (SRO):
                other-config (MRW): owner:
                 io_read_kbs ( RO): 0.000
                io_write_kbs ( RO): 93.752

VDI seen as a snapshot...
in XO6, VDI appears ok.
we have an internal webapp that access by API and disk appears OK, like in XO6.

seems to be rooted on the SR, not the VMs, as the entire SR is impacted... ? not all SRs in this XOA instance are impacted (have other RAID5 local SR and iSCSI SRs)
all VMs hosted on this SR have invisible disks in XO5

have an XO CE attached to same servers, and same behavior, invisible disks

edit :
on GENERAL tab of an impacted VM :

we can see a 0Bytes VDI, but activity

[Pilow]

tried to deploy a NEW vm for testing purpose on an impacted SR :

and it appears ! it's the only VDI visible, there are OTHER vms on this same SR that have invisible disks

all as if nothing

I guess we could migrate the impacted VMs out of this SR and back, and it would correct the issue !

does that help ?!

[olivierlambert]

@anthoineb or someone from the @team-storage, you might want to take a look (IDK if it's a known problem internally)

[anthoineb]

@olivierlambert Yes, we saw this before, we are investigating.

[olivierlambert]

Thanks!

[wilsonqanda]

Hello All,

Found some roundabout solutions you may want to try:
https://xcp-ng.org/forum/post/101370

[Pilow]

@wilsonqanda tried your workaround on a halted VM, and it worked !
If i snapshot -> disk still invisible
delete snapshot - > disk still invisible

but

if i snapshot --> disk still invisible
revert snapshot (with take snapshot option) --> disk APPEAR again
delete the two snapshots -> disks still there

edit : even without the take snapshot before revert, it is working, tried on another VM

[wilsonqanda]

@Pilow Lol glad I was able to help. Its only if you have a few VMs having hundreds will be a nightmare... giod luck to those that has that issue. In the meantime I will use the method I mention for now.