WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [RFC] [0/4] PV driver for FC transport layer

From: Jun Kamada <kama@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] [0/4] PV driver for FC transport layer
Date: Wed, 04 Jul 2007 20:03:32 +0900

> Hi Ian-san,
> 
> Thank you for your reply.
> 
> On Tue, 3 Jul 2007 01:07:04 +0100
> "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx> wrote:
> 
> > > We developed a prototype of para-virtual FC(Fibre Channel) SCSI
> > driver.
> > > It's a extension of the "pv-scsi" driver, that Horikoshi-san posted on
> > > 16 May 2007 ([Xen-devel] [RFC] pv-scsi driver (scsiback/scsifront)),
> > > in order to support FC transport layer.
> > 
> > I'm struggling slightly to understand the usage scenario planned for
> > this stuff. Mapping a SCSI LUN through to a guest makes perfect sense
> > (e.g. for performing SCSI reservations, special SCSI commands like FUA,
> > controlling a tape robot etc), but mapping a whole HBA through to a
> > guest seems less useful -- usually it's the case you want to hide all
> > that nastiness from the guest, taking care of multipath etc in dom0
> > rather than exposing it to the guest. 
> > 
> > Have you a particular scenario in mind? 
> 
> We are planning to run a storage management software, which controls
> bindings storages on FC network to hosts, on group of guest domains.
> The software expect that each guest domain has each HBA, and control the
> HBA directly. (Ex. resetting SCSI bus and getting WWN, ...)

How do you support storage management software that uses non-scsi?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel