qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vincent Palatin
Subject: Re: [Qemu-devel] -net interface association behavior change in current -git.
Date: Thu, 12 May 2011 09:20:37 -0400

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).
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 ?
In my understanding, the Linux kernel might assign interface number
depending on the order the interfaces are appearing.
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) 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.

-- 
Vincent



reply via email to

[Prev in Thread] Current Thread [Next in Thread]