On Mon, Apr 23, 2012 at 7:33 PM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > On Sat, Apr 21, 2012 at 9:51 AM, Nicholas A. Bellinger > <nab@xxxxxxxxxxxxxxx> wrote: >> On Fri, 2012-04-20 at 12:09 +0100, Stefan Hajnoczi wrote: >>> On Fri, Apr 20, 2012 at 8:46 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
