How I learnt to love xl block-attach

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 list
  • backdev needs to include ‘phy:’ or ‘file:’ if you use LVM/raw partitions or disk images respectively
  • frontdev doesn’t appear to need /dev, like the config file
  • mode 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. #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. #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. #3 by seb on October 2, 2018 - 2:41 pm

    If you have multiple block devices, how can you tell which is which?

  4. #4 by Kyle Lexmond on November 2, 2018 - 7:47 am

    Look in /dev? You’re deciding to mount them…

(will not be published)