Re: [Qemu-devel] [PATCH 00/16] QEMU vhost-scsi support

[ronnie sahlberg]

On Mon, Apr 23, 2012 at 7:33 PM, Stefan Hajnoczi <address@hidden> wrote:
> On Sat, Apr 21, 2012 at 9:51 AM, Nicholas A. Bellinger
> <address@hidden> wrote:
>> On Fri, 2012-04-20 at 12:09 +0100, Stefan Hajnoczi wrote:
>>> On Fri, Apr 20, 2012 at 8:46 AM, Paolo Bonzini <address@hidden> wrote:
>>> > Il 20/04/2012 09:00, Nicholas A. Bellinger ha scritto:
>>
>> <SNIP>
>>
>>> > - no support for migration (there can be pending SCSI requests at
>>> > migration time, that need to be restarted on the destination)
>>>
>>> Yes and it hasn't been thought through by me at least ;-).  So
>>> migration is indeed a challenge that needs to be worked through.
>>>
>>> > - no support for non-raw images (fix: use NBD on a Unix socket? perhaps
>>> > add an NBD backend to lio)
>>>
>>> For me this is the biggest issue with kernel-level storage for virtual
>>> machines.  We have NBD today but it goes through the network stack
>>> using a limited protocol and probably can't do zero-copy.
>>>
>>> The most promising option I found was dm-userspace
>>> (http://wiki.xensource.com/xenwiki/DmUserspace), which implements a
>>> device-mapper target with an in-kernel MMU-like lookup mechanism that
>>> calls out to userspace when block addresses need to be translated.
>>> It's not anywhere near to upstream and hasn't been pushed for several
>>> years.  On the plus side we could also write a userspace
>>> implementation of this so that QEMU image formats continue to be
>>> portable to other host OSes without duplicating code.
>>>
>>> If tcm_vhost only works with raw images then I don't see it as a
>>> realistic option given the effort it will require to complete and
>>> maintain.
>>>
>>
>> So there has been interest in the past for creating a TCM backend that
>> allows for a userspace passthrough, but so far the code to do this has
>> not materialized yet..
>>
>> There are pieces of logic from STGT that provide an interface for doing
>> something similar that still exist in the upstream kernel.  Allowing
>> different QEMU formats to be processed (in userspace) through a hybrid
>> TCM backend driver that fits into the existing HBA/DEV layout in
>> /sys/kernel/config/target/$HBA/$DEV/ is what would be required to really
>> do this properly..
>
> Could you point to the existing upstream code?
>
> I think the hybrid TCM backend driver means a way for a userspace
> process to execute SCSI Tasks from the target - implementing a subset
> of se_subsystem_api in userspace?
>
> If we solve the problem at the block driver level instead of inside
> the SCSI target then it's also possible for the host to inspect VM
> disk images similar to loopback devices (mount -o loop).  Do you think
> putting the userspace interface into the SCSI target has advantages
> over the block driver or device-mapper level?
>

Hi Stefan,

A little bit off-topic but

When you design the proper place and API to plug virt-scsi into an
external SCSI parser outside of qemu like the target in the kernel ...

It would be very nice if one could also plug virt-scsi into libiscsi
and pass the CDBs straight to the remote iSCSI target too.
Keep some thoughts on virt-scsi + libiscsi integration.


regards
ronnie sahlberg