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
>
