10 print “Hello, World!”


Aside from the pollen, I hope everyone’s weekend is off to a grand start!  I have worked with a few clients recently – you know who you are! – regarding one of their VM disks becoming “owned by the Control Domain”.

You know: you tried to migrate a VM, move a disk, or take a snapshot and POW: you look on your SR to find that your VM’s disk is owned by “the control domain”.

1.  Why does this happen?

Basically it boils down to disk operations on/from a VM failing.  Operations such as move, copy, snapshot, export, etc.

2.  How do I get around it?

One answer is to reboot.

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 for your use.

And this is from my Virtual Desktop to you.