Re: [Qemu-devel] [PATCH] This patch adds a new block driver : iSCSI

[Daniel P. Berrange]

On Thu, Sep 15, 2011 at 11:48:35AM +0300, Dor Laor wrote:
> On 09/15/2011 09:04 AM, Paolo Bonzini wrote:
> >On 09/15/2011 01:08 AM, ronnie sahlberg wrote:
> >>I think it is reasonable to just not support iscsi at all for
> >>blocksize that is not multiple of 512 bytes
> >>since a read-modify-write cycle across a network would probably be
> >>prohibitively expensive.
> >
> >Agreed.
> >
> >>.bdrv_flush() I can easily add a synchronous implementation of this
> >>unless your patch is expected to be merged
> >>in the near future.
> >
> >We need the same patch for NBD, so I wouldn't bother with the
> >synchronous flush.
> >
> >Paolo
> >
> >
> 
> It seems to me that using a qemu external initiator/target pairs
> like Orit's original design in 
> http://wiki.qemu.org/Features/LiveBlockMigration#ISCSI_for_non_shared_storage
> would be a simpler (in terms of qemu code..) and flexible solution.
> 
> I agree that embedding the iscsi initiation in qemu can simplify the
> end user life but since this scenario is expected to be used by
> higher level software it's not relevant here. The risk is to have to
> maintain more code that won't be as general as the tgtd/lio
> solutions out there.

This should not be considered an either/or decision really. There are
compelling benefits for having a iSCSI initiator inside QEMU which Ronnie
outlined in the first mail in this thread. The enablement for non-root
users is, on its own, enough justification IMHO.

  * Privacy: The iSCSI LUNs are private to the guest and are not
    visible either to the host, nor to any processes running on the host.

  * Ease of managment : If you have very many guests and very many,
    thousands of, iSCSI LUNs. It is inconvenient to have to expose
    all LUNs to the underlying host.

  * No root requirement. Since the iSCSI LUNs are not mounted as
    devices on the host, ordinary users can set up and use iSCSI
    resources without the need for root privilege on the host to
    map the devices to local scsi devices.

There are several other benefits too

  * Since the network I/O for the iSCSI LUN is now done by the
    QEMU process instead of the kernel, each VM's iSCSI I/O
    traffic can be insolated & controlled via the cgroups network
    contorller / tc network classifier.

  * Portable across OS. Each OS has different tools for setting
    up iSCSI usage. A native driver lets QEMU users setup iSCSI
    in the same way regardless of the level of OS support for
    iSCSI.

Finally experiance integrating with the Linux iscsiadm command line
tools in libvirt, has shown that they can be quite a PITA to integrate
with if your mgmt app wants reliable/predictable results from their
usage regardless of what an admin may have previously setup on the
host.

So, IMHO, from a QEMU POV it makes perfect sense to have a builtin
iSCSI initiator, as an alternative to using the OS' iSCSI tools
externally. Vendors of applications managing KVM/QEMU are then free
to decide which of the approaches they wish to support in their own
products.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|