Bug 1275949

Here is the link to the commit so that you can see the differences:

https://gitlab.cee.redhat.com/red-hat-enterprise-linux-documentation/doc-Red_Hat_Enterprise_Linux-7-Virtualization_Deployment_and_Administration_Guide/commit/cbc8d7ad372ad6df7964adf47d128b9c883421bf

Here are the links to the updated documentation:

http://jenkinscat.gsslab.pnq.redhat.com:8080/job/doc-Red_Hat_Enterprise_Linux-7-Virtualization_Deployment_and_Administration_Guide%20%28html-single%29/lastStableBuild/artifact/tmp/en-US/html-single/index.html#sect-PCI_devices-PCI_passthrough

http://jenkinscat.gsslab.pnq.redhat.com:8080/job/doc-Red_Hat_Enterprise_Linux-7-Virtualization_Deployment_and_Administration_Guide%20%28html-single%29/lastStableBuild/artifact/tmp/en-US/html-single/index.html#sect-SR_IOV-Troubleshooting_SR_IOV

Troubleshoot.xml:

The comment about coredump is inaccurate - while a normal coredump isn't possible on a guest with an assigned PCI device, it *can* be done if you specify the option "--memory-only" then you will be able to get a coredump of a guest that has PCI devices assigned.


PCI_Assignment.xml:

* According to Alex, the blanket statement that "Virtual machines that use the Xeon E3-1200 series chip set, do not support SR-IOV" is inaccurate. Due to "quirk" entries in the kernel, device assignment can usually be supported with that CPU (as well as with i3/i5/i7 CPUs that aren't mentioned in this document, but *are* mentioned in Alex's blog post that you reference in this doc). I'll leave it up to him to provide proper text for that paragraph.

* In several places, this file refers to "mapping" a VF to a virtual machine, e.g.:

  The hypervisor can map one or more Virtual Functions to a virtual machine

That should instead use the word "assign" (there are other uses of the word "map" that probably *are* correct):

  The hypervisor can assign one or more Virtual Functions to a virtual machine


(In general the description of SRIOV seems more complicated than necessary, but I don't have the presence of mind to provide an alternative :-))

* Under "Advantages of SRIOV" you can add this:

"When an SRIOV VF is assigned to a virtual machine, it can be configured to (transparently to the virtual machine) place all network traffic going out that VF onto a oarticular VLAN; the virtual machine is unable to detect that its traffic is being tagged for a VLAN, and will be unable to change or eliminate this tagging."

*In "Using SR-IOV" section, I don't think it's necessary to say "libvirt-0.9.10 and newer", since libvirt has been beyond that version since RHEL 6.4 or so and this documentation is for RHEL7.

* The section "Start the SR-IOV kernel modules" should be unnecessary - I have never seen a system where this didn't happen automatically at boot when the card was installed (Alex, do you agree?)

* the section "Activate Virtual Functions" should just tell them to run:

    echo ${num_vfs} > /sys/class/net/${pf_name}/device/sriov_numvfs

(i.e. the same command that they're told to add to /etc/rd.d/rc.local in the following section, "Make the Virtual Functions persistent".)

* the short note after the sample output of "virsh nodedev-list" calls the names of the devices "serial numbers". Thos are not serial numbers, they are PCI addresses.

*in "get device details" section - don't call it "advanced output", call it device details".

* In the example that starts with "This example adds the Virtual Function <systemitem>pci_0000_0b_10_0</systemitem> to the virtual machine in Step 9", it would probably make things less confusing if:

1) you made an example that used one of the VFs listed in the previous "nodedev-dumpxml" example, rather than a device at some other random address. So, e.g. use the VF device pci_0000_03_10_2, which has this address:

     <address domain='0x0000' bus='0x03' slot='0x10' function='0x2'/>

(be sure to include the leading 0x on each number, as they are hexadecimal (in the eaxmple youo have now, youo convert the numbers to decimal, but don't explain that. It's best to just keep them as hex). Also, the description of the first example describes a vlan tag of 42, but that isn't shown until the 2nd example.

Alex - what is the proper thing to be said about ACS at the top of the diff for PCI_Assignment.xml? This is what is said currently:

"Virtual machines that use the Xeon E3-1200 series chip set, do not support SR-IOV. More information can be found on Intel's website or in this <ulink url="http://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html">article</ulink>."

(You had told me in IRC that this isn't accurate)