>>> Stefan Hajnoczi <stefa...@gmail.com> 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
