Database Reference
In-Depth Information
4.
Detach the block device from the ODA Base. This is a tricky process. If you want to
walk the easy path, simply restart the ODA Base and the temporary block device will be
removed because it wasn't saved in the configuration for the ODA Base. But if the system is
used by other databases, or for some reason bouncing the ODA Base is not an option, then
execute
xenstore-ls
to find out the
domain id
and the
vdb id
(the virtual block device id)
for the attached block device. The command will spool a lot of output, but if you search for
the filename of the attached file (
u02.img
), you'll find a section similar to that in the
following example:
[root@ovs-host1 oakDom1]#
xenstore-ls
...
51760 = ""
domain = "oakDom1"
frontend = "/local/domain/2/device/vbd/51760"
uuid = "def6fa49-aeb6-eab8-1ed6-2c6007489c9c"
bootable = "0"
dev = "/dev/xvdd"
state = "4"
params = "/OVS/Repositories/odabaseRepo/VirtualMachines/oakDom1/u02.img"
mode = "w"
online = "1"
frontend-id = "2"
type = "file"
node = "/dev/loop4"
physical-device = "7:4"
feature-flush-cache = "1"
feature-discard = "0"
feature-barrier = "1"
sectors = "204800"
info = "0"
sector-size = "512"
hotplug-status = "connected"
...
5.
You're interested in finding the correct “front-end” path for the attached device. In this
case, the path is
“/local/domain/2/device/vbd/51760
”. The
domain id
in the path is “2”
and the
vdb id
is “51760”. This information is sufficient for detaching the device from the
ODA Base using
xm block-detach
by using the following commands:
[root@ovs-host1 ~]#
xm block-detach 2 51760
[root@ovs-host1 ~]#
xenstore-ls | grep "u02.img"
# no rows retrieved#
The
u02.img
file is not needed anymore and can be removed.
6.
[root@ovs-host1 ~]#
rm -vf /OVS/Repositories/odabaseRepo/VirtualMachines/oakDom1/u02.img
removed `/OVS/Repositories/odabaseRepo/VirtualMachines/oakDom1/u02.img'
The ODA Base is now restored to its original state.
