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

[Andy Grover <agrover@redhat.com>]

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.

What's been the sticking point?

Regards -- Andy