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

[Lin Ma]

>>> Stefan Hajnoczi <address@hidden> 2/15/2017 11:33 下午 >>>
>On Wed, Feb 15, 2017 at 12:15:02AM -0700, Lin Ma wrote:
>> Hi all,
>>  
>> We know that libvirt can create fibre channels vHBA on host
>> based on npiv, and present the LUNs to guest.
>>  
>> I'd like to implement a virtual fibre channel HBA for qemu,
>> I havn't investigate it deeply yet. The idea presents a fc
>> vHBA in guest, interact with remote fc switch through npiv,
>> The LUNs will be recognized inside guest. I sent this email
>> here to see if you are in agreement with this approach and
>> hope to get some ideas/suggestions.
>>  
>> The frontend is based on virtio, say virtio-fc-pci; the backend
>> is based on npiv of physical fc hba on host.
>> The implementation of this virtual fc hba doesn't support Fc-al,
>> only supports Fabric. It wrappers scsi data info fc frames, then
>> forwards them to backend, sounds like scsi over fc.
>> (maybe I can re-use some of virtio-scsi code/idea to deal with scsi data)
>>  
>> The minimum invocation may look like:
>> qemu-system-x86_64 \
>> ...... \
>> -object fibrechannel-backend,id=fcdev0,host=0000:81:00.0 \
>> -device 
>> virtio-fc-pci,id=vfc0,fc_backend=fcdev0,wwpn=1000000000000001,wwnn=1100000000000001
>>  \
>> ......
>>  
>> BTW, I have no idea how to make migration works:
>> How to deal with the BDF during migration?
>> How to deal with the Fabric ID during migration?
>>  
>> It's a draft idea, There are lots of related code I need to
>> investigate, Currently this is all thoughts I have.
>>  
>> Hello Paolo and Stefan, You are the authors of virtio-scsi,
>> and had some in-depth discuss about virtio-scsi in 2011
>> with Hannes, May I have your ideas/thoughts?
>
>I'm not sure it's necessary for the guest to have FC access.  Fam Zheng
>and Paolo are working on virtio-scsi FC NPIV enhancements.  It should
>make NPIV work better without adding a whole new FC device.
>
>https://lkml.org/lkml/2017/1/16/439
>
>The plan is:
>
>1. libvirt listens to udev events on the host so it can add/remove
>   QEMU SCSI LUNs.
>
>2. virtio-scsi is extended to include a WWPN that the guest can see.
>
>The guest doesn't do any FC fabric level stuff, it just does virtio-scsi
>as usual.
>
>It supports live migration by swapping between a pair of WWPNs across
>migration.
OK, Thanks for the information. This way still makes qemu as a SCSI
TARGET, I'm not sure which way makes more sense, But it does solve
the live migration case.

>What are the benefits of having FC access from the guest?
Actually, I havn't dug it too much, Just thought that from virtualization's
perspective, when interact with FC storage, having complete FC access
from the guest is the way it should use.
Lin