- Storage Repository shows a virtual disk attached to a "Control Domain"
- VDIs cannot be deleted with errors that the VDI is not managed by this host.
- Multipathing cannot be enable on the SR because the VDIs are not managed by this host.
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:
1. Reboot
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>
Finally, run:
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.
Basically it boils down to disk operations on/from a VM failing. Operations such as move, copy, snapshot, export, etc. The control domain (XenServer/dom0) protects the source VDI until virtual disk-based operations complete.