Xen devel - Jun 2007 - [RFC] [0/4] PV driver for FC transport layer

Hi all,

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.

The FC extension mainly performs following processes.

1. Copies FC attributes stored in Dom0 to DomU at the driver
   initialization phase. The attributes are originally stored in
   "Scsi_Host", "scsi_target" and "fc_rport"
structures.
2. When /sys/class/fc_*/*/* on DomU is accessed from user land, performs
   appropriate function on Dom0.

We expect your helpful comments especially at following point of view.

- What any other functions are required in order to behave as
"complete"
  FC driver? (We are not familiar with FC driver.)
- This is the sub-question of above. Current prototype supports only
  "frontend driven" functions. What types of "backend
driven" functions
  we have to support?

Any other comments are welcomed.

Best regards

-----
Jun Kamada
Linux Technology Development Div.
Server Systems Unit
Fujitsu Ltd.
kama@jp.fujitsu.com



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

Jun Kamada
Linux Technology Development Div.
Server Systems Unit
Fujitsu Ltd.
kama@jp.fujitsu.com


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

Jun Kamada
Linux Technology Development Div.
Server Systems Unit
Fujitsu Ltd.
kama@jp.fujitsu.com


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

Jun Kamada
Linux Technology Development Div.
Server Systems Unit
Fujitsu Ltd.
kama@jp.fujitsu.com


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

Jun Kamada
Linux Technology Development Div.
Server Systems Unit
Fujitsu Ltd.
kama@jp.fujitsu.com


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

> 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? 

Thanks,
Ian

 
> The FC extension mainly performs following processes.
> 
> 1. Copies FC attributes stored in Dom0 to DomU at the driver
>    initialization phase. The attributes are originally stored in
>    "Scsi_Host", "scsi_target" and "fc_rport"
structures.
> 2. When /sys/class/fc_*/*/* on DomU is accessed from user land,
performs
>    appropriate function on Dom0.
> 
> We expect your helpful comments especially at following point of view.
> 
> - What any other functions are required in order to behave as
"complete"
>   FC driver? (We are not familiar with FC driver.)
> - This is the sub-question of above. Current prototype supports only
>   "frontend driven" functions. What types of "backend
driven"
functions
>   we have to support?
> 
> Any other comments are welcomed.
> 
> Best regards
> 
> -----
> Jun Kamada
> Linux Technology Development Div.
> Server Systems Unit
> Fujitsu Ltd.
> kama@jp.fujitsu.com
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Ian-san,

Thank you for your reply.

On Tue, 3 Jul 2007 01:07:04 +0100
"Ian Pratt" <Ian.Pratt@cl.cam.ac.uk> 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, ...)

On the other hand, we consider that NPIV (N_Port ID Virtualization)
technology makes it possible to assign whole "logical/virtual" HBA to
each gueast domain.

That''s our scenario in mind.

Best regards

-----
Jun Kamada
Linux Technology Development Div.
Server Systems Unit
Fujitsu Ltd.
kama@jp.fujitsu.com



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

From: "Ian Pratt" <Ian.Pratt@cl.cam.ac.uk>
Subject: RE: [Xen-devel] [RFC] [0/4] PV driver for FC transport layer
Date: Tue, 3 Jul 2007 01:07:04 +0100
> > 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. 
Mapping a SCSI LUN through to a guest is far complicated since it
needs the SCSI state machine.

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

From: Jun Kamada <kama@jp.fujitsu.com>
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@cl.cam.ac.uk> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, Fujita-san,

On Fri, 06 Jul 2007 09:22:15 +0900
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
wrote:
> > 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?
Current our scope is only SCSI on FC.
What do you mean as the "non-scsi" ?

-----
Jun Kamada
Linux Technology Development Div.
Server Systems Unit
Fujitsu Ltd.
kama@jp.fujitsu.com



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

From: Jun Kamada <kama@jp.fujitsu.com>
Subject: Re: [Xen-devel] [RFC] [0/4] PV driver for FC transport layer
Date: Fri, 06 Jul 2007 15:44:16 +0900
> Hi, Fujita-san,
> 
> On Fri, 06 Jul 2007 09:22:15 +0900
> FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> > > 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?
> 
> Current our scope is only SCSI on FC.
> What do you mean as the "non-scsi" ?
James Smart also asked you guys about this at the previous submission:

http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00689.html

---
> We want to use SAN management software on guest OS. The software
> works on native(no VM) linux. So we think it is necesarry to 
> have guest OS shown whether HBA card is FC or SCSI in the same
> way of native linux.
Well - depends on what/how your san mgmt works. If it''s straight scsi,
then it would be fine - but you can''t talk to anything non-scsi and
not enumerated by the hba.  If it''s layered on hbaapi, it does mean
you want to talk FC, not just scsi, and now things change significantly.

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

Fujita-san,

I''m sorry if following may not be a straight answer for your question.

Please imagine a large IDC. In general, some guest domain groups, which
have different storage managemnt policy, exist in the IDC. And, the each
domain group would like to have own storage management software within
the guest domain group.

We consider that the management software requires at least following
function to platform the software is running on.

- inform whether the currently focussed storage device or HBA is pure
  SCSI or FC-SCSI.
- if FC-SCSI, inform FC attributes such as WWN to the software.

According to the information aquired, the storage managemant software
can control bindings of the storage and the HBA.


Thanks,

On Fri, 06 Jul 2007 16:26:11 +0900
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> From: Jun Kamada <kama@jp.fujitsu.com>
> Subject: Re: [Xen-devel] [RFC] [0/4] PV driver for FC transport layer
> Date: Fri, 06 Jul 2007 15:44:16 +0900
> 
> > Hi, Fujita-san,
> > 
> > On Fri, 06 Jul 2007 09:22:15 +0900
> > FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> > > > 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?
> > 
> > Current our scope is only SCSI on FC.
> > What do you mean as the "non-scsi" ?
> 
> James Smart also asked you guys about this at the previous submission:
> 
> http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00689.html
> 
> ---
> > We want to use SAN management software on guest OS. The software
> > works on native(no VM) linux. So we think it is necesarry to 
> > have guest OS shown whether HBA card is FC or SCSI in the same
> > way of native linux.
> 
> Well - depends on what/how your san mgmt works. If it''s straight
scsi,
> then it would be fine - but you can''t talk to anything non-scsi
and
> not enumerated by the hba.  If it''s layered on hbaapi, it does
mean
> you want to talk FC, not just scsi, and now things change significantly.
Jun Kamada
Linux Technology Development Div.
Server Systems Unit
Fujitsu Ltd.
kama@jp.fujitsu.com



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