[Qemu-devel] [Patch 0/14] builtin iscsi support
This series of pathces adds built in iscsi support to qemu. The first 12 patches 14 adds a general purpose iscsi client library in a separate subdirectory ./block/iscsi that is aimed at being useful not only for kvm/qemu but for all scsi relates applications. Patch 13 adds the block driver ./block/iscsi.c that interfaces qemu with the library and patch 14 adds the library to build on posix platforms Please review and/or apply. Note that ./block/iscsi/* is aimed at being re-used outisde of qemu/kvm in other applications why qemu/kvm specific calkls are not used there. Syntax to use with TGTD iscsi target is -drive file=iscsi://host[:port]/target-iqn-name/lun for disk devices and -cdrom iscsi://host[:port]/target-iqn-name/lun for cdrom devices
Re: [Qemu-devel] [Patch 0/14] builtin iscsi support
On Fri, Dec 3, 2010 at 11:09 AM, ronniesahlb...@gmail.com wrote: This series of pathces adds built in iscsi support to qemu. Christoph asked why block/iscsi.c exists and we don't have something like hw/iscsi-disk.c. Any thoughts on pass-through SCSI support so CDBs from guest SCSI can be written straight to the iSCSI LUN? Could we support this mode of operation? I like block/iscsi.c because it allows any storage interface (including virtio and ide) to talk to an iSCSI LUN. So I don't think it makes sense to throw away block/iscsi.c. But the idea of a direct iSCSI pass-through might be interesting too. Stefan
Re: [Qemu-devel] [Patch 0/14] builtin iscsi support
On Fri, Dec 3, 2010 at 10:42 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Dec 3, 2010 at 11:09 AM, ronniesahlb...@gmail.com wrote: This series of pathces adds built in iscsi support to qemu. Christoph asked why block/iscsi.c exists and we don't have something like hw/iscsi-disk.c. Any thoughts on pass-through SCSI support so CDBs from guest SCSI can be written straight to the iSCSI LUN? Could we support this mode of operation? That is very simple to add and uses an existing api i already use for my own private sg3-utils branch. ./block.iscsi/scsi-command.c offers an api where you provide a struct scsi_task * structure containing some basic data and the cdb. iscsi_scsi_command_async(). which later invokes the callback with status == SCSI_STATUS_GOOD in which case the buffer from the device contains the data or SCSI_STATUS_CHECK_CONDITON in which case that buffer contains the sense blob instead. So yes, there is already an api in the library that offers you to pass scsi cdb/dataout/datain/response to the device. Instrumenting this to be available to the virtual host as a passthrough scsi device should be relatively simple as a second step. I like block/iscsi.c because it allows any storage interface (including virtio and ide) to talk to an iSCSI LUN. So I don't think it makes sense to throw away block/iscsi.c. But the idea of a direct iSCSI pass-through might be interesting too. That should be very easy to add once the foundation is added into qemu. I would very much like to see bus=scsi make this layer a transparent passthrough layer too, just like it is today for the special case where the file specified matches /dev/sg ronnie sahlberg
Re: [Qemu-devel] [Patch 0/14] builtin iscsi support
On 12/03/2010 05:09 AM, ronniesahlb...@gmail.com wrote: This series of pathces adds built in iscsi support to qemu. The first 12 patches 14 adds a general purpose iscsi client library in a separate subdirectory ./block/iscsi that is aimed at being useful not only for kvm/qemu but for all scsi relates applications. Patch 13 adds the block driver ./block/iscsi.c that interfaces qemu with the library and patch 14 adds the library to build on posix platforms Please review and/or apply. Note that ./block/iscsi/* is aimed at being re-used outisde of qemu/kvm in other applications why qemu/kvm specific calkls are not used there. So should the library be packaged outside of QEMU and then we'll just link against it? Regards, Anthony Liguroi Syntax to use with TGTD iscsi target is -drive file=iscsi://host[:port]/target-iqn-name/lun for disk devices and -cdrom iscsi://host[:port]/target-iqn-name/lun for cdrom devices
Re: [Qemu-devel] [Patch 0/14] builtin iscsi support
On Sat, Dec 4, 2010 at 2:05 AM, Anthony Liguori anth...@codemonkey.ws wrote: On 12/03/2010 05:09 AM, ronniesahlb...@gmail.com wrote: Note that ./block/iscsi/* is aimed at being re-used outisde of qemu/kvm in other applications why qemu/kvm specific calkls are not used there. So should the library be packaged outside of QEMU and then we'll just link against it? Eventually I guess. But that would take a long time before it is ready for standalone distrution. I see this as similar to the situation with LIBTALLOC and LIBTDB that originated from samba. For many years these libraries were kept as local copies inside the source trees of many projects, including samba3, samba4, ctdb, openchange, etc where the tdb/talloc maintainers merged patches and fixes across the different comsumer projects manually. While these libraries are now at a stage where they are mature enough to stand on their own, they now start to appear as separate standalone packages for distros. So in time, once all distros ship them as standalone the local copies held in some of the projects may be removed and replaced with linking with the standalone library instead. I see that as one possible path how a library is started to be used, how it evolves and once proven and mature enough it becomes a standalone package. Do you see a problem with that path and/or would you want that path not to be used in qemu/kvm ? While the library is complete enough for the use and the features that qemu/kvm needs, I think there are a lot of work in other areas that kvm/qemu does not need/use before it can become standalone. regards ronnie sahlberg
Re: [Qemu-devel] [Patch 0/14] builtin iscsi support
On 12/03/2010 01:57 PM, ronnie sahlberg wrote: On Sat, Dec 4, 2010 at 2:05 AM, Anthony Liguorianth...@codemonkey.ws wrote: On 12/03/2010 05:09 AM, ronniesahlb...@gmail.com wrote: Note that ./block/iscsi/* is aimed at being re-used outisde of qemu/kvm in other applications why qemu/kvm specific calkls are not used there. So should the library be packaged outside of QEMU and then we'll just link against it? Eventually I guess. But that would take a long time before it is ready for standalone distrution. I don't think stand alone distribution is a big burden. I see this as similar to the situation with LIBTALLOC and LIBTDB that originated from samba. For many years these libraries were kept as local copies inside the source trees of many projects, including samba3, samba4, ctdb, openchange, etc where the tdb/talloc maintainers merged patches and fixes across the different comsumer projects manually. Yeah, and I think this creates a distro nightmare :-) Figuring out which project has which version with which modifications and whether a security patch is applicable is very painful. From a strictly QEMU perspective, I'm not very keen on having code in the repository that doesn't use common infrastructure and doesn't follow our coding style. Regards, Anthony Liguori While these libraries are now at a stage where they are mature enough to stand on their own, they now start to appear as separate standalone packages for distros. So in time, once all distros ship them as standalone the local copies held in some of the projects may be removed and replaced with linking with the standalone library instead. I see that as one possible path how a library is started to be used, how it evolves and once proven and mature enough it becomes a standalone package. Do you see a problem with that path and/or would you want that path not to be used in qemu/kvm ? While the library is complete enough for the use and the features that qemu/kvm needs, I think there are a lot of work in other areas that kvm/qemu does not need/use before it can become standalone. regards ronnie sahlberg
