[libvirt] [PATCH 0/1] Merge DanPB's SCSI HBA pool code

Dave Allan dallan at redhat.com
Tue Feb 24 02:41:20 UTC 2009


Guido Günther wrote:
> On Mon, Feb 23, 2009 at 07:53:07PM +0000, Daniel P. Berrange wrote:
>> On Mon, Feb 23, 2009 at 06:03:07PM +0100, Guido G?nther wrote:
>>> On Fri, Feb 20, 2009 at 05:14:54PM -0500, David Allan wrote:
>>>> This patch contains the implementation Daniel Berrange did of storage
>>>> pools using SCSI HBAs.  I have updated it for the current tree in
>>>> preparation for implementing NPIV support.  Let me know what you
>>>> think.
>>> This looks like a great addition but I wonder if it is of any real use
>>> without supporting multipath? On SANs issuing I/O to some paths might
>>> cause severe performance penalties or the LUN might be visible but I/O
>>> is rejected until an explicit switch over command is sent. This would be
>>> handled transparently if multipath would be used on top.
>> This is *not* just for FibreChannel based HBAs. Even single host SATA
> Sure.
>> controllers show up as SCSI HBAs, so its perfectly usable even in that
>> case. So there's no need to block on multipath support
> It's just that using it on fibre based HBAs could cause trouble so
> thought I'd ask.

Hi Guido,

People can already use fibre channel block devices like any other block 
devices with libvirt, so it's already possible for people to try to use 
a passive path on an active/passive array, or use two active paths to 
the same LU thinking they're different LUs, etc.  That's being the case, 
I don't think there's anything in this patch that makes it more likely 
that people will make those kinds of mistakes.  This patch just makes it 
easy to list the LUs accessible by a particular host and provides a 
foundation on which NPIV operations can be implemented.

Dave




More information about the libvir-list mailing list