[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] tcmu-runner and QEMU
From: |
Benoît Canet |
Subject: |
[Qemu-devel] tcmu-runner and QEMU |
Date: |
Fri, 29 Aug 2014 19:22:18 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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