Re: [Qemu-devel] 答复： Re: [RFC] virtio-fc: draft idea of virtual fibre channel HBA

[Paolo Bonzini <pbonzini@redhat.com>]

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