Error: "Virtual Disk is Owned By Control Domain" in XenServer

Error: "Virtual Disk is Owned By Control Domain" in XenServer

book

Article ID: CTX207574

calendar_today

Updated On:

Description

- 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.

Resolution

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.


Problem Cause

Why does this happen?

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.

Issue/Introduction

Virtual Hard Disks are attached (owned) by a XenServer host (control domain) and cannot be deleted. This prevents other administrative tasks, such as enabling multipath on the SR hosting the VHDs as well as prevents upgrades.