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
