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

[Andy Grover]

On 08/29/2014 11:51 AM, Benoît Canet wrote:
> 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.

This discussion leads me to think we need to step back and discuss our 
requirements. I am looking for flexible backstores for SCSI-based 
fabrics, with as little new code as possible. I think you are looking 
for a way to export QEMU block devices over iSCSI and other fabrics?

I don't think making a LIO userspace handler into basically a 
full-fledged secondary QEMU server instance is the way to go. What I 
think better serves your requirements is to enable QEMU to configure LIO.

In a previous email you wrote:
> 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.

Whether a volume is exported over iSCSI or FCoE or not shouldn't affect 
how it is managed. QMP commands should go to the single QEMU server, 
which can then optionally configure LIO to export the volume. That 
leaves us with the issue that we'd need to arbitrate access to the 
backing file if taking a streaming snapshot (qemu and tcmu-runner 
processes both accessing the img), but that should be straightforward, 
or at least work that can be done in a second phase of development.

Thoughts?

Regards -- Andy

p.s. offline Monday.