Mike wrote: > Hello Lynn, > > I'm using a bridge, which is configured in my /etc/network/interfaces > like this: > auto br0 > iface br0 inet static > address 195.24.77.169 > netmask 255.255.255.0 > gateway 195.24.77.1 > bridge_ports eth0 > bridge_stp off > bridge_maxwait 5 > > an I have a file called qemu-ifup in /etc which has the following content: > #!/bin/sh > /sbin/ifconfig $1 0.0.0.0 promisc up > /usr/sbin/brctl addif br0 $1 > sleep 2 > > Every guest has it's own tap device, atm tap0 - tap4 are in use. > Those peaks are coming after +/- 10 mins (not always the same time, > sometimes after 5 mins, it changes). Within this time, the guests have > normal pings. > > > It might be related to swapping (the host swaps guest pages). Please check the ram size used by the guest. Can you re-run the test with a single test or with disabling the swapping? Thanks, Dor. > Lynn Kerby schrieb: > >> Hi Mike, >> >> Glad to hear that your networks are up now, but what are you using to >> connect/bridge them? Those response times are horrible across the >> board! >> >> All my VMs are connected to my internal network via a bridge on the >> host through their tap interfaces and a few lucky machines share >> another bridge that is on my DMZ with static IPs. I think the >> network bridge method I use is based on some stuff I picked up a few >> years ago when working with the UML virtualization stuff. I see sub >> millisecond ping responses in both directions and to all VMs (usually >> I've got 3 or 4 active, soon to expand to a few more). >> >> My HOST config is similar though I've got a only 4GB of memory and >> I'm still running KVM-52 modules. My guests are Ubuntu 7.10, Fedora >> 8, and FreeBSD 6.2 at the moment with Mint4.0 and JeOS on the drawing >> board. >> >> Lynn Kerby >> San Martin, CA >> >> On Dec 4, 2007, at 2:44 PM, Mike wrote: >> >> >> >>> Hello, >>> I already spoke to Izik Eidus. He told me to publish the results to >>> the >>> problem at the mailinglist. >>> >>> Some time ago I wrote to the kvm-devel mailinglist that I had a >>> problem >>> with my guests' networking dying. >>> I got the hint to change the network card emulation. That worked. >>> >>> Now I noticed a strange behaviour. >>> I have a gameserver running in a guest os. No problems on performance >>> side, really fast. >>> The only thing, when I make a ping test after unspecific time >>> periods I >>> get this: (this peaks are even there if the gameserver isn't running) >>> >>> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=123ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=98ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=116ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=241ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=72ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=382ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=135ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=397ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=647ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=857ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=1156ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=692ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=604ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=188ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=39ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=46ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=39ms TTL=57 >>> >>> This ping peaks are on *all* guests I'm currently running. >>> I did a ping test the same time to the Host, with this result: >>> >>> Reply from 195.24.77.169: bytes=32 time=38ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=39ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=38ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=40ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=37ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> >>> As you can see, no peaks. >>> Example of start command from a guest: >>> kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net >>> nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic >>> -daemonize >>> >>> Here the pings from the guest started with the command line listed >>> above: >>> >>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=97ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=60ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=186ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=363ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=368ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=972ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=673ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=2006ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=2638ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=3590ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=383ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=34ms TTL=57 >>> >>> So I tried disabling kvm when starting a guest. >>> and here the guest *with* -no-kvm in the command line: >>> >>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=37ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=38ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=37ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> >>> The other guest, without -no-kvm have the ping peaks. Also here, no >>> ping >>> peaks from the host. >>> Server load is really really low at the moment of the tests. >>> >>> Maybe you have an idea where this peaks are coming from? >>> I'm using KVM-55 on Ubuntu 7.10 server with Kernel Linux A050 >>> 2.6.22-14-server #1 SMP Sun Oct 14 22:09:15 GMT 2007 x86_64 GNU/Linux. >>> My CPU is an AMD Athlon 64 X2 5600+ (Dual Core) with 8GByte of RAM. >>> >>> Greetings from Luxembourg. >>> Mike Weimichkirch >>> >>> ---------------------------------------------------------------------- >>> --- >>> SF.Net email is sponsored by: The Future of Linux Business White Paper >>> from Novell. From the desktop to the data center, Linux is going >>> mainstream. Let it simplify your IT future. >>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >>> _______________________________________________ >>> kvm-devel mailing list >>> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >>> https://lists.sourceforge.net/lists/listinfo/kvm-devel >>> >>> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: The Future of Linux Business White Paper >> from Novell. From the desktop to the data center, Linux is going >> mainstream. Let it simplify your IT future. >> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >> _______________________________________________ >> kvm-devel mailing list >> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >> https://lists.sourceforge.net/lists/listinfo/kvm-devel >> >> >> > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > kvm-devel mailing list > kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/kvm-devel > >