Re: [Qemu-devel] tcmu-runner and QEMU

["Benoît Canet" <benoit.canet@irqsave.net>]

The Sunday 31 Aug 2014 à 13:03:14 (-0700), Andy Grover wrote :
> On 08/30/2014 09:02 AM, Richard W.M. Jones wrote:
> >On Sat, Aug 30, 2014 at 05:53:43PM +0200, Benoît Canet wrote:
> >>If the cloud provider want to be able to boot QCOW2 or QED images on
> >>bare metal machines he will need to export QCOW2 or QED images on
> >>the network.
> >>
> >>So far only qemu-nbd allows to do this and it is neither well
> >>performing nor really convenient to boot on a bare metal machine.
> >
> >So I think what you want is a `qemu-iscsi'?  ie. the same as qemu-nbd,
> >but with an iSCSI frontend (to replace the NBD server).
> 
> You want qemu to be able to issue SCSI commands over iSCSI? I thought qemu
> used libiscsi for this, to be the initiator. What Benoit and I have been
> discussing is the other side, enabling qemu to configure LIO to handle
> requests from other initiators (either VMs or iron) over iSCSI or FCoE, but
> backed by qcow2 disk images. The problem being LIO doesn't speak qcow2 yet.
> 
> >I guess so.  Are you planning to integrate bits of LIO into qemu, or
> >bits of qemu into LIO?
> 
> My current thinking is 1) enable qemu to configure the LIO kernel target
> (it's all straightforward via configfs, but add a nice library to qemu to
> hide the details) and 2) enable LIO to use qcow2 and other formats besides
> raw images to back exported LUNs. This is where the LIO userspace
> passthrough and tcmu-runner come in, because we want to do this in
> userspace, not as kernel code, so we have to pass SCSI commands up to a
> userspace helper daemon.
> 
> >The latter has been tried various times, without much success.  See
> >the many examples of people trying to make the qemu block driver code
> >into a separate library, and failing.
> 

The problem with QEMU block drivers is that they are using either coroutines
or QEMU custom AIO callbacks so reusing them without the block layer is
not doable.

For the QEMU block layer as a whole it maintains some linked lists of block devices
states or similar stuff as static global variables.
(See https://github.com/qemu/qemu/blob/master/block.c#L96)

So having more than one instance of the block layer running is not doable.

I am not aware of anyone successfull in turning it into a proper .so.

Extracting into a binary acting as an nbd target was done with qemu-nbd though.

Best regards

Benoît

> What's been the sticking point?
> 
> Regards -- Andy
> 
>