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

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

The Friday 29 Aug 2014 à 11:38:14 (-0700), Andy Grover wrote :
> 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

QMP is just a way to control QEMU via a socket: it is not particularly block related.

On the other hand bringing the whole block layers into a tcmu-runner handler
would mean that there would be _one_ QMP socket opened
(by mean of wonderfull QEMU modules static variables :) to control multiple block devices
exported.

So I think the configuration passed must be done before an individual open occurs:
being global to the .so implementing the tcmu-runner handler.

But I don't see how to do it with the current API.

Best regards

Benoît

> 
> >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
>