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

[Markus Armbruster]

Rob Landley <address@hidden> writes:

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

I guess it was chosen for similarity to -chardev.  Both create a device
host part.

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

Documented in docs/qdev-device-use.txt.

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

"user" is shorthand for "type=user".  The short form is only accepted
when it comes first.  Many option arguments of the form NAME=VALUE...
work that way, including -net.

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

Relatively recent regression, suspecting commit f68b9d67.  Ignore the
warning for now.

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

Yes.

If you want multiple guest NICs on the same ethernet, use a bridge.

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

Important optimizations like GSO or vhost-net aren't feasible with
-net's VLANs.  That's why -netdev got added[*].  VLANs are still around
for backward compatibility.  I hope we can get of them eventually.

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

Let me know whether I've found more ways to confuse you.


[*] http://lists.gnu.org/archive/html/qemu-devel/2009-10/msg00858.html