QEMU 2.6.0 (diskuse)

[Aleš Kapica]

S ohledem na fakt, že mnohdy ani zkušení IT matadoři netuší jak u QEMU funguje síťování, přidávam link na svůj nedávno aktualizovaný manuál ke konfiguraci sítě u QEMU.

[pepe_]

Nějak nikde nevidim jak dát qemu síťovku bez tun/tap jako bridge na konkrétní lan adaptér jako to má třeba virtualbox vmware. Lze to vůbec nebo stále musim vytvořit tun/tap , dát ho do bridge s konkrétní lan a pak pustit na ni qemu ? Ani wiki moc nepomohla ... díky

[pavlix]

Motivace? A jak že to mají?

[Aleš Kapica]

Kokrétní příklad asi bude lepší:

qemu-system-x86_64 -daemonize -machine accel=kvm \
-name third -cpu kvm64 -M q35 -m 8192 \
-device virtio-scsi-pci \
-drive file=sheepdog:localhost:9000:third,if=none,index=0,id=sheep0,cache=none,media=disk,format=qcow2 \
-device scsi-hd,drive=sheep0 \
-netdev tap,id=third0,ifname=main-third-4,script=/etc/openvswitch/ovs-ifup,downscript=/etc/openvswitch/ovs-ifdown \
-device virtio-net-pci,mac=be:ce:de:00:a0:22,netdev=third0 \
-netdev tap,id=third1,ifname=main-third-17,script=/etc/openvswitch/ovs-ifup,downscript=/etc/openvswitch/ovs-ifdown \
-device virtio-net-pci,mac=be:ce:de:01:a0:22,netdev=third1 \
-serial file:/var/log/third.serial

Skripty ovs-ifup a ovs-ifdown se starají o nahození a zrušení portů na openvswitchi. Ovšem to už je v podstatě jen taková vychytávka. Ty porty mohou být klidně vytvořeny jednorázově.

[Aleš Kapica]

Jinak samozřejmě pokud bych to chytal na zařízení, které se má "píchnout" do bridge, tak bych použil místo backendu "tap" backend "bridge". Podle mě je ale použití klasického bridge při virtualizaci přežitek.

[Radek Hladik]

Pokud se nepletu, tak VirtualBox i Vmware používají nějakou formu bridgování. Například virtualbox na win nainstaluje nějaký driver, který ten bridging dělá sám. Osobně si myslím, že použití standardního systémového bridge je nejlepší řešení. Když něco funguje, proč to nepoužít....

Navíc se dá použít macvtap (nebo jak se to jmenuje), což jestli to chápu správně (nikdy jsem to nepoužíval) umožní se napojit na síťovku aniž by se musel dělat bridge. Ale má to jedno omezení, a sice to, že se nepoužívá ten bridge T.j. pokud nemám switch, který umí posílat rámce i zpátky, pak nemůžou komunikovat dvě věci na stejné síťovce... A to je podle mně přesně ten příklad toho, proč je lepší použít něco, co danou věc dělá dobře, než se to snažit obejít a pak mít problém z toho, že to obchází...

[trekker.dk]

Pokud se nepletu, tak VirtualBox i Vmware používají nějakou formu bridgování.

Tak samozřejmě, co by se taky dalo dělat jiného? (Teda kromě PCI passthrough na strojích s IOMMU.) Akorát někdo se k tomu přizná, zatímco jiný si vymyslí vlastní vŘešení, Open vŘešení, které mají pod kapotou (v principu) to samé.

[Radek Hladik]

Ještě je možnost ty framy nějak posílat přímo nějakému switchi. Takové ty software defined network, což si myslím bude v budoucnu docela zajímavé.

Ale je fakt, že i to PCI passthrough je docela zajímavá technologie. Měl jsem tu dvě různé 10Gb síťovky a u obou to fungovalo moc pěkně, ale pokaždé to mělo pár drobností, kvůli kterým to nešlo nasadit do produkce (zatím).

[trekker.dk]

pokaždé to mělo pár drobností, kvůli kterým to nešlo nasadit do produkce (zatím).

Nějaké nestability nebo něco takového? Já to mám připravené jako nouzové řešení, kdyby na nějakou virtuálku šel bordel, který by se nestíhal obsluhovat tím softwarovým bridgem. Nerad bych zjistil, že to nejde použít, až v tu chvíli.

[Radek Hladik]

Nestabilit jsem si nevšiml. Problémy jsme měli spíš s konfigurací. Jedno síťovka byla Broadcom BCM57840 a druhá nějaký onboard Intel od SuperMicra (Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01) ).

První problém (asi nejsnáze řešitelný) byl, že libvirt neměl (tehdy, nevím jestli má teď) nějakou jednoduchou metodu "přiřad první volný PCI pass-trough". Při použití virtuálních funkcí samozřejmě nejde úplně snadno live migrace (možná nejde vůbec, do detailu jsem po tom nepátral), ale alespoň cold migraci by pomohlo, kdybych mohl specifikovat něco jako "přihoď první volnou aspoň trochu kompatibilní síťovku". Prostě to, jak funguje normální bridge

