Re: [Qemu-stable] connectivity problem with Windows 7 + heavy network-traffic

[Oliver Francke]

Well,

not to get me wrong, the _guest_ is a windows-VM, host is linux with 
ubuntu-12.04 LTS.

A further test with replacing sources from qemu-1.2.0/net.c and 
qemu-1.2.0/net/*
to qemu-1.2.1 and recompile is ending with a stable VM with the RTL8139 
card.

So, my guess is, that perhaps some new func like 
'qemu_flush_queued_packets' has
just not make it into the corresponding rtl-source?
For some reason it breaks a windows VM, not anyone with Linux.

A test with qemu-1.5.0-rc2 with an e1000 as network-driver is 
rock-stable, though I would
be stuck with some overhead to establish traffic-control on the 
tap-interface not to saturate
a 1GE link of the node ;)

This workaround could do the trick, but a _real_ fix would be much 
appreciated... No-one?

Reg's,

Oliver.

On 05/13/2013 04:01 PM, Oliver Francke wrote:
> Hi,
>
> even if it's not really a "narrowing down", but at least my testing 
> shows, there happened something
> between 1.2.0 and 1.2.1 onwards, that is: even 1.2.1 breaks.
>
> Any chance to help me into debugging? I know it's windows, but... ;)
>
> Kind regards,
>
> Oliver.
>
> On 05/08/2013 10:04 AM, Oliver Francke wrote:
> > Hi,
> >
> > I have a couple of reports vom people, where the network-link goes down.
> > I did some live-migration, and the RTL8139 card was connected again, 
> > up to the next traffic-burst.
> > ( just cmd, one ftp download + two uploads parallel... let it run for 
> > couple of minutes until drop...)
> >
> > No way within windows to recover the card except reboot.
> >
> > All is fine with qem-1.2.0, I have no problem to make some exceptions 
> > for these VM's, but cool would
> > be some possibility to narrow down the problem, which is there in 
> > qemu-1.3.x up to 1.5.0-rc0.
> >
> > The host is for example an AMD opteron 6172 ( 24 cores).
> > Switch is openvswitch-1.9.x, nothing special.
> >
> > Here my call to qemu:
> >
> > /usr/local/qemu-1.5.0/bin/qemu-system-x86_64 -usbdevice tablet 
> > -enable-kvm -daemonize -pidfile /var/run/qemu-server/761.pid -monitor 
> > unix:/var/run/qemu-server/761.mon,server,nowait -vnc 
> > unix:/var/run/qemu-server/761.vnc,password -qmp 
> > unix:/var/run/qemu-server/761.qmp,server,nowait -nodefaults -serial 
> > none -parallel none -device 
> > rtl8139,mac=00:F1:70:00:2F:90,netdev=vlan0d0 -netdev 
> > type=tap,id=vlan0d0,ifname=tap761i0d0,script=/etc/fcms/add_if.sh,downscript=/etc/fcms/downscript.sh 
> > -name 1155823384-4 -m 2048 -vga cirrus -k de -smp sockets=1,cores=2 
> > -device virtio-blk-pci,drive=virtio0 -drive 
> > format=raw,file=rbd:1155823384/vm-761-disk-1.rbd:rbd_cache=false,cache=writeback,if=none,id=virtio0,media=disk,index=0 
> > -drive 
> > format=raw,file=rbd:1155823384/vm-761-swap-1.rbd:rbd_cache=false,cache=writeback,if=virtio,media=disk,index=1 
> > -drive if=ide,media=cdrom,id=ide1-cd0 -drive 
> > if=ide,media=cdrom,id=ide1-cd1 -rtc base=localtime -no-hpet -boot 
> > order=dc
> >
> > No problems whatsoever with all Linux-distros ( running hundreds of 
> > them). I left out the -rtc and -no-hpet, not any better.
> >
> > Any comments and help welcome,
> >
> > Oliver.


--

Oliver Francke

filoo GmbH
Moltkestraße 25a
33330 Gütersloh
HRB4355 AG Gütersloh

Geschäftsführer: S.Grewing | J.Rehpöhler | C.Kunz

Folgen Sie uns auf Twitter: http://twitter.com/filoogmbh