This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 999482 - Libvirt failed to map VF in a virtual machine when using SR-IOV PCI passthrough
Libvirt failed to map VF in a virtual machine when using SR-IOV PCI passthrough
Status: CLOSED DUPLICATE of bug 908888
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-21 07:48 EDT by MG
Modified: 2013-08-22 07:55 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-21 11:37:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description MG 2013-08-21 07:48:18 EDT
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 09:34:40 EDT
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 11:37:36 EDT
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 07:55:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.