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

[Andy Grover <agrover@redhat.com>]

On 08/29/2014 10:22 AM, Benoît Canet wrote:
> The truth is that QEMU block drivers don't know how to do much on their own
> so we probably must bring the whole QEMU  block layer in a tcmu-runner handler plugin.

Woah! Really? ok...

> Another reason to do this is that the QEMU block layer brings features like taking
> snapshots or streaming snaphots that a cloud provider would want to keep while exporting
> QCOW2 as ISCSI or FCOE.
>
> Doing these operations is usually done by passing something like
> "--qmp tcp:localhost,4444,server,nowait" as a QEMU command line argument then
> connecting on this JSON processing socket then send orders to QEMU.

The LIO TCMU backend and tcmu-runner provide for a configstring that is 
associated with a given backstore. This is made available to the 
handler, and sounds like just what qmp needs.

> I made some patches to split this QMP machinery from the QEMU binary but still
> I don't know how a tcmu-runner plugin handler would be able to receive this command
> line configuration.

The flow would be:
1) admin configures a LIO backstore of type "user", size 10G, and gives 
it a configstring like "qmp/tcp:localhost,4444,server,nowait"
2) admin exports the backstore via whatever LIO-supported fabric(s) 
(e.g. iSCSI)
3) tcmu-runner is notified of the new user backstore from step 1, finds 
the handler associated with "qmp", calls 
handler->open("tcp:localhost,4444,server,nowait")
4) qmp handler parses string and does whatever it needs to do
5) handler receives SCSI commands as they arrive

> The second problem is that the QEMU block layer is big and filled with scary stuff like
> threads and coroutines but I think only trying to write the tcmu-runner handler will
> tell if it's doable.

Yeah, could be tricky but would be pretty cool if it works. Let me know 
how I can help, or with any questions.

Regards -- Andy