What you do in the VMs does not impact the hosts, so I didn't speak to
that. Having the bridge, interfaces, switches and vnets at 9000 (for
example) doesn't immediately enable large frames in the virtual servers.
It simply means that all of the links between the VM and other devices
on the network are ready for JFs.

Imagine this;

{real switch}
|
{ethX + ethY}
|
{bondX}
|
{vbr0}
|
{vnetX}
|
{VM's eth0}

All of these devices need to have their MTU set to your desires value.
If any one of these is still 1500, then only standard frames will be
able to traverse them.

* real switch; Log into it and make sure jumbo frames are enabled

* ethX + ethY; If you are using bonding, be sure both/all slaved
interfaces are set to use a large frame.

* bondX; Again if you use a bond, make sure the bondX interface has a
large frame.

* vbr0; The bridge can not be set to a specific MTU size. It will use
the lowest MTU of the various devices / interfaces connected to it.

* vnetX; These are the "virtual network cables" that are used to "plug
in" a VM's interface to the bridge. This is not new by any means. In the
real world, network cables don't have setable MTUs of course. In the
virtual world though, they do. These interfaces are spontaneously
created and destroyed as VMs come and go. This is what the udev rule is
for because these "virtual network cables" don't have traditional
ifcfg-X files.

* VM's eth0; This is the (emulated) network card in your virtual server.
If you told the hypervisor to replicate an e1000 intel card or use the
virtio-net driver, you can set a large MTU. However, if you used
something like an emulated realtek card, those don't support jumbo
frames, so their emulated counterparts will not support large frames either.

hth

digimer

On 21/11/13 13:32, Nico Kadel-Garcia wrote:

I was under the impression that the relevant MTU settings were on the

*node's* local ifcfg-eth* configurations. Did something change with

KVM internal networking in the last year?

On Thu, Nov 21, 2013 at 1:03 PM, Digimer <lists@alteeve.ca> wrote:

The problem is that there are no ifcfg-vnetX config files. They are

dynamically created as VMs are created or migrated to a node. You could

manually (or via script) change the MTU, but that would mean that the

MTU on the bridge would drop momentarily when new VMs start. This could

break network traffic for any existing VMs (or real devices) using large

frames.

I'm not a fan of udev either, but in this case, it is the best option.

Of course, I am certainly open to hearing alternative methods if they exist.

On 21/11/13 08:39, Nico Kadel-Garcia wrote:

Stay out of udev if you can. It's often overwritten by component

addition and manipulation MTU is parsed, and overridden, by options in

/etc/sysconfig/network-scripts/ifcfg-[device]. I find it much safer to

read and manage there, and if new devices are added or replaced, the

behavior is dominated by the "HWADDR" associated config files there,

no matter what "udev" thinks the device number or name should be..

<snip>

Another update;

 To make sure the VMs' vnetX devices are created with a larger MTU, you

*sill* need to update udev[1].

 Append to /etc/udev/rules.d/70-persistent-net.rules;

====

# Make all VMs' vnetX devices come up with an MTU of 9000.

SUBSYSTEM=="net", ACTION=="add", KERNEL=="vnet*", ATTR{mtu}="9000"

====

 Assuming you find that you can use an MTU of '9000', of course. No

need to reboot or even restart networking. Just add that line and then

provision/boot your VMs. If the VMs are already running, you can adjust

the MTU of the existing 'vnetX' devices with:

ifconfig vnetX mtu 9000

Cheers!

PS - Credit for the udev rule:

http://linuxaleph.blogspot.ca/2013/01/how-to-network-jumbo-frames-to-kvm-guest.html

--

Digimer