Bug 999482

Summary: Libvirt failed to map VF in a virtual machine when using SR-IOV PCI passthrough
Product: [Fedora] Fedora Reporter: MG <mathis.gavillon>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 19CC: berrange, clalancette, itamar, jforbes, jyang, laine, libvirt-maint, mathis.gavillon, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-21 15:37:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description MG 2013-08-21 11:48:18 UTC 
Description of problem:

Hi,

I try to map an Intel I350 Gigabit Ethernet Virtual Function in a virtual machine using libvirt, as described in RedHat documentation (https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/sect-Virtualization_Host_Configuration_and_Guest_Installation_Guide-SR_IOV-How_SR_IOV_Libvirt_Works.html).

The virtual functions are correctly loaded : 

[root@toto0 ~]# lspci | grep Eth
02:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
02:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
02:10.0 Ethernet controller: Intel Corporation I350 Ethernet Controller Virtual Function (rev 01)
02:10.1 Ethernet controller: Intel Corporation I350 Ethernet Controller Virtual Function (rev 01)

Here is my virtual network card configuration defined in /etc/libvirt/qemu/test1_rhel6.4.xml :

<interface type='hostdev'>
  <mac address='52:54:00:33:c0:ec'/>
  <source>
    <address type='pci' domain='0x0000' bus='0x02' slot='0x10' function='0x0'/>
  </source>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

When I try to start the virtual machine, it crashes with this message : 

[root@toto0 ~]# virsh start test1_rhel6.4
erreur :Failed to start domain test1_rhel6.4
erreur :Unable to read from monitor: Connection reset by peer

Here is domain log : 

qemu-system-x86_64: -device pci-assign,configfd=24,host=02:10.0,id=hostdev0,bus=pci.0,addr=0x3: assigned_dev_register_regions: Error: Couldn't mmap 0xdfda0000!
qemu-system-x86_64: -device pci-assign,configfd=24,host=02:10.0,id=hostdev0,bus=pci.0,addr=0x3: Device 'kvm-pci-assign' could not be initialized
2013-08-21 04:45:57.998+0000: shutting down

Version-Release number of selected component (if applicable):

qemu-kvm-1.4.2-3.fc19.x86_64
libvirt-1.0.5.2-1.fc19.x86_64
Comment 1 Laine Stump 2013-08-21 13:34:40 UTC 
Try setting:

user = root
group = root
clear_emulator_capabilities = 0

in /etc/libvirt/qemu.conf, then restarting libvirtd. If you can now start the guest with the VF assigned, you have encountered Bug 908888. If so, please mark this as a duplicate of that bug, and post a comment there requesting escalation.
Comment 2 MG 2013-08-21 15:37:36 UTC 
That solves the problem.

I had already tried to set the clear_emulator_capabilities to 0 but not user and group to root.

Thanks for your answer

*** This bug has been marked as a duplicate of bug 908888 ***
Comment 3 Laine Stump 2013-08-22 11:55:28 UTC 
To avoid setting clear_emulator_capabilities=0 and user=root, an alternate fix would be to instead add "<driver name='vfio'/>" to the device entry in the XML. You'll need to make sure that the vfio-pci module is loaded. This will be the preferred method of device assignment in the future.