From: Li RongQing
Date: Thu, 25 Feb 2016 09:50:41 +0800
> On Thu, Feb 25, 2016 at 5:44 AM, Stephen Hemminger
> wrote:
>>> This is especially annoying for the virtualization case because the
>>> KVM's tap driver will by default adopt the bridge's MTU on startup
>>> making it impossible (without t
On Thu, Feb 25, 2016 at 5:44 AM, Stephen Hemminger
wrote:
>> This is especially annoying for the virtualization case because the
>> KVM's tap driver will by default adopt the bridge's MTU on startup
>> making it impossible (without the workaround) to use a large MTU on the
>> guest VMs.
>>
>> http
On Tue, 23 Feb 2016 09:00:56 +0800
roy.qing...@gmail.com wrote:
> This is especially annoying for the virtualization case because the
> KVM's tap driver will by default adopt the bridge's MTU on startup
> making it impossible (without the workaround) to use a large MTU on the
> guest VMs.
>
> htt
From: roy.qing...@gmail.com
Date: Tue, 23 Feb 2016 09:00:56 +0800
> This is especially annoying for the virtualization case because the
> KVM's tap driver will by default adopt the bridge's MTU on startup
> making it impossible (without the workaround) to use a large MTU on the
> guest VMs.
So if
From: Li RongQing
A linux bridge always adopts the smallest MTU of the enslaved devices.
When no device are enslaved, it defaults to a MTU of 1500 and refuses to
use a larger one. This is problematic when using bridges enslaving only
virtual NICs (vnetX) like it's common with KVM guests.
Steps t
