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/
Home Products Support Community News


[Xen-devel] Re: [RFC] pv-scsi driver (scsiback/scsifront)

To: akira hayakawa <hayakawa.akira@xxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC] pv-scsi driver (scsiback/scsifront)
From: James Smart <James.Smart@xxxxxxxxxx>
Date: Fri, 18 May 2007 09:08:53 -0400
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 18 May 2007 06:07:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <FAC798F70EA827hayakawa.akira@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1AC79799C3B324t.horikoshi@xxxxxxxxxxxxxx> <464B02B5.5000903@xxxxxxxxxx> <FAC798F70EA827hayakawa.akira@xxxxxxxxxxxxxx>
Reply-to: James.Smart@xxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (Windows/20070221)

I would expect "fc" does not need to be specified, unless there
is FC-isms exposed to the guest.

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.

   Do you have any comment?
 * We have no idea how to implement suspend/resume feature.
   ex. Physical HBA mapping for resumed guest.
       Pending I/O.
       The WWN within FC mode for resumed guest.
The WWN is a whole different issue - and I'm going to want to make
sure that whatever you do here is consistent with FC NPIV virtual
ports instantiated in Dom 0. See:

We think whether WWN is same value or not when a guest resumes again is
unknown because the WWN may be already used by another guest.

This confuses me greatly. WWN's are how FC ports are known - which controls
their SAN visibility and device access.  If it's changing for the VM, unless
you have everything seeing everything (i.e. no SAN zoning or lun masking,
which is very very rare in a production environment) then whether you see
your storage is questionable. For this reason, regular NPIV will be adding
the WWNs as a resource of the guest, much like the ethernet MAC addresses.
And, if it is bound to the guest, it matches the model needed for
suspend/resume, although there are challenges for discovery and enumeration.

Additionally, I certainly hope you are keeping far more control on how WWN's
are allocated and used. There is that small part about uniqueness that has
to be maintained or the fabric will show very nasty issues.

-- james

Xen-devel mailing list