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.
