All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Smart <James.Smart@Emulex.Com>
To: akira hayakawa <hayakawa.akira@jp.fujitsu.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [RFC] pv-scsi driver (scsiback/scsifront)
Date: Fri, 18 May 2007 09:08:53 -0400	[thread overview]
Message-ID: <464DA565.5030200@emulex.com> (raw)
In-Reply-To: <FAC798F70EA827hayakawa.akira@jp.fujitsu.com>


>> 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:
>> http://marc.info/?l=linux-scsi&m=117768770720886&w=2
> 
> 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

  reply	other threads:[~2007-05-18 13:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-16  9:08 [RFC] pv-scsi driver (scsiback/scsifront) Tomonari Horikoshi
2007-05-16 13:10 ` James Smart
2007-05-18  2:48   ` akira hayakawa
2007-05-18 13:08     ` James Smart [this message]
2007-05-17 11:49 ` Ian Pratt
2007-05-22 13:58   ` akira hayakawa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=464DA565.5030200@emulex.com \
    --to=james.smart@emulex.com \
    --cc=hayakawa.akira@jp.fujitsu.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.