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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-03-02 at 07:40 +0000, Jan Beulich wrote:
> >>> 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:
> >> 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.
> >> (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.
> 
> What is the rationale for using blkback over blktap for file backed
> disks anyway? If using blktap, why not directly do so?

"directly" how? blktap always requires a blkback to export it to the
guest. The old blktap1 incorporated a disk backend but this lead to
duplicated code, complex set up and teardown interlocking and
interesting interactions between the "backdev" (which exposed the blktap
device to dom0 for toolstack and qemu use) and the pv disk backend.
blktap2 was intended to fix those by layering blkback on blktap2, which
now just provides a block device in dom0 (blktap2 is almost independent
of Xen). 

(I originally misread the above and wrote the following, so it's not
actually relevant to your questions, but they are perhaps interest facts
so I've left them in:...

There is no blktap in upstream kernels and the kernel module is
considered non-upstreamable.

If blktap is available then libxl will use it in preference to qdisk.

There are some folks working on a purely userspace blktap ("blktap3" ==
blktap2 with a userspace disk backend bolted on). I hope this will be
ready in time for 4.2 but I'm not sure.

...)

> And if using blkback, why not (as in xend) via loop devices?

Support for block device script= in xl/libxl is on the 4.2 blocker list,
this feature would re-enable the loop+blkback case -- I think this would
be a better option than blktap* or qdisk once it becomes available.

Ian.


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