Dotaz: qemu - virtio - rychlost sítě NAT, BRIDGE

[walker]

Přeji hezký den,

řeším problém s přenosovou rychlostí sítě v různých režimech. Používám virtualizaci qemu (kvm, libvirt), host Archlinux, guest CentOS, sít běží na 1Gb

Pokud nastavím  sít na NAT nebo VEPA, běží vše v pohodě - rychlost se pohybuje kolem 900Mb/s  (měřeno mezi guest a druhým fyzickým serverem v síti) , jakmile však nastavím režim BRIDGE, tak klesne rychlost o jeden řád cca 90Mb/s
Prozatím jsem nepřišel na důvod ani na nastavení, jak host tak guest mají načteny moduly virtio (virtio_net).

Budu rád za každnou radu a nakopnutí (režim BRIDGE potřebuji kvůli tomu, že virutal pc bude součást sítě a nechce se mi řešit routování, asi by to tím šlo taky vyřešit).

---

---

Odpovědi

[Honza Vrana]

Krásný den,

Napadá mě, že by do toho mohl kecat switch, který ma najednou dvě mac adresy na jednom portu. Já měl obdobný problém ale switch druhou mac adresu zablokoval a nepustil ji do sítě vubec.

Honza Vrána

[vandrovnik]

Což je dost divné chování - na tom portu přeci místo PC může být jiný switch, tzn. to, že na jednom portu bude víc MAC adres, je naprosto běžné.

[Vantomas]

A nebo je to na switchi nastavené tak, že tam může být jen jedna MAC a v takovém případě to port odřízne. Switche to umožňují a je to čistě na rozhodnutí správce jak to bude mít nastavené.

Používá se to třeba v kancelářích, kde mají být připojené pouze počítače a v případě, že si nějaký zaměstnanec přinese switch a chce si připojit soukromý notebook.... Tak ať o tom administrátor ví.

[walker]

Switchem to asi nebude, je to sice CISCO (10/100/1000 SG 100-24) ale bez managementu. Navíc třebas v režimu VEPA (obdoba BRIDGE) to funguje (ale tento režim zase blokuje komunikace host<->guest což já zase potřebuji)

[Vantomas]

Tak to fakt netuším kde může být zakopaný pes. Nikdy jsem se nesetkal s takovýmto typem problému, že by to padlo na 100mbit.

Jediné co mě napadá, jaká je velikost MTU mezi virtuálem a hostem a případně na síťovce? Asi stačí poslat výpis z "ip link".

Případně jak vypadá brctl showbr <název bridge>? Jestli tam není více interfaců a jestli se to někde necyklí?

[Vantomas]

Další co mě napadá, jak se konfiguruje ten KVM guest? Nějaký libvirt nebo ručně spouštěný v shellu? Jestli se používá nějaký klikátko, tak mě napadá jestli se to tam při přenastavení z NAT na bridge nezmění používaný driver na síťovku v guestu, to by mohlo ořezat linkovou rychlost z gigabitu na 100mbit.

[walker]

Zdravím,

tak výpis jest tu:

 

ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
 link/ether 00:22:19:a7:ec:da brd ff:ff:ff:ff:ff:ff
3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
 link/ether 00:22:19:a7:ec:dc brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
 link/ether 52:54:00:ab:64:78 brd ff:ff:ff:ff:ff:ff
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN mode DEFAULT group default qlen 500
 link/ether 52:54:00:ab:64:78 brd ff:ff:ff:ff:ff:ff
6: macvtap0@eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
 link/ether 52:54:00:a6:c5:9e brd ff:ff:ff:ff:ff:ff
7: macvtap1@eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
 link/ether 52:54:00:89:ad:f0 brd ff:ff:ff:ff:ff:ff



server má dvě sítovky - eno1 eno2, eno1 je použita pro host a jeho služby, 
eno2 je pro guesty (v současné době dva - win7 a centos) ==> bridge jede přes rozhraní macvtap
Jinak ano, spouštím to přes virt-manager - grafické klikátko (no jsem občas lenoch, možná by stálo za to to zkusit spousti z shellu)

Díky za rady a pomoc

[Vantomas]

Jo, to jsem zase za zenitem koukám. Jako taky používám virt-manager na svém serveru, ale guestí síťovky jsou normální TAP rozhraní a ty poté libvirt přidává do br0 rozhraní kde mám ethernet do skutečný sítě.

Co jsem si tak zběžně hledal co je to ten macvtap, tak se jedná o nějakou náhradu za řešení typu TAP+bridge, nějaké all-in-one řešení. Napadá mě tedy, že by mohl být nějaký pes zakopaný zde. Zatím jsem se nedohledal jestli to vnitřně používá stejný kód a jen je to nějaký víc user-friendly bridge a nebo se jedná o něco většího.

