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
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list