What is asked here of libvirt is an option to
run qemu-kvm with sndbuf=0.

With the default value (1M), given a sufficient number
of unresponsive guests on the same host, and assuming
a given guest tries to communicate to all of them,
all communication from a specific guest slows down
and then stops completely.
The bigger the buffer value, the less the risk of this.

sndbuf=0 is actually equivalent to 0xffffffff.

The disadvantage is that with large buffer values
UDP applications that
do not do any flow control in software will
get large packet drop rates for guest to guest
traffic on a local machine.

Providing an option to set the sndbuf parameter is reasonable.

I can add this in the same manner (and at the same time) as I will use to add the vhost on|off switch (Bug 643050). There is currently a discussion upstream on what the XML should look like:

https://www.redhat.com/archives/libvir-list/2011-January/msg00092.html

sndbuf would be added either as another attribute to <driver> (or whatever the element is called), or as a subelement (ie, either <driver sndbuf='0' .../> or <driver><sndbuf>0</sndbuf>...</driver>

Patch to add this has been posted upstream:

https://www.redhat.com/archives/libvir-list/2011-January/msg00522.html

The XML will look like this:


    <domain>
      ...
      <interface ... >
        ...
        <tune>
          <sndbuf>0</sndbuf>
        </tune>
        ...
      </interface>
      ...
    </domain>

An updated version of the above patch has been committed to upstream libvirt, and posted to rhvirt-patches for inclusion in the RHEL build of libvirt. Note that this patch also requires application of the 2nd patch listed in this comment:


commit fe053dbea761573c96617b01f41f1fd3e50b1330
Author: Laine Stump <laine>
Date:   Wed Jan 12 14:38:01 2011 -0500

    Enable tuning of qemu network tap device "sndbuf" size
    
    This is in response to a request in:
    
       https://bugzilla.redhat.com/show_bug.cgi?id=665293
    
    In short, under heavy load, it's possible for qemu's networking to
    lock up due to the tap device's default 1MB sndbuf being
    inadequate. adding "sndbuf=0" to the qemu commandline -netdevice
    option will alleviate this problem (sndbuf=0 actually sets it to
    0xffffffff).
    
    Because we must be able to explicitly specify "0" as a value, the
    standard practice of "0 means not specified" won't work here. Instead,
    virDomainNetDef also has a sndbuf_specified, which defaults to 0, but
    is set to 1 if some value was given.
    
    The sndbuf value is put inside a <tune> element of each <interface> in
    the domain. The intent is that further tunable settings will also be
    placed inside this element.
    
         <interface type='network'>
           ...
           <tune>
             <sndbuf>0</sndbuf>
           ...
           </tune>
         </interface>

commit 1ff03b28e938dd0cbde076aa0875f46d0ce52d30
Author: Eric Blake <eblake>
Date:   Thu Jan 13 15:09:18 2011 -0700

    util: add missing string->integer conversion functions
    
    It was awkward having only int conversion in the virStrToLong family,
    but only long conversion in the virXPath family.  Make both families
    support both types.
    
    * src/util/util.h (virStrToLong_l, virStrToLong_ul): New
    prototypes.
    * src/util/xml.h (virXPathInt, virXPathUInt): Likewise.
    * src/util/util.c (virStrToLong_l, virStrToLong_ul): New
    functions.
    * src/util/xml.c (virXPathInt, virXPathUInt): Likewise.
    * src/libvirt_private.syms (util.h, xml.h): Export them.

Verified it on RHEL6 server with the following components:
libvirt-0.8.7-2.el6
qemu-kvm-0.12.1.2-2.129.el6
kernel-2.6.32-94.el6

The steps are as follows:
1 install a guest named rhel6

2 shutdown the guest and add the following xml into interface element:
<tune>
       <sndbuf>0</sndbuf>
</tune>

3 start the guest and check qemu -netdevice option
# ps -edf |grep qemu
qemu     19001     1  6 15:03 ?        00:01:16 /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name rhel6 -uuid 816605ff-d6b2-db24-57a1-bf872f4c40d5 -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/rhel6.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/rhel6-1.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,fd=24,id=hostnet0,sndbuf=0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:1e:8e:ab,bus=pci.0,addr=0x3 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

4 shutdown the guest and add the following xml into interface element:
<tune>
       <sndbuf>1000</sndbuf>
</tune>

5 start the guest and check qemu -netdevice option
# ps -ef|grep qemu
qemu     24016     1 29 16:15 ?        00:00:20 /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name rhel6 -uuid 816605ff-d6b2-db24-57a1-bf872f4c40d5 -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/rhel6.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/rhel6-1.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,fd=24,id=hostnet0,sndbuf=1000 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:1e:8e:ab,bus=pci.0,addr=0x3 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0596.html