On 17/05/2017 08:01, Hannes Reinecke wrote: > On 05/16/2017 06:22 PM, Paolo Bonzini wrote: >> On 16/05/2017 17:22, Hannes Reinecke wrote: >>> iSCSI has its 'iqn' string, which is defined to be a 256-byte string. >>> Hence the number >>> And if we're updating virtio anyway, we could as well update it to carry >>> _all_ possible scsi IDs. >> >> Yes, but one iSCSI connection maps to one initiator and target IQN. >> It's not like FC where each frame can specify its own initiator ID. >> > Sure. But updating the format to hold _any_ SCSI Name would allow us to > reflect the actual initiator port name used by the host. > So the guest could be
... aware of it for things such as PERSISTENT RESERVE IN? >>>>> (3) would be feasible, as it would effectively mean 'just' to update the >>>>> current NPIV mechanism. However, this would essentially lock us in for >>>>> FC; any other types (think NVMe) will require yet another solution. >>>> An FC-NVMe driver could also expose the same vhost interface, couldn't it? >>>> FC-NVMe doesn't have to share the Linux code; but sharing the virtio >>>> standard >>>> and the userspace ABI would be great. >>>> >>>> In fact, the main advantage of virtio-fc would be that (if we define it >>>> properly) >>>> it could be reused for FC-NVMe instead of having to extend e.g. virtio-blk. >>>> For example virtio-scsi has request, to-device payload, response, >>>> from-device >>>> payload. virtio-fc's request format could be the initiator and target port >>>> identifiers, followed by FCP_CMD, to-device payload, FCP_RSP, from-device >>>> payload. >>>> >>> As already said: We do _not_ have access to the FCP frames. >>> So designing a virtio-fc protocol will only work for libfc-based HBAs, >>> namely fnic, bnx2fc, and fcoe. >>> Given that the future of FCoE is somewhat unclear I doubt it's a good >>> idea to restrict ourselves to that. >> >> I understand that. It doesn't have to be a 1:1 match with FCP frames or >> even IUs; in fact the above minimal example is not (no OXID/RXID and no >> FCP_XFER_RDY IU are just the first two things that come to mind). >> >> The only purpose is to have a *transport* that is (roughly speaking) >> flexible enough to support future NPIV usecases which will certainly >> include FC-NVMe. In other words: I'm inventing my own cooked FCP >> format, but I might as well base it on FCP itself as much as possible. > > Weeelll ... I don't want to go into nit-picking here, but FC-NVMe is > _NOT_ FCP. In fact, it's a different FC-4 provider with its own set of > FC-4 commands etc. Yes, but it reuses the IU format and the overall look of the exchange. It's not FCP, but it looks and quacks very much like it AFAIU. >> Likewise, I'm not going to even mention ELS, but we would need _some_ >> kind of protocol to query name servers, receive state change >> notifications, and get service parameters. No idea yet how to do that, >> probably something similar to virtio-scsi control and event queues, but >> why not make the requests/responses look a little like PLOGI and PRLI? >> > And my idea here is to keep virtio-scsi as the basic mode of (command) > transfer, but add a set of transport management commands which would > allow us to do things like: > - port discovery / scan > - port instantiation / login > - port reset > - transport link notification / status check > - transport reset > > Those could be defined transport independently; and the neat thing is > they could even be made to work with the current NPIV implementation > with some tooling. > And we could define things such that all current transport protocols can > be mapped onto it. Okay, got it. So some kind of virtio-scsi 2.0. I think we should weigh the two proposals. Would yours be useful for anything except NPIV (e.g. the iSCSI + persistent reservations case)? What software would use it? And please speak up loudly if I'm completely mistaken about FC-NVMe! Thanks, Paolo
