Strange network behaviour

Strange network behaviour

[Mike]

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

Re: Strange network behaviour

[Lynn Kerby]

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

Re: Strange network behaviour

[Mike]

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.


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

Re: Strange network behaviour

[Dor Laor]

[-- Attachment #1.1: Type: text/plain, Size: 10831 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 11667 bytes --]

[-- Attachment #2: Type: text/plain, Size: 309 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: Strange network behaviour

[Mike]

I did a single test, only 1 guest running with kvm activated.
The ping peaks are still there.

How do I disable swapping?

Mike

Dor Laor schrieb:
> 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
>>
>>   
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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

Re: Strange network behaviour

[Izik Eidus]

Dor Laor wrote:
> 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.
it doesnt look like swapping, beacuse all the qemu memory is swappable,
so i guess this not the reason
>
> 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
>>
>>   
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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

Re: Strange network behaviour

[Avi Kivity]

Mike wrote:
> 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)
>
>
> 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
>   

What guest are you running?

'kvm' isn't the name of the binary generated by make.  Are you sure it 
is actually the binary from kvm-55?

-- 
error compiling committee.c: too many arguments to function


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

Re: Strange network behaviour

[Mike]

Avi Kivity schrieb:
> Mike wrote:
>   
>> 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)
>>
>>
>> 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
>>   
>>     
>
> What guest are you running?
>
> 'kvm' isn't the name of the binary generated by make.  Are you sure it 
> is actually the binary from kvm-55?
>
>   
I'm running debian etch with kernel Linux 2.6.18-5-486 #1 Tue Oct 2 
23:38:54 UTC 2007 i686 GNU/Linux
as guest. All the guests are running this distr.
My kvm is pointing to /usr/local/bin/qemu-system-x86_64
2007-12-04 15:29 /usr/local/bin/qemu-system-x86_64

That's the time I compiled kvm-55.


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

Re: Strange network behaviour

[Avi Kivity]

Mike wrote:
> Avi Kivity schrieb:
>   
>> Mike wrote:
>>   
>>     
>>> 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)
>>>
>>>
>>> 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
>>>   
>>>     
>>>       
>> What guest are you running?
>>
>> 'kvm' isn't the name of the binary generated by make.  Are you sure it 
>> is actually the binary from kvm-55?
>>
>>   
>>     
> I'm running debian etch with kernel Linux 2.6.18-5-486 #1 Tue Oct 2 
> 23:38:54 UTC 2007 i686 GNU/Linux
> as guest. All the guests are running this distr.
> My kvm is pointing to /usr/local/bin/qemu-system-x86_64
> 2007-12-04 15:29 /usr/local/bin/qemu-system-x86_64
>   

Ok.  How long does it take for the latency to appear?  If it isn't too 
long, please run kvm with

   strace -fF -ttT -o /tmp/trace kvm ...

Note the time that latency appears so we can correlate with the logs.  
Be aware the logs can be quite large, so make sure you have some disk 
space ready.


-- 
error compiling committee.c: too many arguments to function


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

Re: Strange network behaviour

[Pelle]

Hi,

Is there a fast and simple way to tell the version of the binary?
I think I remember something about that on this mailing list, but I 
can't find it in 'qemu-system-x86_64 -h'


Avi Kivity wrote:
> Mike wrote:
>   
>> 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)
>>
>>
>> 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
>>   
>>     
>
> What guest are you running?
>
> 'kvm' isn't the name of the binary generated by make.  Are you sure it 
> is actually the binary from kvm-55?
>
>   

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

Re: Strange network behaviour

[Mike]

You can download the requested trace at
http://www.eliteserver.biz/trace.tar.gz

the peaks were around 12:04:30

Mike

