On Mon, Feb 23, 2009 at 09:41:20PM -0500, Dave Allan wrote:
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.
You are of course right. My
mail probably sounded overly "pessimistic".
Dan's SCSI HBA pool code is a great addition! I just can't wait until we
support active/passive arrays ;)
-- Guido