Networking v QEMU

25.9.2011 20:06 | Přečteno: 1601× | Za vším hledej Linux | poslední úprava: 25.9.2011 20:05

Také řešíte síťování v QEMU a máte v tom tak trošku guláš? Pokud ano, tak se vám možná bude hodit můj manuálek v naší wiki.

Nejrůznějších "návodů" můžete nalézt na internetu přehršel, ale mě kupř. docela chybělo nějaké polopatické schéma, jak to vlastně funguje. Sbírám takhle nejrůznější střípky, zlehka je přežvykuji a publikuji v rámci naší wiki. Všechno je odzkoušeno a odtrápeno na vlastní kůži, ale jak zcela oprávněně poznamenal kolega, určitě by neškodilo, kdyby ty věci čas od času okouknul i někdo jiný a případně upozornil na to, co jsme pochopili blbě. Omlouvám se tímto za poněkud stručný text (pořád ještě dopisuji nějaké věci na výše odkazovanou stránku wiki) a skrytou reklamu.

       

Komentáře

[Zdeněk Burda]

Sice v tom guláš nemám, ale dík - je to pěkně sepsané

[tom]

Pomerne pekne je to popsane v manualu, staci pochopit, ze pro jednu sit potrebuju 2 -net parametry a pak uz netreba hledat na webu.

[Aleš Kapica]

Zrovna před chvilkou jsem tam doplňoval odstavec, kde uvádím situaci, kdy to nestačí.

[pht]

Máte tam celkem dlouhý odstavec o VDE. Používáte to? Má to nějaké výhody oproti normálnímu bridge?

[Aleš Kapica]

Používám. Nad VDE2 jsem měl postavenou původní verzi obslužného skriptu (dá se k němu dostat proklikáním z odkazované stránky). Z mého pohledu to na prosíťování většiny běžných virtuálních strojů bohatě stačí. Jako super mi přišla především možnost, že se do jednoho "base" switche přivede vnější konektivita a pak už veškeré další síťování probíhá v userspace, tzn. že uživatel, který virtuál spouští a sestavuje síťovou infrastrukturu má naprostou kontrolu nad veškerými datovými toky. Tuto síťovou infrastrukturu lze přitom odpojit od vnější sítě, aniž by bylo nutné víc než ukončit jeden proces, kterým je konektivita přivedena do virtuálního switche.

Na problém se síťováním přes VDE jsme narazili až u jednoho našeho speciálního virtuálu, který kromě toho, že pracuje s více subnety má i poměrně vysoké nároky na propustnost síťě. Původní řešení postavené na XENu bylo subjektivně rychlejší, i když podmínky nebyly zcela srovnatelné. Abych to vysvětlil..

Původní řešení jede na stroji kde je virtualizován pouze jeden stroj. Takže ten má prakticky pouze pro sebe celou konektivitu. Navíc je virtuál napojen přes bridge přímo na fyzické rozhraní. Také má ten virtualizační stroj poměrně dost paměti (6GB). Stroj pro virtualizaci KVM verze stroje má jenom 4GB paměti, navíc už tam jeden virtuál běží takže se musel dělit o konektivitu. Stejným drátem probíhá kromě síťové i datová komunikace (disky virtuálů jsou připojovány přes NBD). VDE switche byly propojeny ssh tunelem a navíc jsem měl ještě v té době implementován defaultně wirefilter, což ještě konektivitu vnitřního stroje ořezávalo o další pakety. Závěr? Fungovalo to, ale dřelo to. Takže jsme zatím setrvali u původního řešení přes XEN. Větší luxus už ten virtuál totiž mít nemůže a ty staré stroje alespoň morálně dožijí.

Co je ovšem zajímavé z hlediska VDE. Ten druhý paralelně běžící stroj veškeré naše pokusničení se sítí přežil a stále jede. Přitom byl už minimálně dvakrát za běhu kompletně přemigrován. Myslím, že pokud někdo nemá (a nepotřebuje) vysokou propustnost do vnějšího internetového světa, tak VDE bohatě stačí. Já zatím VDE nezatratil, naopak plánuji ještě nějaké pokusy při kterých bych si ověřil některésvé domněnky.

[SAM:]

