SR_BACKEND_FAILURE_46 The VDI is not available not detached cleanly

john.manning

I ran across this issue today and thought I would share as I didn't find any immediate results when looking for a solution. I had a VM that was in an unhealthy state where RDP would not connect and the console tab in XOA was blank.

I was in the process of applying updates to the pool and also could not migrate this VM to a different host. I proceeded to install the patches and this VM went offline during the updates after the toolstack restarted.

I tried to boot the VM on the host I had wanted to move it to and got the "SR_BACKEND_FAILURE_46 The VDI is not available not detached cleanly" error. I then tried to just boot the VM with the same result.

The fix was to boot the VM on the original host it had been running on before the shutdown. Hope this helps.

DustinB

@john.manning Just confirming some details for the community.

You're using XCP-ng 8.3 with the latest round of updates?
You're using the latest version of XOA
The guest was running what operating system?

john.manning

@DustinB Sure thing.

Yes, XCCP-ng 8.3 while applying the latest round on 3/12/25, kept up to date prior.
XOA Premium, version 5.103.1.
Guest was Windows Server 2019 Standard with XenServer VM Tools version 9.3.3.

icecoke

@john.manning

well known problem.
solution:

shutdown vm (must be in halted state)
find your VDI UUIDs

xe vm-disk-list vm=VMNAMEORUUID is-a-snapshot=false | grep -a1 'VDI\:' | grep 'uuid' | awk '{print $(NF)}'

write down for all VDIs (in addition to you VMUUID):

VDIUUID
VDILABEL = xe vdi-param-get param-name=name-label uuid=VDIUUID
VDIDESCR = xe vdi-param-get param-name=name-description uuid=VDIUUID
SRUUID = xe vdi-param-get param-name=sr-uuid uuid=VDIUUID (if you have different SRs)
OLDVBDUUID = xe vdi-param-get uuid=VDIUUID param-name=vbd-uuids
VDIUSERDEVICE = xe vbd-param-get param-name=userdevice uuid=OLDVBDUUID

i have a script doing some checks at this point like getting current-operations etc. to prevent work on running/connected VMs/VDIs. If you are sure, the VM is offline, everything is ok. Sometimes thinks like a xe-toolstack-restart is needed, if the host is a long time runner

now 'forget' all VDIs: (call for each VDI)

xe vdi-forget uuid=VDIUUID

this could take some time AFTER the call above. Check that this responds with a 0, after you did the above call for all of your VM devices:

xe vbd-list vm-uuid=VMUUID | grep 'empty ( RO): false' | wc -l`

now rescan all SRs where the VM had a VDI (maybe you have more than one SR):

xe sr-scan uuid=SRUUID

now readd all devices again to the same position (VDIUSERDEVICE):

xe vbd-create vm-uuid=VMUUID device=VDIUSERDEVICE vdi-uuid=VDIUUID
xe vdi-param-set name-label='VDILABEL' name-description='VDIDESCR' uuid=VDIUUID

If you got no errors (hopefully), start you VM:

xe vm-start uuid=VMUUID

This can easily scripted in shell or perl. We have 'The VDI is not available' errors and alike from time to time, so on all pool masters such a script exists to be run if needed. Especially if you have several drives and several VDI names/descriptions it's nice to not do it step by step

john.manning

@icecoke Thank you.

I do have an added complication. This disk resides on an XOSTOR SR. Also, when gathering the VDIUSERDEVICE I get the following error:

"The uuid you supplied was invalid."

Is the VBDUUID parameter a typo of VDIUUID? Otherwise I don't see a command to obtain the VBDUUID for this step:
"VDIUSERDEVICE = xe vbd-param-get param-name=userdevice uuid=VBDUUID"

icecoke

@john.manning

not familiar with xostor, but that should make no difference.

The UUID for the vbd-param-get command must be a vbd-uuid, as the vbd 'has' the logical position in the VM, not the VDI. Look at this example:

[root@xenserver72-b1 ~]# xe vm-disk-list vm=xxxxxx is-a-snapshot=false | grep -a1 'VDI\:' | grep 'uuid' | awk '{print $(NF)}'
847c79d8-1dac-4b7c-bc5f-9fd2714dfa66
40d02eb9-e099-4ebf-8ad7-96f689b33990
[root@xenserver72-b1 ~]# xe vdi-param-get uuid=40d02eb9-e099-4ebf-8ad7-96f689b33990 param-name=vbd-uuids
98bb67cb-2b66-b10d-6016-edd8e24896cb
[root@xenserver72-b1 ~]# xe vbd-param-get param-name=userdevice uuid=98bb67cb-2b66-b10d-6016-edd8e24896cb
0
[root@xenserver72-b1 ~]# xe vdi-param-get uuid=847c79d8-1dac-4b7c-bc5f-9fd2714dfa66 param-name=vbd-uuids
ffab52fe-ba57-f5b3-2614-5ce01171ea79
[root@xenserver72-b1 ~]# xe vbd-param-get param-name=userdevice uuid=ffab52fe-ba57-f5b3-2614-5ce01171ea79
4

first step is to get all VDIs of the named VM, than for the vdi-param-get command, I use these VDI-UUIDs to get the VBD-UUIDs of each.
Then - from the vbd-param-get with the VBD-UUID - you can get the logical userdevice position of the VBD->VDI connection.

john.manning

@icecoke Got it. I worked through the steps and found where I transposed one of the variables incorrectly. I was able to complete all the steps and the VM is booting now as expected. Thanks again.

icecoke

@john.manning

Happy to hear that. I guess it was my fault - I edited the naming of the snipped pseudo vars:

OLDVBDUUID = xe vdi-param-get uuid=VDIUUID param-name=vbd-uuids
VDIUSERDEVICE = xe vbd-param-get param-name=userdevice uuid=OLDVBDUUID

maybe that way it's clearer for others that might find that helpful