|
From: | Andy Grover |
Subject: | Re: [Qemu-devel] tcmu-runner and QEMU |
Date: | Sun, 31 Aug 2014 13:03:14 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |