Bug 809172

Summary:	Feature Request: Implement the ability to be able to tune vnetX devices tunables such as txqueuelen
Product:	[Community] Virtualization Tools	Reporter:	Tim Hughes <thughes>
Component:	libvirt	Assignee:	Michal Privoznik <mprivozn>
Status:	CLOSED DEFERRED	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	crobinso, rbalakri, uboscolo, xen-maint
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-12-31 11:32:47 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tim Hughes 2012-04-02 16:38:59 UTC

Feature Request:

setting the txqueuelen on vnetX devices to 2500 we can increase the network throughput by a factor of almost 10. On an eth device it can be set by  hand/rc.local with the following instructions http://www.cyberciti.biz/faq/gentoo-centos-rhel-debian-fedora-increasing-txqueuelen/  .  Because vnetX devices are named on a 'first free' basis and they come and go with the guests, the rc.local method is not going to work. 

Ideally I would like to be able to set this automatically for all vnetX devices when they are created or even better, on a per guest basis.

Comment 1 Tim Hughes 2013-02-01 01:08:10 UTC

http://www.thegoldfish.org/2012/04/set-txqueuelen-on-virtual-vnetx-devices-with-libvirt/

Comment 2 Umberto Boscolo 2014-03-31 14:16:25 UTC

the proposed solution works fine, but I guess all the VMs/vnets will have the same txqueuelen as configured in /etc/udev/...? 
What happens if I want to customize different VMs/vnet with different txqueuelen. 

The proper solution would be to be able to specify the txquelen in the xml description instead on a per vnet basis

Is there still an interest in this enhancement?

Comment 3 Tim Hughes 2014-12-31 11:26:08 UTC

We have dropped virtualization for all our production systems. The solution above works for us in because we use puppet to manage it on any system that requires it so unless anyone else is after the feature then I would put it at the bottom of the list or drop it.

Comment 4 Michal Privoznik 2014-12-31 11:32:47 UTC

Okay, closing per comment 3. If anybody find out that they need this, please feel free to reopen.