[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.