Respektive jaké úzké hrdlo se projevily zejména časté přechody kernel-user space a metoda použitá pro přenos dat mezi jednotlivými novy distribuovaného switche (ssh/nc/...).

[pht]

No jo ale přijde mi že je se sestavováním a patláním se s VDE zbytečně moc práce, když můžu místo toho udělat normální bridge. Izolované sítě to umí úplně stejně, připojení / odpojení světa je také záležitost jednoho příkazu. Navíc mám možnost na tom použít nativně eb/iptables a další vymoženosti. Co z toho umí VDE, případně co má navíc?

[Aleš Kapica]

VDE nenahrazuje síťování uvnitř stroje, ale fyzickou infrastrukturu. Hlavní výhodou je, že vše kromě bodu kterým je přivedena vnější konektivita běží pod uživatelem v userspace, který jinak do konfigurace sítě hrabat nemůže.

Jinak jsem dnes dělal několik menších testů, takže si troufám říct že se Martin v příspěvku výše mýlí. Tím úzkým hrdlem nebyla samotná infrastruktura VDE, ale použití aplikace wirefilter, která až 10% paketů zahazuje - na což ovšem autoři v manuálu upozorňují.

Mnohem větší vliv mají jiné věci - především zapnutá HW virtualizace U novějšího QEMU se musí přidat volba -machine accel=kvm, jinak použije emulaci, přesto že je modul pro kvm v jádře zaveden. Proháněl jsem sítí mezi dvěma virtuály - ještě přes jiný stroj tam a zpět - gigový blok dat, abych měl na lince přenosy v obou směrech. Asi to je zbytečné uvádět, ale při aktivivaném kvm to trvalo cca 4,5 minuty, bez ohledu na to, jestli jsem to honil přes vde, nebo jinak (rozdíl byl v řádu sekund). A bez aktivovaného kvm to zabralo cca 12x delší dobu (mezi 50 - 55 minutami). Opět. Mezi připojením vde switchů přes ssh nebo přímo přes soket a přímým připojenám nebyl výraznější rozdíl.

Při použití vde switche dokonce vychází přenosová rychlost spíš mírně vyšší, než když jsem stejný přenos realizoval přes tap zařízení a s využitím modulu vhost. A taky bylo nižší zatížení CPU.

[pht]

U novějšího QEMU se musí přidat volba -machine accel=kvm, jinak použije emulaci, přesto že je modul pro kvm v jádře zaveden.

O které verzi mluvíte? Na mojí 0.15 nic takového nepozoruji.

[Aleš Kapica]

lucy (HOSTSERVER) :~# qemu-system-x86_64 --help
QEMU emulator version 0.15.50, Copyright (c) 2003-2008 Fabrice Bellard

Ale popravdě řečeno - pokud jde o verzi, tak to není v případě QEMU žádná relevantní informace. Jinými slovy řečeno - používám verzi z gitu aktuální k 30. srpnu.

[Aleš Kapica]

Tak už vím, jak to s tím verzováním je. Verze 0.15.50 je kompilovaná z vývojové repository, kde se vyvíjí SPICE, zatím co oficiální vývojová repozitory QEMU má číslo verze 0.15.0.

[Aleš Kapica]

Souvisí to s tím, že novější QEMU umožňuje používat nejenom KVM, ale i XEN. Ovšem výchozí volba QEMU, kterou použije, není-li uvedeno jinak, je TCG (Tiny Code Generator).

[pht]

To by snad mohlo do vydání 0.16 být ošetřeno inteligentněji, jinak bude asi hodně rozzlobených uživatelů.

[Aleš Kapica]

No tak ono to svým způsobem inteligentní řešení je. Stroj najede. Sice není tak výkonný, ale jede. Spíš je zádrhel v tom, že uživatel nechápe co se děje, jen se diví proč je to tak vláčné. Má-li k dispozici monitorovací konzoli, nebo QMP konzoli, tak lze obratem zjistit jak to s kvm je, jenže co já vím, tak při spouštění přes libvirt k těmto konzolím standardně přístup není, ale určitě musí mít možnost tuhle informaci z QEMU vytáhnout.

[polymorf]

Nemalo by sa to nahodou volat Networking v KVM?

[Aleš Kapica]

Ne, protože KVM jako takové nemá se síťováním nic společného.