Hi, In order to be able to use qemu's bridged networking without taking my network down, I set up my primary network (eth0) to work through a bridge (br0) right from boot, so that later on the virtual machines can just connect to the bridge and talk to the outside. The downside is that it now takes 30s for the network to acquire an IP from my DHCP server, whereas before, when using only eth0, it took about 3s. I've collected the messages that bridge prints out in the kernel, and I'm hoping that you find something I can do about it - maybe specify some parameters so there's no need for bridge to go trial and error. Anyways, here's the log (I didn't know if the RPC messages were related, so I left them in):> Nov 4 19:29:55 terra kernel: ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [L3CM] -> GSI 11 (level, low) -> IRQ 11 > Nov 4 19:29:56 terra kernel: eth0: Setting promiscuous mode. > Nov 4 19:29:56 terra kernel: device eth0 entered promiscuous mode > Nov 4 19:29:56 terra kernel: br0: port 1(eth0) entering learning state > Nov 4 19:30:03 terra kernel: RPC: sendmsg returned error 101 > Nov 4 19:30:11 terra kernel: br0: topology change detected, propagating > Nov 4 19:30:11 terra kernel: br0: port 1(eth0) entering forwarding state > Nov 4 19:30:16 terra kernel: RPC: sendmsg returned error 101 > Fri Nov 4 19:30:24 CET 2005The last line is from using the command 'dhcpcd br0 && date >> /var/log/messages', so I knew how long it took (which turned out to be 29s). Any hints are greatly appreciated. Cheers, ~Mik -- Pech im Gl?ck, Spiel in der Liebe.
On Fri, 04 Nov 2005 21:08:36 +0100 Michael Bueker <m.bueker@berlin.de> wrote:> Hi, > > In order to be able to use qemu's bridged networking without taking my > network down, I set up my primary network (eth0) to work through a > bridge (br0) right from boot, so that later on the virtual machines can > just connect to the bridge and talk to the outside. > > The downside is that it now takes 30s for the network to acquire an IP > from my DHCP server, whereas before, when using only eth0, it took about 3s. > > I've collected the messages that bridge prints out in the kernel, and > I'm hoping that you find something I can do about it - maybe specify > some parameters so there's no need for bridge to go trial and error. > > Anyways, here's the log (I didn't know if the RPC messages were related, > so I left them in): > > > Nov 4 19:29:55 terra kernel: ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [L3CM] -> GSI 11 (level, low) -> IRQ 11 > > Nov 4 19:29:56 terra kernel: eth0: Setting promiscuous mode. > > Nov 4 19:29:56 terra kernel: device eth0 entered promiscuous mode > > Nov 4 19:29:56 terra kernel: br0: port 1(eth0) entering learning state > > Nov 4 19:30:03 terra kernel: RPC: sendmsg returned error 101 > > Nov 4 19:30:11 terra kernel: br0: topology change detected, propagating > > Nov 4 19:30:11 terra kernel: br0: port 1(eth0) entering forwarding state > > Nov 4 19:30:16 terra kernel: RPC: sendmsg returned error 101 > > Fri Nov 4 19:30:24 CET 2005 > > The last line is from using the command 'dhcpcd br0 && date >> > /var/log/messages', so I knew how long it took (which turned out to be 29s). > > Any hints are greatly appreciated. > > Cheers, > ~MikShorten the forward delay. -- Stephen Hemminger <shemminger@osdl.org> OSDL http://developer.osdl.org/~shemminger