Avi Kivity schrieb:
> Mike wrote:
>   
>> Avi Kivity schrieb:
>>   
>>     
>>> Mike wrote:
>>>   
>>>     
>>>       
>>>> 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)
>>>>
>>>>
>>>> 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
>>>>   
>>>>     
>>>>       
>>>>         
>>> What guest are you running?
>>>
>>> 'kvm' isn't the name of the binary generated by make.  Are you sure it 
>>> is actually the binary from kvm-55?
>>>
>>>   
>>>     
>>>       
>> I'm running debian etch with kernel Linux 2.6.18-5-486 #1 Tue Oct 2 
>> 23:38:54 UTC 2007 i686 GNU/Linux
>> as guest. All the guests are running this distr.
>> My kvm is pointing to /usr/local/bin/qemu-system-x86_64
>> 2007-12-04 15:29 /usr/local/bin/qemu-system-x86_64
>>   
>>     
>
> Ok.  How long does it take for the latency to appear?  If it isn't too 
> long, please run kvm with
>
>    strace -fF -ttT -o /tmp/trace kvm ...
>
> Note the time that latency appears so we can correlate with the logs.  
> Be aware the logs can be quite large, so make sure you have some disk 
> space ready.
>
>
>   


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

Re: Strange network behaviour

[Uri Lublin]

Mike wrote:
> You can download the requested trace at
> http://www.eliteserver.biz/trace.tar.gz
>
> the peaks were around 12:04:30
>
> Mike
>
> Avi Kivity schrieb:
>   
>> Mike wrote:
>>     
>>> Avi Kivity schrieb:
>>>       
>>>> Mike wrote:
>>>>         
>>>>> 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)
>>>>>
>>>>>
>>>>> 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    
>>>>>           
>> Ok.  How long does it take for the latency to appear?  If it isn't too 
>> long, please run kvm with
>>
>>    strace -fF -ttT -o /tmp/trace kvm ...
>>
>> Note the time that latency appears so we can correlate with the logs.  
>> Be aware the logs can be quite large, so make sure you have some disk 
>> space ready.
>>     
>
Does using a different clock helps ( add "-clock hpet" or "-clock rtc" 
or "-clock unix" to kvm command line) ?

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

Re: Strange network behaviour

[Avi Kivity]

Pelle wrote:
> Hi,
>
> Is there a fast and simple way to tell the version of the binary?
> I think I remember something about that on this mailing list, but I 
> can't find it in 'qemu-system-x86_64 -h'

Right now, only the kernel module (see dmesg).

kvm-56's qemu will also report its version number.

-- 
error compiling committee.c: too many arguments to function


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

Re: Strange network behaviour

[Avi Kivity]

Mike wrote:
> You can download the requested trace at
> http://www.eliteserver.biz/trace.tar.gz
>
> the peaks were around 12:04:30
>
>   

Can you rerun, this time with additional options '-x -s 80' to strace 
(so I can identify the pings from random broadcast noise on the 
network).  Also please run ping on the host itself, so I get regular 
timing without jitter from the Internet.


-- 
error compiling committee.c: too many arguments to function


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

Re: Strange network behaviour

[Mike]

Sure,
here the ping results from the host to the guest atm of the peaks:
64 bytes from postfix (195.24.77.173): icmp_seq=347 ttl=64 time=10.6 ms
64 bytes from postfix (195.24.77.173): icmp_seq=348 ttl=64 time=11.6 ms
64 bytes from postfix (195.24.77.173): icmp_seq=349 ttl=64 time=11.6 ms
64 bytes from postfix (195.24.77.173): icmp_seq=350 ttl=64 time=465 ms
64 bytes from postfix (195.24.77.173): icmp_seq=351 ttl=64 time=455 ms
64 bytes from postfix (195.24.77.173): icmp_seq=352 ttl=64 time=349 ms
64 bytes from postfix (195.24.77.173): icmp_seq=353 ttl=64 time=314 ms
64 bytes from postfix (195.24.77.173): icmp_seq=354 ttl=64 time=483 ms
64 bytes from postfix (195.24.77.173): icmp_seq=355 ttl=64 time=871 ms
64 bytes from postfix (195.24.77.173): icmp_seq=357 ttl=64 time=1889 ms
64 bytes from postfix (195.24.77.173): icmp_seq=358 ttl=64 time=1635 ms
64 bytes from postfix (195.24.77.173): icmp_seq=359 ttl=64 time=1973 ms
64 bytes from postfix (195.24.77.173): icmp_seq=360 ttl=64 time=1796 ms
64 bytes from postfix (195.24.77.173): icmp_seq=361 ttl=64 time=1961 ms
64 bytes from postfix (195.24.77.173): icmp_seq=362 ttl=64 time=2029 ms
64 bytes from postfix (195.24.77.173): icmp_seq=363 ttl=64 time=1994 ms
64 bytes from postfix (195.24.77.173): icmp_seq=364 ttl=64 time=1689 ms
64 bytes from postfix (195.24.77.173): icmp_seq=365 ttl=64 time=932 ms
64 bytes from postfix (195.24.77.173): icmp_seq=366 ttl=64 time=899 ms
64 bytes from postfix (195.24.77.173): icmp_seq=367 ttl=64 time=752 ms
64 bytes from postfix (195.24.77.173): icmp_seq=368 ttl=64 time=860 ms
64 bytes from postfix (195.24.77.173): icmp_seq=369 ttl=64 time=483 ms
64 bytes from postfix (195.24.77.173): icmp_seq=370 ttl=64 time=244 ms
64 bytes from postfix (195.24.77.173): icmp_seq=371 ttl=64 time=7.89 ms
64 bytes from postfix (195.24.77.173): icmp_seq=372 ttl=64 time=5.98 ms
64 bytes from postfix (195.24.77.173): icmp_seq=373 ttl=64 time=6.31 ms

The peaks started @ +/- 14:53:39 and ended @ +/- 14:53:59
You can download the trace file at:
http://www.eliteserver.biz/trace2.tar.gz


Avi Kivity schrieb:
> Mike wrote:
>   
>> You can download the requested trace at
>> http://www.eliteserver.biz/trace.tar.gz
>>
>> the peaks were around 12:04:30
>>
>>   
>>     
>
> Can you rerun, this time with additional options '-x -s 80' to strace 
> (so I can identify the pings from random broadcast noise on the 
> network).  Also please run ping on the host itself, so I get regular 
> timing without jitter from the Internet.
>
>
>   


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

Re: Strange network behaviour

[Avi Kivity]

Mike wrote:
> Sure,
> here the ping results from the host to the guest atm of the peaks:
> 64 bytes from postfix (195.24.77.173): icmp_seq=347 ttl=64 time=10.6 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=348 ttl=64 time=11.6 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=349 ttl=64 time=11.6 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=350 ttl=64 time=465 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=351 ttl=64 time=455 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=352 ttl=64 time=349 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=353 ttl=64 time=314 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=354 ttl=64 time=483 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=355 ttl=64 time=871 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=357 ttl=64 time=1889 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=358 ttl=64 time=1635 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=359 ttl=64 time=1973 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=360 ttl=64 time=1796 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=361 ttl=64 time=1961 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=362 ttl=64 time=2029 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=363 ttl=64 time=1994 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=364 ttl=64 time=1689 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=365 ttl=64 time=932 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=366 ttl=64 time=899 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=367 ttl=64 time=752 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=368 ttl=64 time=860 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=369 ttl=64 time=483 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=370 ttl=64 time=244 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=371 ttl=64 time=7.89 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=372 ttl=64 time=5.98 ms
> 64 bytes from postfix (195.24.77.173): icmp_seq=373 ttl=64 time=6.31 ms
>
> The peaks started @ +/- 14:53:39 and ended @ +/- 14:53:59
> You can download the trace file at:
> http://www.eliteserver.biz/trace2.tar.gz
>
>
>   

The traces show that the periods of latency correspond to floods of 
broadcast packets on the network

>      10 29895 14:53:25
>       9 29895 14:53:26
>       9 29895 14:53:27
>       9 29895 14:53:28
>      16 29895 14:53:29
>      19 29895 14:53:30
>      19 29895 14:53:31
>      14 29895 14:53:32
>      13 29895 14:53:33
>      12 29895 14:53:34
>     205 29895 14:53:35
>     203 29895 14:53:36
>     276 29895 14:53:37
>     234 29895 14:53:38
>     234 29895 14:53:39
>     243 29895 14:53:40
>     234 29895 14:53:41
>     259 29895 14:53:42
>     228 29895 14:53:43
>     325 29895 14:53:44
>     242 29895 14:53:45
>     271 29895 14:53:46
>     251 29895 14:53:47
>     227 29895 14:53:48
>     178 29895 14:53:49
>     166 29895 14:53:50
>     271 29895 14:53:51
>     244 29895 14:53:52
>     287 29895 14:53:53
>     196 29895 14:53:54
>     215 29895 14:53:55
>      83 29895 14:53:56
>      65 29895 14:53:57
>      10 29895 14:53:58
>       9 29895 14:53:59
>      10 29895 14:54:00
>      14 29895 14:54:01
>      14 29895 14:54:02
>      12 29895 14:54:03
>      13 29895 14:54:04
>      16 29895 14:54:05

The first column is the number of packets delivered at the time in the 
third column.  The broadcast packets are clearly visible in the trace as 
having \xff in the first 6 bytes of the packet.  The ping packet is 
getting queued behind the broadcasts and thus delayed.

However, kvm is capable of much more than 200 packets/sec.  I get about 
6500 here with a flood ping.  Can you try this on the host:

   ping -f -q guest-ip

Hit ctrl-C after a second or two and send the output.

You can also try running wireshark on the host to capture the broadcast 
packets.  Maybe they cause some processing on the guest and slow it down.

-- 
error compiling committee.c: too many arguments to function


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

Re: Strange network behaviour

[Mike]

Avi Kivity schrieb:
> Mike wrote:
>> Sure,
>> here the ping results from the host to the guest atm of the peaks:
>> 64 bytes from postfix (195.24.77.173): icmp_seq=347 ttl=64 time=10.6 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=348 ttl=64 time=11.6 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=349 ttl=64 time=11.6 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=350 ttl=64 time=465 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=351 ttl=64 time=455 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=352 ttl=64 time=349 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=353 ttl=64 time=314 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=354 ttl=64 time=483 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=355 ttl=64 time=871 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=357 ttl=64 time=1889 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=358 ttl=64 time=1635 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=359 ttl=64 time=1973 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=360 ttl=64 time=1796 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=361 ttl=64 time=1961 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=362 ttl=64 time=2029 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=363 ttl=64 time=1994 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=364 ttl=64 time=1689 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=365 ttl=64 time=932 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=366 ttl=64 time=899 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=367 ttl=64 time=752 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=368 ttl=64 time=860 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=369 ttl=64 time=483 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=370 ttl=64 time=244 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=371 ttl=64 time=7.89 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=372 ttl=64 time=5.98 ms
>> 64 bytes from postfix (195.24.77.173): icmp_seq=373 ttl=64 time=6.31 ms
>>
>> The peaks started @ +/- 14:53:39 and ended @ +/- 14:53:59
>> You can download the trace file at:
>> http://www.eliteserver.biz/trace2.tar.gz
>>
>>
>>   
>
> The traces show that the periods of latency correspond to floods of 
> broadcast packets on the network
>
>>      10 29895 14:53:25
>>       9 29895 14:53:26
>>       9 29895 14:53:27
>>       9 29895 14:53:28
>>      16 29895 14:53:29
>>      19 29895 14:53:30
>>      19 29895 14:53:31
>>      14 29895 14:53:32
>>      13 29895 14:53:33
>>      12 29895 14:53:34
>>     205 29895 14:53:35
>>     203 29895 14:53:36
>>     276 29895 14:53:37
>>     234 29895 14:53:38
>>     234 29895 14:53:39
>>     243 29895 14:53:40
>>     234 29895 14:53:41
>>     259 29895 14:53:42
>>     228 29895 14:53:43
>>     325 29895 14:53:44
>>     242 29895 14:53:45
>>     271 29895 14:53:46
>>     251 29895 14:53:47
>>     227 29895 14:53:48
>>     178 29895 14:53:49
>>     166 29895 14:53:50
>>     271 29895 14:53:51
>>     244 29895 14:53:52
>>     287 29895 14:53:53
>>     196 29895 14:53:54
>>     215 29895 14:53:55
>>      83 29895 14:53:56
>>      65 29895 14:53:57
>>      10 29895 14:53:58
>>       9 29895 14:53:59
>>      10 29895 14:54:00
>>      14 29895 14:54:01
>>      14 29895 14:54:02
>>      12 29895 14:54:03
>>      13 29895 14:54:04
>>      16 29895 14:54:05
>
> The first column is the number of packets delivered at the time in the 
> third column.  The broadcast packets are clearly visible in the trace 
> as having \xff in the first 6 bytes of the packet.  The ping packet is 
> getting queued behind the broadcasts and thus delayed.
>
> However, kvm is capable of much more than 200 packets/sec.  I get 
> about 6500 here with a flood ping.  Can you try this on the host:
>
>   ping -f -q guest-ip
>
> Hit ctrl-C after a second or two and send the output.
>
> You can also try running wireshark on the host to capture the 
> broadcast packets.  Maybe they cause some processing on the guest and 
> slow it down.
>
9066 packets transmitted, 9055 received, 0% packet loss, time 1956ms
rtt min/avg/max/mdev = 0.078/0.171/16.659/0.181 ms, pipe 2, ipg/ewma 
0.215/0.213 ms

