qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] [Fwd: qemu tx stop in cloonix]


From: clownix
Subject: [Qemu-devel] [Fwd: qemu tx stop in cloonix]
Date: Sun, 24 Feb 2013 14:14:43 -0600
User-agent: SquirrelMail/1.4.22

Hello,
I use qemu inside a gplv3 software called cloonix, I have patched qemu to
have unix sockets instead of inet ones but the bug I have with unix
sockets may also happen with inet ones.

The bug can be reproduced in cloonix context by using iperf, it occurs
randomly in a virtual cloonix network but occurs within seconds using
iperf in nested virtualisation (cloonix inside cloonix), the problem
begins when a lot of packets must be transmitted and the socket (inet in
the classical qemu, unix in cloonix) gets full and
qemu_net_queue_append_iov is called, then tx never restarts.

See under in the patch attached, the way I avoided queuing anything, it
works, even if it is not a correction to the bug...

The patch is for version 21.3 of cloonix which uses qemu-1.4.0-rc1, but
I now use qemu-1.4.0 and the bug is still there.

Regards
Vincent Perrier



---------------------------- Original Message ----------------------------
Subject: qemu tx stop in cloonix
From:    address@hidden
Date:    Sun, February 24, 2013 9:14 am
To:      "list" <address@hidden>
--------------------------------------------------------------------------

There is a bug visible more particularly when doing nested cloonix and
iperf inside the second level nested machines.
The ethernet interface emitting a big load stops working, this has been
corrected in my version but I will not deliver the correction outside the
regular deliveries (every 2 or 3 months).

If you have a stopping of your ethernet access after a burst of traffic,
here is the cause:

>From the kernel virtio_net driver inside the guest, piles of messages are
sent into a virtio queue to the qemu user process.
The qemu user process does what it can to give the messages to a unix
socket (to cloonix). When too much traffic arrives, the unix socket writes
0 bytes as it gets full.
Then qemu, instead of droping packet (too much is too much, no need to try
harder) qemu does not want to drop, it tries to enqueue packets until the
unix socket clears...

The mechanics of this unusual case management is too complex, I did not
get into it to repair it, I just dropped the packets, simplest solution,
and the above layers know low level packets can just disapear...

Here is the solution:
in "sources/Cloonix-Net-Lab/qemu", in file cmd, add the following
qemu_drop_burst.patch line after having put the qemu_drop_burst.patch in
the qemu directory.

  patch -p1 < ../cloonix_qemu.patch
  patch -p1 < ../qemu_drop_burst.patch


The qemu_drop_burst.patch should be with this mail...

Attachment: qemu_drop_burst.patch
Description: Text Data


reply via email to

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