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

[Rob Landley]

On 05/13/2011 07:19 AM, Markus Armbruster wrote:
> 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.

Well, not calling it a "VLAN" which already has at least two other
meanings is less confusing, so I'll give it a shot.  (I'm trying to
update my container documentation at http://landley.net/lxc so I don't
just want to get this to work but I want to be able to EXPLAIN it.)

The name "netdev" is not self-explanatory.  FYI.  Let's see...

Doesn't like "macaddr".  It got gratuitously renamed to "mac=".  Eh,
remove that and try again.

qemu-system-x86_64: -netdev id=lan0,user,hostfwd=tcp:127.0.0.1:9876-:22:
Parameter 'type' is missing

Um, no it isn't?  Ok, that argument magically has to be first...

So my third wild guess at redoing my command line worked:

qemu-system-x86_64 -m 512 -kernel ~/linux/linux/arch/x86/boot/bzImage
-no-reboot -hda squeeze.ext3 -append "root=/dev/hda rw" -netdev
user,id=lan0,hostfwd=tcp:127.0.0.1:9876-:22 -device e1000,netdev=lan0
-netdev tap,id=lan1,ifname=kvm0,script=no,downscript=no -device
e1000,netdev=lan1
Warning: more nics requested than this machine supports; some have been
ignored

I have no idea where that warning came from, but I got both my
interfaces so it's at least working.

> 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.

Um, are you saying I CAN'T connect multiple guest parts to -netdev user?

> 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.

Is the old mechanism ever going to get removed?  Does the new one
actually do anything the old one couldn't?  Why are there two redundant
mechanisms here anyway?

>>>> (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.

I'm now confused about different things, which is progress.  (Possibly
lateral progress, but eh, still new territory.)

Rob