Ale na těch dalších dvou guestech je také ono omezení na 100mbit nebo to lítá tak jak má?

[walker]

jak sem zjistil, jakmile má jakýkoliv gest macvtap jede jen 100 (i když ostatní vypnu a jede jen jeden, testoval sem) - a ano správně, macvtap je jak píšeš - kombinace tun/tap a bridge v jednom
ještě můžu zkusit udělat klasicky po starém. snad na něco přijdu. díky za tip

Jinak virt-manager používám i "vzdáleně", na svém cestovním notebooku jsem přidal spojení na virt na serveru (qemu+ssh) a vzdáleně tak mohou kontrolovat guesty (či se dokonce připojit, což ale nepoužívám,  radějí vnc+ssh či vnc+openvpn)

[Vantomas]

Jestli to z nějakého důvodu opravdu nemusí být macvtap, asi bych zvolil klasický bridge a k tomu TAP rozhraní, libvirt pro to rozhraní má, protože mi to přesně tak funguje a nemám s propustností problémy. Na internetech jsem v souvislosti s pomalým macvtapem dohledal, že to někomu žralo hrozně moc CPU a kvůli tomu se ořezávala propustnost, takže možná ještě kouknout do htopu na hostu když je síť vytížena zda je to tento problém nebo ne (v nastavení htopu možná bude třeba povolit zobrazovat kernel thready, aby se ten proces s macvtapem ukázal).

Jinak jo, proti virt-manageru asi nikdo nic mít nebude, v pozadí to používá libvirt, který už je docela dobře odladěn a dá se na to spolehnout, není důvod proč se mačkat s nějakým XML pro konfiguraci, když je klikací nástroj .

[walker]

Nene, na macvtap netrvám, prostě to virt-manager nabídnul. Zkusím to udělat "klasicky" a dám vědět. je to poslední věc co mi zatím brání v přechodu na 1G sít v jednom menším podniku (malý podnik malý rozpočet ....) a rád bych to měl vše v "cajku".

Jinak souhlas, virt-manager je dobrá věc.

Zatím díky za rady a pomoc.

[walker]

tak nevím, kde všude dělám chybu, ale už mám snad i podezření na svou neschopnost nebo vadu HW

Server je DELL a má dvě sítově karty 1Gb. Laborování jsem zjistil:

1. bridge macvtap na druhou kartu, host jede 1Gb, guest 100Mb, spojení host <-> guest funguje
2. bridge macvtap na první sítovou kartu, vše jede 1Gb, spojení host <-> guest není průchozí ani přes jednu sítovku
3. ručně vytvořený bridge na přes druhou sítovku - viz první případ
4. ručně vytvořený bridge na první sítovku - při nahození brige mi rychlost hostu klesla na 100Mb

bridge vytvořený ručně přes netctl

konfigurace bridge:

Description=" Bridge connection"
Interface=br1
Connection=bridge
BindsToInterfaces=(eno2)
#IP=no
IP=dhcp
## Ignore (R)STP and immediately activate the bridge
#SkipForwardingDelay=yes

brctl show
bridge name     bridge id               STP enabled     interfaces
br1             8000.002219a7ecdc       yes             eno2
 vnet0
virbr0          8000.525400ab6478       yes             virbr0-nic

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
 link/ether 00:22:19:a7:ec:da brd ff:ff:ff:ff:ff:ff
 inet 192.xxx.xxx.250/24 brd 192.xxx.xxx.255 scope global eno1
 valid_lft forever preferred_lft forever
 inet6 xxx scope link
 valid_lft forever preferred_lft forever
3: eno2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq master br1 state UP group default qlen 1000
 link/ether 00:22:19:a7:ec:dc brd ff:ff:ff:ff:ff:ff
 inet 192.xxx.xxx.201/24 brd 192.xxx.xxx.255 scope global eno2
 valid_lft forever preferred_lft forever
4: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
 link/ether 00:22:19:a7:ec:dc brd ff:ff:ff:ff:ff:ff
 inet6xxx scope link
 valid_lft forever preferred_lft forever
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
 link/ether 52:54:00:ab:64:78 brd ff:ff:ff:ff:ff:ff
 inet 192.xxx.xxx.1/24 brd 192.xxx.122.255 scope global virbr0
 valid_lft forever preferred_lft forever
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 500
 link/ether 52:54:00:ab:64:78 brd ff:ff:ff:ff:ff:ff
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 500
 link/ether fe:54:00:a6:c5:9e brd ff:ff:ff:ff:ff:ff
 inet6 xxx/64 scope link
 valid_lft forever preferred_lft forever


 

[walker]

Ještě jsem ted zmaten z jiné věci, když jsem si dal vypsat seznam HW - pomoci lshw (lshw-gtk) zobrazilo mi to u sítě vnet0 rychlost 10Mb . KDe dělám chybu?

https://sbdcheb.cz/obr/vnet0.png

[Vantomas]

Skutečnou linkovou rychlost ukáže třeba ethtool (ethtool em1).

Když se jedná o server, není náhodou u jednoho z portů svázán nějaký remote management? To by možná něco mohlo způsobovat a mohlo by napovědět v rozdílném chování mezi dvěma porty.

Každopádně to zní docela zapeklitě, pro začátek bych zkusil vzít nějaké live cd, kde je funkční KVM a zkusil jak se to chová s úplně jiným systémem. Všechno potřebné by asi mohl mít oVIrt Live cd, tam to půjde spustit aspoň ručně ze shellu.

[walker]

propustnost sem měřil pomocí iperf3

co se týká managementu, není na sítovkách žádný, Dell k tomu má speciální přídavek se sítovým vstupem. Zkusím když tak live CD. budu o víkendu laborovat :D díky za tip

[Vantomas]

Tak třeba HP má taky extra port pro management, ale zároveň jde v BIOS nastavit sharování prvního portu s managementem, celý server je pak poté možné připojit jedním patchcordem a nemusí se tahat druhý pro management. Dell neznám, takže nevím.

Ještě mě napadá, co je to za model/y síťovek? Třeba u Broadcom síťovek je třeba načítat nějaký binární blob (firmware), jinak tam nemusí všechno fungovat. Co třeba v dmesg když se vygrepuje jméno toho driveru nebo jméno interfacu, není tam něco podezřelého?

Pak taky spousta serverovějších síťovek má samostatný Linuxový drivery, které vždy nejsou součástí jádra a je třeba je ručně zkompilovat z jejich balíku, možná se zkusit zaměřit i na toto. Případně jejich dodávané drivery jsou novější než ty v jádru, může tam být nějaký bug okolo promiskuitního režimu, který je třeba pro běh bridge.

Na ten test s livecd doporučuji nějakou blbuvzdornější distribuci, případně přímo ten ovirt, aby to mělo právě všechny ty firmwary s sebou, aby se dala úspěšně vyloučila nějaká HW nekompatibilita.

[walker]

uf tak nevím čím to, ale dnes sem dělal jisté upravy včetně serveru, provedl jsem pár HW změn a restartů a po spuštění všech služeb světe div se, vše funguje jak má.

Současný stav je následující:

• most je nahozen přes netctl jako br1 přes rozhraní eno2
• na serveru ted běží dva guest-i
• rychost všemi směry je 1Gb, můj kýžený cílený stav

brctl show

bridge name     bridge id               STP enabled     interfaces
br1             8000.002219a7ecdc       no              eno2
                                                                      vnet0
                                                                        vnet1
virbr0          8000.525400ab6478       yes             virbr0-nic
 
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
 link/ether 00:22:19:a7:ec:da brd ff:ff:ff:ff:ff:ff
 inet 192.xxx.xxx.xxx/24 brd 192.xxx.xxx.255 scope global eno1
 valid_lft forever preferred_lft forever
 inet6 xxx:a4bd:7bcc/64 scope link
 valid_lft forever preferred_lft forever
3: eno2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq master br1 state UP group default qlen 1000
 link/ether 00:22:19:a7:ec:dc brd ff:ff:ff:ff:ff:ff
 inet 192.xxx.xxx.201/24 brd 192.xxx.xxx.255 scope global eno2
 valid_lft forever preferred_lft forever
4: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
 link/ether 00:22:19:a7:ec:dc brd ff:ff:ff:ff:ff:ff
 inet6 fe80::26af:909:f80e:c0f0/64 scope link
 valid_lft forever preferred_lft forever
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
 link/ether 52:54:00:ab:64:78 brd ff:ff:ff:ff:ff:ff
 inet 192.xxx.122.1/24 brd 192.xxx.122.255 scope global virbr0
 valid_lft forever preferred_lft forever
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 500
 link/ether 52:54:00:ab:64:78 brd ff:ff:ff:ff:ff:ff
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 500
 link/ether fe:54:00:a6:c5:9e brd ff:ff:ff:ff:ff:ff
 inet6 fe80::8dfa:f489:7ed4:58be/64 scope link
 valid_lft forever preferred_lft forever
8: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 500
 link/ether fe:54:00:89:ad:f0 brd ff:ff:ff:ff:ff:ff
 inet6 fe80::768d:be10:c414:4ae7/64 scope link
 valid_lft forever preferred_lft forever

Patrně jsem tak dlouho laboroval a koumal, až z toho byl mišmaš a restarty to vyčistili :D

jen malý dotaz - u mostu hodnota STP enabled je lepší on nebo off?

Děkuji všem za pomoc a tipy.

[GeorgeWH]

interface, ktory je v bridge, by nemal mat ip adresu.