[vbox-dev] FW: Re: [VBox-users] Predictable PCI bus addresses for network interfaces?

Klaus Espenlaub klaus.espenlaub at oracle.com
Wed Jul 17 12:38:34 PDT 2013

Hi Kent,

On 17.07.2013 20:39, Kent R. Spillner wrote:
> Perhaps I'm reading the PCI address wrong?  I just confirmed this on two separate Linux guests both using the PIIX3 chipset, but with only a single network adapter:
> # lspci | grep Ethernet
> 00:11.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 02)
> That bus address is in hex, correct?  So I read that as "bus 0 dev 17 function 0."  I don't believe I performed any magic tricks to enable VMware compat, but I am running the stock VirtualBox 4.2.16 packages for Arch (https://www.archlinux.org/packages/community/x86_64/virtualbox/).

Yes, the bus address is in hex, and with some digging I actually found 
what's going on - you've configured the Intel 82545EM network adapter 
(official Intel product name PRO/1000 MT Server), and the manual gives 
the following hint in section 6.1: "The MT Server variant facilitates 
OVF imports from other platforms." - i.e. this one implicitly enables 
VMware compatibility hack (swapping slots 0x03 and 0x11). If you switch 
to any other model the first device will move to 00:03:0 as expected.

The "nic-vmware" entry in the table in BusAssignmentManager.cpp is 
totally bogus (shouldn't have been there ever), apparently caused by 
mixup between decimal and hex. Fixed in trunk, but this is purely 
cosmetic, there is no behavior change whatsoever.

I'm wondering how you ended up with this card type - there are exactly 
three ways: importing an OVF/OVA appliance which wasn't created by 
VirtualBox, creating a VM with OS type "JRockit VE", or manually 
selecting this card type.

Whatever, riddle solved.


More information about the vbox-dev mailing list