Originally, I exported one block device to each VM, then partitioned it. No fuss, everything self-contained in the one file/logical volume.
Then I had a few incidences where the VM crashed, and I needed to get a file or two off the virtual drive. It was a complicated process, as detailed in one of my earlier posts. So I get fed up and gave each VM 4 virtual disks – boot, root, home & swap, so I could shuffle the respective disks around when necessary.
Now I’ve discovered an easier way to use a single logical volume with each VM:
xl block-attach 0 phy:/dev/domU/fedora13pv.1 xvda w
Simply put, xl block-attach (and xm block-attach) creates a new virtual block device in the specified domain. There’s no man page for xl (yet), but it’s supposed to be a drop-in replacement for xm block-attach, which does have a manual entry. That command up there attached a domU’s logical volume to my dom0, where pvs
shows the new physical volume appearing as /dev/xvda2, and the domU’s volume group appearing, ready to be mounted.
Using xl block-attach
Usage: xl [-v] block-attach <Domain> <BackDev> <FrontDev> [<Mode>] [BackDomain]
Points to note about using block-attach:
domain
should be the domain ID, get it from xl listbackdev
needs to include ‘phy:’ or ‘file:’ if you use LVM/raw partitions or disk images respectivelyfrontdev
doesn’t appear to need /dev, like the config filemode
should be ‘w’ or ‘r’
Essentially, block-attach uses the VM config file syntax – does disk = [ "phy:/dev/domU/fedora13pv.1,xvda,w" ]
look familiar?
Using xl block-detach
Now, using block-attach
to recover data (or running fsck on a disk) is simple. Detaching the drive from your VM? Yeah… easier said than done, unfortunately. Trying xl block-detach
to get the syntax gives you this:
Usage: xl [-v] block-detach <Domain> <DevId>
So… try xl block-detach 0 xvda
, since we attached the block device to the domain’s xvda
.
Error: Device xvda not connected
. Oops.
Turns out, DevId doesn’t mean the front end or back end device names. What it needs is something from xl block-list
. Running xl block-list 0
(since I want the block devices attached to dom0) gave me this output:
Vdev BE handle state evt-ch ring-ref BE-path
51712 0 0 1 -1 -1 /local/domain/0/backend/vbd/0/51712
Look at the Vdev number. That’s what you want.
Substitute it into the command to get xl block-detach 0 51712
, run it, and your block device is detached.
As a point of note, it doesn’t print any message on success though.
And I’m prefix this last bit with saying that this is unconfirmed in that I haven’t investigated why, but xm block-detach
doesn’t like the Vdev number when you try to use it. I don’t know if it’s just something up with xm, or my install.
I’d bet my install.
#1 by Frank Vasquez Diaz on December 14, 2016 - 9:15 am
When I run the command on my server throws me this error:
xl block-attach proxy phy:/dev/vgcmbo/compartidas /dev/vgcmbo/xvdc1 w
libxl: error: libxl.c:2042:libxl__device_from_disk: Invalid or unsupported virtual disk identifier /dev/vgcmbo/xvdc1
libxl: error: libxl.c:2128:device_disk_add: Invalid or unsupported virtual disk identifier /dev/vgcmbo/xvdc1
libxl: error: libxl.c:1743:device_addrm_aocomplete: unable to (null) device
libxl_device_disk_add failed.
#2 by Kyle Lexmond on December 27, 2016 - 1:34 am
I haven’t touched block-attach in a while, first thought the /dev/vgcmbo/xvdc1 part is completely wrong, you should just be passing it xvdc.
#3 by seb on October 2, 2018 - 2:41 pm
If you have multiple block devices, how can you tell which is which?
#4 by Kyle Lexmond on November 2, 2018 - 7:47 am
Look in /dev? You’re deciding to mount them…