libvirt users - Oct 2015 - How can I set the advertised value of MTU for virbr0 interface?

Hi all, 
 
I want to set the advertised value of MTU 
for virbr0 interface on a Fedora 21 host to 1454 
to accommodate the installation of new VMs for testing purposes. 
The aforementioned host is an OpenStack VM actually, 
which explains the need for a lower than 1500 MTU. 
 
I noticed Pieter Hollants' patch to set 
dhcp-option=<number>,"<value>" for an interface, 
but it seems that it has not been implemented yet. 
 
Is there a possibility to have such an option? 
 
George

On 15.10.2015 20:23, George Trakatelis wrote:
> Hi all, 
>  
> I want to set the advertised value of MTU 
> for virbr0 interface on a Fedora 21 host to 1454 
> to accommodate the installation of new VMs for testing purposes. 
> The aforementioned host is an OpenStack VM actually, 
> which explains the need for a lower than 1500 MTU. 
>  
> I noticed Pieter Hollants' patch to set 
> dhcp-option=<number>,"<value>" for an interface, 
> but it seems that it has not been implemented yet. 
The patch is in:

Author:     Pieter Hollants <pieter@hollants.com>
AuthorDate: Thu Feb 21 23:40:17 2013 +0100
Commit:     Laine Stump <laine@laine.org>
CommitDate: Fri Feb 22 19:45:19 2013 -0500

    Add support for <option> tag in network config
    
    This patch adds support for a new <option>-Tag in the <dhcp>
block of
    network configs, based on a subset of the fifth proposal by Laine
    Stump in the mailing list discussion at
    https://www.redhat.com/archives/libvir-list/2012-November/msg01054.html.
    Any such defined option will result in a
dhcp-option=<number>,"<value>"
    statement in the generated dnsmasq configuration file.
    
    Currently, DHCP options can be specified by number only and there is
    no whitelisting or blacklisting of option numbers, which should
    probably be added.
    
    Signed-off-by: Pieter Hollants <pieter@hollants.com>
    Signed-off-by: Laine Stump <laine@laine.org>


But I don't think it will solve your problem. IIUC you want to modify MTU of
virbr0 not just advertise altered MTU to domains.

Does this virbr0 come from the default libvirt network? If so, I am afraid
there's no way how to specify MTU. What you could do, is to define
<interface/> [1] and then bridged <network/> [2] that will use the
interface.
Libvirt already has support for setting MTUs for host interfaces.

Michal

1:
http://libvirt.org/git/?p=libvirt.git;a=blob;f=tests/interfaceschemadata/bridge.xml;h=ece087ea2ef5e3a85fd708ff44286acb15680a64;hb=HEAD

2: http://libvirt.org/formatnetwork.html#examples

P.S.: I must ashamedly admit that we don't have any documentation for
<interface/>, sorry.

Michal, 

Thank you for your response. Please accept my clarifications below.
> On 15.10.2015 20:23, George Trakatelis wrote:
> > Hi all,
> >
> > I want to set the advertised value of MTU for virbr0 interface on a
> > Fedora 21 host to 1454 to accommodate the installation of new VMs for
> > testing purposes.
> > The aforementioned host is an OpenStack VM actually, which explains
> > the need for a lower than 1500 MTU.
> >
> > I noticed Pieter Hollants' patch to set
dhcp-option=<number>,"<value>"
> > for an interface, but it seems that it has not been implemented yet.
I should have written (for the patch) "that it has not been applied
yet".

Digging further, I realized that it has been applied but pulled before 1.0.3

