On 08/30/2014 09:02 AM, Richard W.M. Jones wrote:
On Sat, Aug 30, 2014 at 05:53:43PM +0200, Benoît Canet wrote:
If the cloud provider want to be able to boot QCOW2 or QED images on
bare metal machines he will need to export QCOW2 or QED images on
the network.
So far only qemu-nbd allows to do this and it is neither well
performing nor really convenient to boot on a bare metal machine.
So I think what you want is a `qemu-iscsi'? ie. the same as qemu-nbd,
but with an iSCSI frontend (to replace the NBD server).
You want qemu to be able to issue SCSI commands over iSCSI? I thought
qemu used libiscsi for this, to be the initiator. What Benoit and I have
been discussing is the other side, enabling qemu to configure LIO to
handle requests from other initiators (either VMs or iron) over iSCSI or
FCoE, but backed by qcow2 disk images. The problem being LIO doesn't
speak qcow2 yet.
I guess so. Are you planning to integrate bits of LIO into qemu, or
bits of qemu into LIO?
My current thinking is 1) enable qemu to configure the LIO kernel target
(it's all straightforward via configfs, but add a nice library to qemu
to hide the details) and 2) enable LIO to use qcow2 and other formats
besides raw images to back exported LUNs. This is where the LIO
userspace passthrough and tcmu-runner come in, because we want to do
this in userspace, not as kernel code, so we have to pass SCSI commands
up to a userspace helper daemon.
The latter has been tried various times, without much success. See
the many examples of people trying to make the qemu block driver code
into a separate library, and failing.
What's been the sticking point?
Regards -- Andy
