Bug 1349115
Summary: | [RFE] fc_host support in virtio-scsi guests, with support for live migration (QEMU) | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Ademar Reis <areis> | |
Component: | qemu-kvm-rhev | Assignee: | Fam Zheng <famz> | |
Status: | CLOSED WONTFIX | QA Contact: | Xueqiang Wei <xuwei> | |
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 7.2 | CC: | aliang, chayang, coli, dconsoli, dmoessne, famz, hachen, juzhang, lsurette, michal.skrivanek, michen, mtessun, ngu, pbonzini, pezhang, pilux, pingl, rbalakri, srevivo, stefanha, virt-maint, xuwei, yafu, ykaul, ylavi | |
Target Milestone: | rc | Keywords: | FutureFeature, Reopened | |
Target Release: | 7.4 | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | Enhancement | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | 1320621 | |||
: | 1349117 (view as bug list) | Environment: | ||
Last Closed: | 2018-06-21 16:02:35 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | 834514, 1553682, 1553685 | |||
Bug Blocks: | 806907, 1349117, 1404963 |
Description
Ademar Reis
2016-06-22 17:53:40 UTC
*** Bug 834514 has been marked as a duplicate of this bug. *** This feature is best implemented at the libvirt level where LUN hotplug can result in hot adding/removing LUNs at the QEMU level. In order to support this NPIV use case libvirt will also have to add new syntax. See bz#1349117 for the libvirt bug. Hi Stefan, I don't agree on this. It is not about any LUN passthrough, but the NPIV port should be presneted to the guest OS as an adapter, like done with physical adapter passthrough. As already mentioned, please see, e.g. http://www.ibm.com/developerworks/aix/library/au-NPIV/ for implementation. As qemu is not yet able (afaik) to forward a NPIV port to the guest, I think this needs to be added as a functionality to qemu. So I agree, that we also need some libvirt changes for being able to tell qemu which NPIV Port should be provided to the guest, but still qemu also needs to know, how to present this NPIV port to the guest, which also needs to be implemented. So to describe the workflow: 1. NPIV created on OS level 2. the vPort is forwarded to the guest OS 3. The guest OS initializes this device and does the FC-scanning, etc. I think that (2) is not yet implemented in qemu as of now. So put to libvirt / qemu architecture: - libvirt to create N-Port with WWNN/WWPN as requested - libvirt to start qemu and "tell" qemu which virtual device (virtual N-Port) to "forward" to the guest - qemu to take control of this vN-Port and present it to the guest OS accordingly - GuestOS to initialize the vN-Port correctly (FC-LIP, scanning, etc) Please let me know, if you need to discuss this further. Kind regards, Martin (In reply to Martin Tessun from comment #3) > 3. The guest OS initializes this device and does the FC-scanning, etc. I don't think FibreChannel scanning is possible since the virtio-scsi device is not a FC HBA. QEMU emulates a SCSI target. The libvirt solution involves automatically adding/removing LUNs to the QEMU target as they change on the host's NPIV port. The result is that the LUNs in the guest always reflect what is visible on the NPIV port without manually reconfiguring libvirt/QEMU. Can you explain why this doesn't meet your requirements? Hi Stefan, (In reply to Stefan Hajnoczi from comment #4) > (In reply to Martin Tessun from comment #3) > > 3. The guest OS initializes this device and does the FC-scanning, etc. > > I don't think FibreChannel scanning is possible since the virtio-scsi device > is not a FC HBA. It should not be a virtio-scsi device, but a LPFC/QLOGIC device (depending on the parent device). As I have not seen it implemented in Linux, I am not able if the lpfc/qla drivers do detect that there is only a virtual function forwarded to the guest and skips the card initialisation or if it should be done differently. Within AIX you do not really notice if the HBA is a physical provided or a virtualized, as they are always represented as fcp (fibre channel port). From the guest OS perspective there is no difference to a physical adapter on AIX side. > > QEMU emulates a SCSI target. The libvirt solution involves automatically > adding/removing LUNs to the QEMU target as they change on the host's NPIV > port. Ah ok. So if I understand what we are doing correctly, then we provide a virtio-scsi device to the guest and libvirt "attaches" the LUNs provided to the NPIV port to the guest automatically. So just some questions here: * What about "non-disk" devices, like Tapes, Changers? Will they also work? * Does this virtual adapter provide all SCSI commands possible (so does it forward, INQ, SCSI-3-Reservation, etc. > > The result is that the LUNs in the guest always reflect what is visible on > the NPIV port without manually reconfiguring libvirt/QEMU. Ack. Sounds a possible solution to me, as long as all "types" of devices can be correctly "seen" in the guest OS. > > Can you explain why this doesn't meet your requirements? Looks like I did not get your approach in implementing it. Sounded to me like needing to tell qemu to attach the new disks, but I missed the automation part here. Still it would be nice to check if this does work in a generic way (not only for disks). Cheers, Martin (In reply to Martin Tessun from comment #5) > Hi Stefan, > > (In reply to Stefan Hajnoczi from comment #4) > > (In reply to Martin Tessun from comment #3) > > > 3. The guest OS initializes this device and does the FC-scanning, etc. > > > > I don't think FibreChannel scanning is possible since the virtio-scsi device > > is not a FC HBA. > > It should not be a virtio-scsi device, but a LPFC/QLOGIC device (depending > on the parent device). > > As I have not seen it implemented in Linux, I am not able if the lpfc/qla > drivers do detect that there is only a virtual function forwarded to the > guest and skips the card initialisation or if it should be done differently. > > Within AIX you do not really notice if the HBA is a physical provided or a > virtualized, as they are always represented as fcp (fibre channel port). > > From the guest OS perspective there is no difference to a physical adapter > on AIX side. The Linux lpfc driver has PCI SR-IOV support. You can pass through the virtual function to the guest and get the behavior you want (in theory). I have never tried so I don't know how to do it exactly. I'll need to think about your other questions regarding limitations on SCSI commands that can be sent through QEMU. I discussed an alternative software NPIV approach with Paolo Bonzini that may be closer to the virtual Fibre Channel that POWER and Hyper-V offer and it wouldn't go through QEMU's emulated SCSI target.. I'm recycling this bug for fc_host support in QEMU, a separate bug is needed for the kernel. Bug 1349117 is now the tracker. New command line option for QEMU: -device virtio-scsi-pci, {primary,secondary}_{wwnn,wwpn}=0x1234,fc_host=off|primary|secondary Paolo, could you answer that? I think this bug is more or less replaced by bug 1553682 and bug 1553685. (In reply to Paolo Bonzini from comment #18) > I think this bug is more or less replaced by bug 1553682 and bug 1553685. Looks like that's the case indeed, and we need to cleanup some of these BZs. So I'm closing this one. |