On 05/13/2011 01:54 AM, Markus Armbruster wrote: > Rob Landley <r...@landley.net> writes: > >> On 05/12/2011 09:10 AM, Markus Armbruster wrote: >>> Rob Landley <r...@landley.net> writes: >>> >>>> In 1.14.0, if I did this: >>>> >>>> qemu -net nic,blah -net user -net nic,blah -net tun,blah >>>> >>>> Then the first nic would be -net user, and the second nic would be -net >>>> tun. In current -git, -net user attaches to the second interface and >>>> -net tun attaches to the first, I.E. the order is reversed. >>>> >>>> Either way the first -nic becomes eth0 in Linux and the second becomes >>>> eth1 (I can manually assign mac addresses in order to confirm which is >>>> which), but eth0 used to be the -net user interface and now eth1 is the >>>> -net user interface. >>>> >>>> I bisected this to commit 60c07d933c66c4b30a83b but I don't know why it >>>> changed the behavior, and I can't find _documentation_ on having >>>> multiple interfaces transports hooked up to the same qemu instance >>>> anyway. (It used to work, but possibly that was an accident?) >>>> >>>> Any ideas? >>> >>> Does it happen with -device and -netdev as well? >>> >>> See docs/qdev-device-use.txt for how to go from -net to -device. >> >> Read read read... >> >> That seems to be micromanaging PCI bus slot assignment, which isn't >> changed by this patch. The cards don't move around, nor does the >> association between cards and Linux eth0/eth1. What changes is which >> virtual LAN each virtual ethernet card is plugged into. (The virtual >> cat5 cable coming out of the card moves to a different switch.) > > I didn't mean to tell you "try using -device to juggle PCI addresses". > I meant to steer you away from QEMU VLANs, to find out whether they're a > factor in your problem. Possible, because non-VLAN uses a few different > code paths in QEMU. Sorry if I was too terse. > > In general, my advice is stay away from QEMU VLANs.
Ok, now I'm confused. Before this, I wasn't using them. Now I am. What's the reason for avoiding them? (Also, I didn't see a way in -device to specify a network transport, just cards and their properties. Quite possibly I missed it...) >> (The fix was to tag everything with vlan arguments and manually manage >> the association.) > > Glad you got your problem solved. Solved, yes. Understood... less so than I thought, apparently? Rob
