| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [RFC] pv-scsi driver (scsiback/scsifront)
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home