Vážnější problém bylo, že ten Broadcom měl konfiguraci buď v biosu nebo přes nějakou jejich gui utilitu, která chtěla nějakou šílenou service, která chtěla nějakej šilenej framewrok.... Šlo naštěstí jen o základní nastavování počtu VF a tak, ale je fakt, že představa, že budu muset rebootovat abych zvýšil počet VF, se mi moc nelíbila... S tím souvisí další drobnost, že když je v systému 64VF (maximální počet, abych nemusel rebootovat), tak aby se v těch síťovkách pes vyznal A ještě tam pak byla nějaká drobnost s nastavováním MAC adres, opět snadno řešitelná, ale přesto opruz...

Teď už si nevzpomenu přesně která, ale jedna z těch síťovek měla taky problémy s tím, když má "otočit" frame, tedy když je frame určený pro někoho na stejné kartě (ale jiné VF). On se ten bridging vlastně přesouvá do driveru té síťovky, což v principu taky není ideální. Anebo to musí umět switch, ale přiznávám, že to máme připojené k entry-level Ciscu s 4x10GB porty, které to neumí...

A v jednom případě mám pocit něco zahaprovalo v tom vnitřním stroji a síťovka nefungovala... Ale to byla taky možná moje chyba a detaily už si nepamatuju....

Takže celkově shrnuto, standardní brdiging nám přišel výrazně snazší a tohle máme v zásobě pro případ, že nějaký virtuál bude potřebovat velmi vysoký datový tok nebo tok s nízkou latencí....

[trekker.dk]

Aha, já to zkoušel jenom přímo na té fyzické síťovce - máme na serverech jednu navíc, což by pro nouzové situace typu "na jedno IP jde bordel" mělo stačit.

VF jsem teď zkusil jenom tak narychlo a vypadá to docela dobře - síťovky Intel i350 (8086:1521) a taky X540-AT2 (8086:1528). U obou jdou VF zapínat přes sysfs za běhu a vypadá to, že stroje na různých VF na jedné síťovce spolu komunikují přímo (tcpdump na té "základní" síťovce nic neukazuje). Vypadá to pěkně, ale prakticky mi to asi k ničemu nebude, protože na tom softwarovém bridgi s tap zařízeními mám 802.3ad bond na konektivitu do internetu. Mám takové tušení, že 7 (nebo 63, podle síťovky) různých bondů na jednom fyzickém portu by switche asi nezkously.

[Radek Hladik]

Jo, mám pocit, že ty intelí byly na tom s podporou a tak líp. Ale bohužel to byl metalický ethernet, zatímco náš switch umí 10Gb jen na "optice"... Přes /sys šel počet VF měnit u obojího, ale např. u té broadcom se v tom biosu nastavovala max hodnota...

Situace "na jedno IP jde bordel" umíme docela pěkně řešit na switchi, protože už i to entry-level cisco má základní firewall s dostatečným počtem pravidel. Osobně mám pocit, že už ten firewall v tom ASICu funguje hodně podobně jako switching/routing, takže zatímco linksys kdysi míval omezení na cca 8 FW pravidel, pak snad 40, tak teď už je to něco jako 4K...

[trekker.dk]

Tak kdyby to bylo něco, na co jde snadno napsat pravidla do firewallu, tak se to dá řešit netfilterem na hostiteli ještě předtím, než to vleze do bridge. Já měl na mysli spíš něco jako slabší DDoS - moc silný na to, aby to neustál softwarový bridge, ale dost slabý na to, aby to zvládl fyzický hardware.

[Radek Hladik]

Osobně mám zkušenost, že něco jako "slabší DDoS" neexistuje Protože pokud jednou přijde DDoS v řádu X, se kterým se vypořádáte, tak za chvíli přijde DDoS v řádu 2*X atd...

Právě proto je ideální to přesouvat co nejdál od serveru, t.j. ideálně na switch, k providerovi, atd... Takhle jsme poměrně dobře schopni řešit DDoSy v řádu do cca 15GBit/s s tím, že cílovému stroji odřízneme komunikaci (někdy i jen neNIX komunikaci), ale ostatní stroje fungují v pořádku....

[trekker.dk]

Jo, to jasně, rozhodně jsem tímhle nechtěl vymýšlet nějaké konečné řešení - když ten provoz nejde zvládnout, tak se to zařízne vejš. Mně šlo jenom o to mít možnost tohle opatření - když to půjde - oddálit.

[JduKolem]

Ono lepší než virtuální funkce na SR-IOV bude, až se plně začlení podpora DPDK do openvswitche, tam by měla být live migrace bez problémů, jelikož se nebude jednat o žádnou změnu na straně virtuálů, ale na straně obsluhy síťovky na straně openvswitche. A taky doufám že bude v oVirt 4.0 plná podpora openvswitche jako takového.

Osobně jsem to zkoušel v takovým experimentálním setupu (CentOS 7, openvswitch trunk a nedistribuční DPDK) na 2x10GbE Intel do HP 5900 switche, a opravdu nekecají, dá se z toho tahat "Ludicrous speed".

[trekker.dk]

Síťovky jsou sranda, nedávno jsem zkoušel dostat do virtuálu pomocí -drive/-device CD-ROM a byl to pěkný porod. I když nakonec kvůli tomu, že SystemRescueCD zřejmě neumí bootovat z virtio-scsi sběrnice a musí se tomu předhodit něco méně exotického.

[trekker.dk]

(Překlik, měla to byla reakce na #1)

[Aleš Kapica]

Pravda, pro předchozí manuálovou stránku mám většinu věcí stále ještě v poznámkách.