The same time a tried a ping over the internet. No peaks.

I also tried over a longer time, no peaks.

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

Re: Strange network behaviour

[Simon Gao]

Mike wrote:
> Avi Kivity schrieb:
>   
>> Mike wrote:
>>     
>>> Sure,
>>> here the ping results from the host to the guest atm of the peaks:
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=347 ttl=64 time=10.6 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=348 ttl=64 time=11.6 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=349 ttl=64 time=11.6 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=350 ttl=64 time=465 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=351 ttl=64 time=455 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=352 ttl=64 time=349 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=353 ttl=64 time=314 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=354 ttl=64 time=483 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=355 ttl=64 time=871 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=357 ttl=64 time=1889 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=358 ttl=64 time=1635 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=359 ttl=64 time=1973 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=360 ttl=64 time=1796 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=361 ttl=64 time=1961 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=362 ttl=64 time=2029 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=363 ttl=64 time=1994 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=364 ttl=64 time=1689 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=365 ttl=64 time=932 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=366 ttl=64 time=899 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=367 ttl=64 time=752 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=368 ttl=64 time=860 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=369 ttl=64 time=483 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=370 ttl=64 time=244 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=371 ttl=64 time=7.89 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=372 ttl=64 time=5.98 ms
>>> 64 bytes from postfix (195.24.77.173): icmp_seq=373 ttl=64 time=6.31 ms
>>>
>>> The peaks started @ +/- 14:53:39 and ended @ +/- 14:53:59
>>> You can download the trace file at:
>>> http://www.eliteserver.biz/trace2.tar.gz
>>>
>>>
>>>   
>>>       
>> The traces show that the periods of latency correspond to floods of 
>> broadcast packets on the network
>>
>>     
>>>      10 29895 14:53:25
>>>       9 29895 14:53:26
>>>       9 29895 14:53:27
>>>       9 29895 14:53:28
>>>      16 29895 14:53:29
>>>      19 29895 14:53:30
>>>      19 29895 14:53:31
>>>      14 29895 14:53:32
>>>      13 29895 14:53:33
>>>      12 29895 14:53:34
>>>     205 29895 14:53:35
>>>     203 29895 14:53:36
>>>     276 29895 14:53:37
>>>     234 29895 14:53:38
>>>     234 29895 14:53:39
>>>     243 29895 14:53:40
>>>     234 29895 14:53:41
>>>     259 29895 14:53:42
>>>     228 29895 14:53:43
>>>     325 29895 14:53:44
>>>     242 29895 14:53:45
>>>     271 29895 14:53:46
>>>     251 29895 14:53:47
>>>     227 29895 14:53:48
>>>     178 29895 14:53:49
>>>     166 29895 14:53:50
>>>     271 29895 14:53:51
>>>     244 29895 14:53:52
>>>     287 29895 14:53:53
>>>     196 29895 14:53:54
>>>     215 29895 14:53:55
>>>      83 29895 14:53:56
>>>      65 29895 14:53:57
>>>      10 29895 14:53:58
>>>       9 29895 14:53:59
>>>      10 29895 14:54:00
>>>      14 29895 14:54:01
>>>      14 29895 14:54:02
>>>      12 29895 14:54:03
>>>      13 29895 14:54:04
>>>      16 29895 14:54:05
>>>       
>> The first column is the number of packets delivered at the time in the 
>> third column.  The broadcast packets are clearly visible in the trace 
>> as having \xff in the first 6 bytes of the packet.  The ping packet is 
>> getting queued behind the broadcasts and thus delayed.
>>
>> However, kvm is capable of much more than 200 packets/sec.  I get 
>> about 6500 here with a flood ping.  Can you try this on the host:
>>
>>   ping -f -q guest-ip
>>
>> Hit ctrl-C after a second or two and send the output.
>>
>> You can also try running wireshark on the host to capture the 
>> broadcast packets.  Maybe they cause some processing on the guest and 
>> slow it down.
>>
>>     
> 9066 packets transmitted, 9055 received, 0% packet loss, time 1956ms
> rtt min/avg/max/mdev = 0.078/0.171/16.659/0.181 ms, pipe 2, ipg/ewma 
> 0.215/0.213 ms
>
> The same time a tried a ping over the internet. No peaks.
>
> I also tried over a longer time, no peaks.
>
> -------------------------------------------------------------------------
> 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
>   
I also saw the similar problem. However, it happens with I have several
KVM guests running and sharing the same network bridge. If just one
single KVM guest, then everything works fine.

Simon

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

Re: Strange network behaviour

[Lynn Kerby]

On Dec 5, 2007, at 10:05 AM, Simon Gao wrote:
> I also saw the similar problem. However, it happens with I have  
> several
> KVM guests running and sharing the same network bridge. If just one
> single KVM guest, then everything works fine.
>
> Simon

I think I've been through similar problems as well.

Initially my guests would experience massive packet losses and huge  
delays somtime shortly after the second guest started.  Often the  
first guest continued to operate fairly well, but it was noticably  
degraded.  That is when I switched from the default QEMU ne2k device  
to the rtl8139 for all my virtual network taps.

A bunch of debugging eventually led me to check the mac addresses of  
all my guests on the bridge.  Not the host side TAP address, but the  
guest's mac address.  In my environment I found cases where more than  
one of the guests on the bridge had the same mac address and rewrote  
my startup scripts and configs to always assign a unique mac address  
to each network device.

I thought perhaps this may be related to something in KVM-55, but  
I've just shutdown and restarted my VMs on the KVM-55 modules and  
userspace and am not seeing any network problems with my VMs.

Here are the kvm/qemu command lines for 3 of my machines: (2  
FreeBSD-6.2 servers and a Ubuntu-7.10 server)
> /usr/local/bin/qemu-system-x86_64 -name FreeBSD_6.2 -hda /vm_img/ 
> bsd_dz1/disk0.qcow -m 256 -boot c -smp 1 -usb -usbdevice tablet - 
> vnc :0 -serial telnet::4100,server,nowait -monitor telnet:: 
> 4200,server,nowait -net  
> nic,vlan=0,macaddr=52:54:00:12:34:56,model=rtl8139 -net  
> tap,vlan=0,ifname=tap0,script=/etc/kvm/kvm-ifup -net  
> nic,vlan=1,model=rtl8139 -net tap,vlan=1,ifname=dmz0,script=/etc/ 
> kvm/kvm-ifup

> /usr/local/bin/qemu-system-x86_64 -name DOM9-BSD62 -hda /vm_img/ 
> bsd_in1/dom9-disk1.qcow -hdb /vm_img/bsd_in1/dom9-disk2.raw -m 512 - 
> boot c -smp 2 -usb -usbdevice tablet -vnc :9 -serial telnet:: 
> 4109,server,nowait -monitor telnet::4209,server,nowait -net  
> nic,vlan=0,macaddr=52:54:09:12:34:56,model=rtl8139 -net  
> tap,vlan=0,ifname=tap1,script=/etc/kvm/kvm-ifup

> /usr/local/bin/qemu-system-x86_64 -name DOMT2-UbuSrv7.10 -hda /dev/ 
> vg_r5/dom_t2 -m 512 -boot c -smp 1 -vnc :8 -serial telnet:: 
> 4108,server,nowait -monitor telnet::4208,server,nowait -net  
> nic,vlan=0,macaddr=52:54:08:12:34:56,model=rtl8139 -net  
> tap,vlan=0,ifname=tap2,script=/etc/kvm/kvm-ifup

The kvm-ifup script referenced in these commands is very similar to  
the standard qemu-ifup except that it deals with multiple bridges,  
based on the interface name.  It may be worth noting that I'm not  
explicitly assigning a mac address to interface dmz0 in the first  
example, but other interfaces on that network all have unique mac  
addresses so it isn't critical.

You might want to examine the output of 'brctl showmacs br0' (use  
your bridge name in place of br0) and also check the interface stats  
on the bridge and any troublesome tap interfaces.

Lynn Kerby
San Martin, CA

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