Portál AbcLinuxu, 14. května 2025 12:01
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
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.serialSkripty
16.5.2016 13:40
16.5.2016 14:07
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ě.
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í...
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é.
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.
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í....
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....
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.