Re: [Xen-devel] xl block-attach vs block-detach

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.03.12 at 17:45, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Thu, 2012-03-01 at 16:33 +0000, Jan Beulich wrote:
>> So it seems that "xl block-attach" allows a variety of ways to specify the
>> devices ID (xvdN, dNpN, decimal or hex number) - why is it that the
>> inverse operation ("xl block-detach") can't deal with anything by a decimal
>> number?
> 
> Just an omission?

Maybe. How many else are there throughout the xl stack then? (I'm
asking because any time I do something more advanced than "xl dmesg"
or "xl debug-key ..." with xl, I'm running into endless problems.

>> Further, why is it that with no blktap module loaded I'm getting an
>> incomplete attach when using the (deprecated) file:/ format for
>> specifying the backing file? It reports that it would be using qdisk,
>> and blkfront also sees the device appearing, but all I'm seeing in the
>> kernel log is the single message from blkfront's probe function.
> 
> What do you mean by "incomplete"? What else would you expect to see?

Either a fully failed operation (including an error message indicating so
even without wading through the -vvv output), or a fully working one
(after all, the -vvv messages suggest that a usable backend was
selected).

> What do the xenstore entries for the device look like?

local = ""
 domain = ""
  0 = ""
   name = "Domain-0"
   device = ""
    vbd = ""
     51712 = ""
      backend = "/local/domain/0/backend/qdisk/0/51712"
      backend-id = "0"
      state = "1"
      virtual-device = "51712"
      device-type = "disk"
     51728 = ""
      backend = "/local/domain/0/backend/qdisk/0/51728"
      backend-id = "0"
      state = "3"
      virtual-device = "51728"
      device-type = "disk"
      ring-ref = "9"
      event-channel = "60"
      protocol = "x86_64-abi"
     51760 = ""
      backend = "/local/domain/0/backend/qdisk/0/51760"
      backend-id = "0"
      state = "3"
      virtual-device = "51760"
      device-type = "disk"
      ring-ref = "10"
      event-channel = "61"
      protocol = "x86_64-abi"
   backend = ""
    qdisk = ""
     0 = ""
      51712 = ""
       frontend = "/local/domain/0/device/vbd/51712"
       params = "aio:/srv/SuSE/SLES-11-SP1-MINI-ISO-x86_64-GMC3-CD.iso"
       frontend-id = "0"
       online = "1"
       removable = "0"
       bootable = "1"
       state = "1"
       dev = "xvda"
       type = "qdisk"
       mode = "r"
       device-type = "disk"
      51728 = ""
       frontend = "/local/domain/0/device/vbd/51728"
       params = "aio:/srv/SuSE/SLES-11-SP1-MINI-ISO-x86_64-GMC3-CD.iso"
       frontend-id = "0"
       online = "1"
       removable = "0"
       bootable = "1"
       state = "1"
       dev = "xvdb"
       type = "qdisk"
       mode = "r"
       device-type = "disk"
      51760 = ""
       frontend = "/local/domain/0/device/vbd/51760"
       params = "aio:/srv/SuSE/SLES-11-SP1-MINI-ISO-x86_64-GMC3-CD.iso"
       frontend-id = "0"
       online = "1"
       removable = "0"
       bootable = "1"
       state = "1"
       dev = "d3p0"
       type = "qdisk"
       mode = "r"
       device-type = "disk"

>> (With no blktap in pv-ops, I wonder how file backed disks work there.)
> 
> file backed disks without blktap use the qdisk backend supplied by qemu.

Which apparently doesn't work (for me).

>> When trying to detach such a broken device I'm getting
>> "unrecognized disk backend type: 0", and the remove fails.
> 
> What version of xen is this?

-unstable c/s 24691:3432abcf9380.

I should probably add that I'm running the tools from the build tree,
but with xend this never caused any problems after I had added the
necessary paths to various environment variables in a wrapper script.
I'd expect xl to be similarly tolerable of such an environment,
otherwise it's not a drop-in replacement.

> libxl__device_disk_from_xs_be tries to read the backend type from
> xenstore, the be "type" node. Is that present for you?

See above.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel