Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 807538 - Incorrect default NIC for qemu_system_arm: arm can't use rtl8139
Summary: Incorrect default NIC for qemu_system_arm: arm can't use rtl8139
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
Reported: 2012-03-28 05:33 UTC by Stefan Becker
Modified: 2013-08-18 18:59 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-08-18 18:59:40 UTC

Attachments (Terms of Use)

Description Stefan Becker 2012-03-28 05:33:54 UTC
Description of problem:

For ARM VMs virt-manager uses the same default NIC ("Hypervisor default"), i.e. PCI device rtl8139, as for x86 VMs. But that driver is not included in the standard Fedora ARM kernels.

When you execute the ARM VM by hand with "qemu-system-arm -net nic ..." then you can see that the default NIC for ARM is

    name "smc91c111", bus System

for which the driver is included in the Fedora ARM kernel.

My knowledge of libvirt XML is limited, but I couldn't write the VM XML in such a way that I could define NIC type "smc91c111" on the bus "System", i.e. that libvirt would execute qemu-system-arm with the correct parameters. So the root cause for this problem might be libvirt, not virt-manager.

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

Comment 1 Cole Robinson 2012-04-02 21:02:49 UTC
There are issues with non x86 archs in libvirt and virt-manager. The main blockers are in libvirt though: in an attempt to have stable device addressing it gets the defaults wrong for most non-x86 archs. Reassigning there.

Comment 2 Cole Robinson 2013-08-18 18:59:40 UTC
I posted a series upstream which fixes this issue:

Just closing as UPSTREAM since I'll probably forget to update this bug when the patches actually land.

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