[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [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 softwareworks 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 sameway 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=2We think whether WWN is same value or not when a guest resumes again isunknown 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |