Linux-bridge ohne physischen Port mit 10MBit/s Link Speed

Dec 6, 2019
2
0
6
Hallo,

ich habe auf einem PVE-Node eine Linux-bridge eingerichtet, die nur für Netzwerkverkehr zwischen VMs vorgesehen ist, also kein physisches Interface des Nodes enthält, sonder nur tap-Devices. Unter /sys/class/net/vmbr100/speed wird nun eine Geschwindigkeit von 10 gemeldet. Diese Meldung bringt leider unser Monitoring durcheinander, da damit quasi immer volle Last am Bridge-Interface anliegt. Bei Bridges mit physischem Port wird dessen Geschwindigkeit übernommen, die tap-Devices haben aber keinen gültigen /sys/class/net/<interface>/speed Wert (-1). Ich würde erwarten, dass auch die Bridge dazu keinen gültigen Wert hat, worauf das Monitoring reagieren kann. Aber so führt das leider zu einer Menge Fehler.
Hat jemand eine Idee was ich ändern kann?
 
Guten Morgen,

ich habe leider keine Lösung für dich. Allerdings sitze ich im selben Boot, wie ich gestern festgestellt habe. Hattest du eine Lösung gefunden? (Ansonsten stelle ich das Problem nochmal im englischsprachigen Bereich vor...)

Viele Grüße
 
Ja, danke.
Ich habe den Bug 'reopened' weil der dort beschriebene Workaround das Problem (für mich) nicht löst.
Und ich hatte das Problem im englischen Bereich nochmals beschrieben: https://forum.proxmox.com/threads/how-can-i-specifiy-a-nominal-speed-of-a-kvm-virtio-nic.114817/
Moin, etwas spät, aber hilft vielleicht:
lshw -class network | grep "ogical name: tap*" |while read line ; do ethtool -s ${line/"logical name: "/""} speed 1000 ; done
@reboot & täglich ausgeführt oder so - dann hast Du alle taps entsprechend hochgesetzt...
Kann als Cron täglich laufen.
#Edit: 100 Mbit statt 1000 angegeben :confused:
 
Last edited:
  • Like
Reactions: UdoB
Prima, danke fürs ausformulieren :)
Ich werde das also wohl tatsächlich in eine passende crontab packen. Auch wenn das nach "Holzhammer" riecht, es ist ein funktionierender Workaround.
 
Hallo Udo,
ich stehe seit einiger Zeit vor dem selben Problem, dass mein Monitoring mich den ganzen Tag zuspammt, das die Bridge-Member unter Volllast laufen.
Anstelle des Cronjobs habe ich das mithilfe eines Hook-Scripts gelöst (ist halt zeitgenauer und wird nur dann ausgeführt, wenn die VM hochgefahren wird).

Hier ein paar Details:

  • Als erstes dem Interface eine feste Bezeichnung geben, sonst vergibt QEMU bei jedem Neustart der VM eine neue vnet*-ID.
XML:
<interface type='bridge'>
      <mac address='52:54:00:98:0f:41'/>
      <source bridge='br0'/>
      <target dev='virtif01'/>
      <model type='e1000e'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

ACHTUNG: Es gibt gewisse Namen, die per Default QEMU vorbehalten sind und ignoriert werden, wenn man sie selbst setzt. Das gehören beispielsweise vnet*, virbr* und so weiter. Die QEMU-Doku gibt Aufschluss darüber. https://libvirt.org/formatdomain.html#overriding-the-target-element

  • Danach einfach per Hook-Script (normalerweise in /etc/libvirt/hooks/qemu) folgende Anweisungen ausführen
Bash:
#!/bin/bash

if [ "${1}" == "Windows2016ServerPRD" ] && [ "${2}" == "started" ]; then
    /usr/sbin/ethtool -s virtif00 speed 10000
fi

if [ "${1}" == "VWKS1" ] && [ "${2}" == "started" ]; then
    /usr/sbin/ethtool -s virtif01 speed 10000
fi

ACHTUNG: Wer jetzt denkt, dass er einfach in dem Script per "virsh domiflist" die Interfaces ziehen kann wird feststellen, dass er sich sehr schnell in einem Dead-Lock befinden wird. Während Libvirtd-Neustart kann das mal zufällig funktionieren, leider habe ich bisher keine Möglichkeit gefunden, das stabil hinzubekommen. Libvirtd hängt sich damit regelmässig auf. Laut Doku ist der Call-Back auf Libvirt verboten...
https://www.libvirt.org/hooks.html#calling-libvirt-functions-from-within-a-hook-script

Gruss
Jan
 
  • Like
Reactions: UdoB

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!