Before taking action to fix this error, it is useful to know which VM was the owner of this VDI. Run the command:
xe vbd-list vdi-uuid=<VDI UUID> params=vm-name-label
This command returns the name of the VM that the VDI was attached to. You can use this information to check the status of the VM.
You can use one of the following methods to get rid of the error:
The shortest means to resolve this is to reboot the XenServer which owns the VDI
2. Remove the Virtual Block Disk (VBD)
Another way is to find the link between your virtual disk and DOM0 (the control domain) from your stand-alone XenServer (or primary server if you have a pool).
Use list_domains to get the UUID of DOM0 (the control domain):
[root@rightserver boot]# list_domains
id | uuid | state
0 | 09dffafe-5bec-430d-bc80-6ddb2313beff | R
1 | 94c63c12-0851-708d-7f95-c011f2760649 | RH
21 | a8f76fee-0b45-b5ee-7d83-14f6b530141f | B H
The control domain UUID is 09dffafe-5bec-430d-bc80-6ddb2313beff
Now we have to find the VBD(s) that DOM0 (the control domain) owns:
xe vbd-list vm-uuid=<DOM0 UUID, such as 09dffafe-5bec-430d-bc80-6ddb2313beff id>
This will show information about any Virtual Block Device (VBD) that DOM0 (the control domain) may be hanging onto. What we are interested in is the UUID of the VBD(s).
Grab the VBD’s UUID and execute:
xe vbd-unplug uuid=<UUID of the VBD being held by DOM0>
xe vbd-destroy uuid=<UUID of the VBD being held by DOM0>
And there – rescan your storage repository and your VDI (virtual disk interface) should be free from this safety lock.