[Qemu-devel] tcmu-runner and QEMU

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

Hi list,

Listening at Palo's suggestion I started discussing privately with
Andy about integrating LIO and the QEMU block layer together using
tcmu-runner: https://github.com/agrover/tcmu-runner.

The rationale is that it would be very handy to be able to export one of the numerous QEMU
image formats into ISCSI or FCOE via the LIO kernel target.

For example a cloud provider would be able to provision either a bare metal instance
(some hardware knows how to boot ISCSI and FCOE) or a virtualized instance while
using the same QCOW2 backing chain.

The consequence is that the end user would be able to switch back and forth between
small virtualized hardware or monster bare metal hardware while keeping the same data
in the same volumes.

Quoting Andy:
"My initial thought is that we don't want to make tcmu-runner
QEMU-specific, what we really want is tcmu-runner to be able to use
QEMU's multitude of BlockDrivers. Ideally the BlockDrivers could be
compiled as loadable modules that could then be loaded by QEMU or
tcmu-runner. Or if that's not possible then we might need to build a
tcmu-runner handler as part of QEMU, similar to how qemu-nbd is built?"

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.

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.

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.

Some other configuration would be needed to configurate properly the QEMU block layer:
for example which cache mode should the handler use ?

So passing configuration to the QEMU block plugin would be the first critical point.

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.

Best regards

Benoît