Frame Jumbo tra guest KVM e host?

Sto cercando di implementare un MTU da 9000 byte per la comunicazione di archiviazione tra guest KVM e il sistema host. L'host ha un bridge ( br1) con un MTU a 9000 byte:

host# ip link show br1
8: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP 
    link/ether fe:54:00:50:f3:55 brd ff:ff:ff:ff:ff:ff
    inet 172.16.64.1/24 brd 172.16.64.255 scope global br1
    inet6 fe80::21b:21ff:fe0e:ee39/64 scope link 
       valid_lft forever preferred_lft forever

Gli ospiti hanno un'interfaccia collegata a questo bridge che ha anche un MTU da 9000 byte:

guest# ip addr show eth2
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:50:f3:55 brd ff:ff:ff:ff:ff:ff
    inet 172.16.64.10/24 brd 172.16.64.255 scope global eth2
    inet6 fe80::5054:ff:fe50:f355/64 scope link 
       valid_lft forever preferred_lft forever

Posso eseguire il ping dall'host all'ospite:

host# ping -c4 172.16.64.10
PING 172.16.64.10 (172.16.64.10) 56(84) bytes of data.
64 bytes from 172.16.64.10: icmp_seq=1 ttl=64 time=1.15 ms
64 bytes from 172.16.64.10: icmp_seq=2 ttl=64 time=0.558 ms
64 bytes from 172.16.64.10: icmp_seq=3 ttl=64 time=0.566 ms
64 bytes from 172.16.64.10: icmp_seq=4 ttl=64 time=0.631 ms

--- 172.16.64.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.558/0.727/1.153/0.247 ms

Ma se aumento la dimensione del pacchetto ping oltre i 1490 byte, non ho più la connettività:

host# ping -c4 -s 1491 172.16.64.10
PING 172.16.64.10 (172.16.64.10) 1491(1519) bytes of data.

--- 172.16.64.10 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3000ms

Una traccia di pacchetto mostra che questi pacchetti non raggiungono mai l'ospite. Tutto quello che ho letto indica che sia l'interfaccia bridge Linux che le virtiounità di rete supportano tutti i frame jumbo, ma questo sicuramente mi sembra un problema MTU.

Mi sto perdendo qualcosa di veramente ovvio?

Aggiornare

Mostra il lato host dell'interfaccia guest:

host# brctl show
bridge name bridge id       STP enabled interfaces
br1     8000.fe540050f355   no      vnet2

host# ip addr show vnet2
11: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast master br1 state UNKNOWN qlen 500
    link/ether fe:54:00:50:f3:55 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe50:f355/64 scope link 
       valid_lft forever preferred_lft forever

Mentre questo era un problema MTU, si scopre che non aveva nulla a che fare con le impostazioni MTU su nessuno dei dispositivi componenti. Come ho mostrato nella domanda originale, il bridge host, l'interfaccia host tun e l'interfaccia guest avevano tutte la stessa impostazione MTU (9000 byte).

Il vero problema era un problema di configurazione di libvirt / kvm. Per impostazione predefinita, libvirt non utilizza i virtiodispositivi. In assenza di una configurazione esplicita si finisce con una scheda NIC RealTek RTL-8139. Questa scheda di rete virtuale non supporta i frame jumbo .

Per utilizzare i virtiodispositivi, è necessario specificare un modello esplicito. Quando si utilizza virt-install:

virt-install ... -w bridge=br1,model=virtio

O dopo il fatto aggiungendo un <model>tag <interface>all'elemento appropriato nel dominio XML:

<interface type="bridge">
  <model type="virtio"/>
  <source bridge="br1"/>
  <target dev="vnet2"/>
</interface>

Con questo cambiamento in atto, tutto funziona come previsto.

affinché MTU più grande funzioni, l'intero stack deve avere l'MTU più alto, che include gli ospiti, i tapdev e le schede NIC fisiche a cui è collegato il bridge (se si hanno obbligazioni e vlan lungo la strada - anche loro)