KVM 게스트와 호스트 사이의 점보 프레임?


11

KVM 게스트와 호스트 시스템 간의 스토리지 통신을 위해 9000 바이트 MTU를 구현하려고합니다. 호스트에는 br19000 바이트 MTU 가있는 브리지 ( )가 있습니다.

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

게스트에는이 브리지에 연결된 인터페이스가 있으며 9000 바이트 MTU도 있습니다.

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

호스트에서 게스트로 핑할 수 있습니다.

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

그러나 핑 패킷 크기를 1490 바이트 이상으로 늘리면 더 이상 연결이 없습니다.

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

패킷 추적은 이러한 패킷이 게스트에 도달하지 않았 음을 나타냅니다. 내가 읽은 모든 것은 Linux 브리지 인터페이스와 virtio네트워크 드라이브가 모두 점보 프레임을 지원 한다는 것을 나타냅니다 . 그러나 이것은 MTU 문제처럼 보입니다.

내가 정말로 명백한 것을 놓치고 있습니까?

최신 정보

게스트 인터페이스의 호스트 측 표시 :

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

호스트의 VM에 대한 tun 인터페이스의 MTU는 무엇입니까?
— mgorven December

또한 9000 바이트입니다. 나는의 출력과 질문을 업데이 트했습니다 brctl및 ip addr show해당 인터페이스에 대해.
— Larsks

정확히 호스트 시스템은 무엇입니까?
— Michael Hampton

Linux 3.6.10 (x86_64), qemu-kvm 1.2.0, libvirt 1.0.1이 설치된 Arch Linux
— Larsks

답변:


7

이것은 MTU 문제이지만 구성 요소 장치의 MTU 설정과 관련이 없음이 밝혀졌습니다. 원래 질문에서 알 수 있듯이 호스트 브리지, 호스트 툰 인터페이스 및 게스트 인터페이스는 모두 동일한 MTU 설정 (9000 바이트)을 가졌습니다.

실제 문제는 libvirt / kvm 구성 문제였습니다. 기본적으로 libvirt는 장치를 사용 하지 않습니다virtio . 명시적인 구성이 없으면 RealTek RTL-8139 NIC가 사용됩니다. 이 가상 NIC 는 점보 프레임을 지원하지 않습니다 .

virtio장치 를 사용하려면 명시 적 모델을 지정해야합니다. 사용시 virt-install:

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

또는 도메인 XML <model>의 적절한 <interface>요소에 태그를 추가하여 사실 후에 :

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

이 변경으로 모든 것이 의도 한대로 작동합니다.


0

더 큰 MTU가 작동하려면 전체 스택에 더 높은 MTU가 있어야합니다. 여기에는 게스트, tapdev 및 브리지가 연결된 물리적 NIC가 포함됩니다 (본드 및 VLAN이있는 경우에도 해당)


GigaEthernet과 같은 특정 사례가 자동 협상의 결과 인 곳을 알고 있습니까? 이 게시물은 중복 될 수 있습니다 : google.com/…
— ArrowInTree

아니, 특정 구성 요소의 가장 높은 MTU를 수동으로 모든 스택 설정을 수행해야합니다
— dyasny

그렇습니다. 그것은 모든 곳에서 잘 문서화되어 있습니다. 이 질문에서 알 수 있듯이 손님, tapdevs 및 다리는 모두 MTU가 높습니다. 내가 제시 한 예제에서 잘못 구성된 것이 있습니까?
— larsks

기본이 아닌 MTU 설정을 사용하려면 모든 것이 기본이 아닌 MTU를 준수해야합니다. 즉, 위에서 아래로 게스트 NIC, 탭, 브리지, 브리지 아래 eth (+ vlan + bond) 및 물론 스위치 포트 여야합니다. 몇 분 전에 테스트했으며 kvm을 사용하여 RHEL에서 완벽하게 작동합니다.
— dyasny

맞습니다. 저는 질문에서 스택의 모든 부분에서의 가치를 분명히 보여주었습니다. 누락 된 정보 나 올바르게 구성되지 않은 것이 있습니까?
— Larsks
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.