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

[Rob Landley]

On 05/12/2011 08:20 AM, Vincent Palatin wrote:
> Hi,
> 
> On Wed, May 11, 2011 at 22:39, Rob Landley <address@hidden> wrote:
>> 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?
> 
> First of all, as you have 2 totally separated subnets in your setup, I
> think your command-line should use "vlan=" parameter to isolate them,
> else you will end up with some random routing/broadcasting (and random
> tends to change over time).

Does the kernel need some sort of vlan support compiled into it for this
to work, or can the kernel not care?

> I'm not using setup with multiple NICs but I would have written something 
> like :
> qemu -net nic,vlan=1,blah -net user,vlan=1 -net nic,vlan=2,blah -net
> tun,vlan=2,blah
> 
> In addition to this, which type of NIC are you using ?

The actual command line is various permutations of:

~/qemu/qemu/x86_64-softmmu/qemu-system-x86_64 -m 512 -kernel
~/linux/linux/arch/x86/boot/bzImage -no-reboot -hda squeeze.ext3 -append
"root=/dev/hda rw" -net nic,model=e1000,macaddr=52:54:00:11:11:11 -net
user -redir tcp:9876::22 -net nic,model=e1000,macaddr=52:54:00:22:22:22
-net tap,ifname=kvm0,script=no,downscript=no

With the parameters reordered to try to beat some controllable behavior
out of it.  (It had a deterministic behavior before the above commit,
going back at least 2 years.  The behavior was changed by the commit.)

> In my understanding, the Linux kernel might assign interface number
> depending on the order the interfaces are appearing.

It's going in PCI bus order.  And the _interfaces_ are still happily in
PCI bus order both before and after this commit.  What's changing is the
association between interface and -net user or -net tap.

The first one, with macaddr 11:11:11, is always eth0.  But before the
patch, eth0 is -net user, and after the patch eth0 is -net tap.

> Without my change, when a packet arrives and should be distributed to
> multiple interfaces (that seems to be the case in your setup even
> though it is not intended)

That that I know of.  DHCP was doing broadcast out of eth0, but ignoring
eth1.  (It's still attempting to do that, it's just not getting a
response unless I hook the tun/tap plumbing up to a dhcp server on the
host.)

> if one of the interface is not ready, the
> packet is only forwarded to the ready interface (and the other never
> receives it). This produces interesting timing effects where packets
> are routed according to obscure race conditions, but in your former
> setup, that might cause the packet to be routed to the interface you
> want.

That does not seem to match what I'm seeing.

Rob