Re: [Qemu-devel] -net interface association behavior change in current -git.

[Markus Armbruster]

Rob Landley <address@hidden> writes:

> On 05/13/2011 01:54 AM, Markus Armbruster wrote:
>> Rob Landley <address@hidden> writes:
>> 
>>> On 05/12/2011 09:10 AM, Markus Armbruster wrote:
>>>> Rob Landley <address@hidden> 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.