for a number of reasons as explained by Laine Stump  
http://www.redhat.com/archives/libvir-list/2013-March/msg00166.html
> The patch is in:
> 
> Author:     Pieter Hollants <pieter@hollants.com>
> AuthorDate: Thu Feb 21 23:40:17 2013 +0100
> Commit:     Laine Stump <laine@laine.org>
> CommitDate: Fri Feb 22 19:45:19 2013 -0500
> 
>     Add support for <option> tag in network config
> 
>     This patch adds support for a new <option>-Tag in the
<dhcp> block of
>     network configs, based on a subset of the fifth proposal by Laine
>     Stump in the mailing list discussion at
>
https://www.redhat.com/archives/libvir-list/2012-November/msg01054.html.
> 
>     [...]
> 
> But I don't think it will solve your problem. IIUC you want to modify
> MTU of virbr0, not just advertise altered MTU to domains.
Well, in my case (which I briefly described earlier), 
having dhcp-option=26,1454 or dhcp-option-force=26,1454 
in /var/lib/libvirt/dnsmasq/default.conf does the trick. 
> Does this virbr0 come from the default libvirt network?
> If so, I am afraid there's no way how to specify MTU. 
> What you could do, is to define <interface/> [1] 
> and then bridged <network/> [2] that will use the interface.
> Libvirt already has support for setting MTUs for host interfaces. 
> 
> Michal
I'll try that! For the time being, I applied a mini version of the patch. 

George

On 10/22/2015 10:57 AM, Michal Privoznik wrote:
> On 15.10.2015 20:23, George Trakatelis wrote:
>> Hi all,
>>   
>> I want to set the advertised value of MTU
>> for virbr0 interface on a Fedora 21 host to 1454
>> to accommodate the installation of new VMs for testing purposes.
>> The aforementioned host is an OpenStack VM actually,
>> which explains the need for a lower than 1500 MTU.
>>   
>> I noticed Pieter Hollants' patch to set
>> dhcp-option=<number>,"<value>" for an interface,
>> but it seems that it has not been implemented yet.
> The patch is in:
>
> Author:     Pieter Hollants <pieter@hollants.com>
> AuthorDate: Thu Feb 21 23:40:17 2013 +0100
> Commit:     Laine Stump <laine@laine.org>
> CommitDate: Fri Feb 22 19:45:19 2013 -0500
>
>      Add support for <option> tag in network config
As you've found, that was reverted before it was ever in a release. 
After initially approving it, I realized that the free-form format of 
the option values was doomed to create problems in the future, and that 
we had to come up with a more robust syntax (essentially libvirt needed 
to know the datatype of each option value, rather than just accepting an 
opaque string and passing it on to the dhcp server).

>      
>      This patch adds support for a new <option>-Tag in the
<dhcp> block of
>      network configs, based on a subset of the fifth proposal by Laine
>      Stump in the mailing list discussion at
>     
https://www.redhat.com/archives/libvir-list/2012-November/msg01054.html.
>      Any such defined option will result in a
dhcp-option=<number>,"<value>"
>      statement in the generated dnsmasq configuration file.
>      
>      Currently, DHCP options can be specified by number only and there is
>      no whitelisting or blacklisting of option numbers, which should
>      probably be added.
>      
>      Signed-off-by: Pieter Hollants <pieter@hollants.com>
>      Signed-off-by: Laine Stump <laine@laine.org>
>
>
> But I don't think it will solve your problem. IIUC you want to modify
MTU of virbr0 not just advertise altered MTU to domains.
>
> Does this virbr0 come from the default libvirt network? If so, I am afraid
there's no way how to specify MTU. What you could do, is to define
<interface/> [1] and then bridged <network/> [2] that will use the
interface.
> Libvirt already has support for setting MTUs for host interfaces.
It really surprised me a month or two ago when someone asked about this 
on IRC and I found that we didn't support setting the MTU in a libvirt 
virtual network. Due to MTU being supported in host interface config, I 
had just always assumed in the back of my mind that it was there for 
networks as well, but never needed it and so never paid close attention.

But when it was pointed out it was missing, my first suspicion was that 
there must be some reason it wasn't done (since it's so simple).

And then (as usual) I went back to whatever I was working on and forgot 
about it :-/

It makes sense to me that the <bridge> element should have an attribute 
called "mtu" (this is a case where I think we shouldn't try to use
exactly the same config as host interfaces, since they have a separate 
<mtu size='blah'/> element so that it can be used with any type of
interface). So it would look something like this:

     <bridge name='virbr0' mtu='9000' stp='on'
delay='0'/>

If someone feels like implementing this that would be great. If not, 
it's on my list and may get implemented "someday".