Rob Landley <r...@landley.net> writes:
> 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.
Sorry :)
> 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...)
A virtual network device has a host and a guest part.
The modern way to configure host and guest part is -netdev for host and
-device for guest part. Example:
-netdev user,id=net0 -device e1000,netdev=net0
(qemu) info network
Devices not on any VLAN:
net0: net=10.0.2.0, restricted=n peer=e1000.0
e1000.0: model=e1000,macaddr=52:54:00:12:34:56 peer=net0
One guest part connected to one host part.
For backward compatibility, the older way still works:
-netdev user,id=net0 -net nic,model=rtl8139,netdev=net0
There's also a completely different kind of host part, called VLAN (not
related to 802.1q VLANs). Example:
-net user,vlan=0 -device rtl8139,vlan=0
(qemu) info network
VLAN 0 devices:
user.0: net=10.0.2.0, restricted=n
rtl8139.0: model=rtl8139,macaddr=52:54:00:12:34:56
You can connect multiple guest parts to it. This is rarely needed, and
when you need it, you're often better off with a real ethernet bridge,
see brctl(8). Best stick to -netdev.
For backward compatibility, the older way still works:
-net user,vlan=0 -net nic,model=rtl8139,vlan=0
You can omit vlan=0, because it's the default.
>>> (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?
Hope the above helps a bit.
