Portál AbcLinuxu, 12. prosinec 2017 07:28

Xen vs. KVM: Souboj v extrémních podmínkách 2010

24. 8. 2010 | Jirka Bourek
Články - Xen vs. KVM: Souboj v extrémních podmínkách 2010  

Před několika měsíci zde vyšel článek Xen vs. KVM: Souboj v extrémních podmínkách. Od pořízení dat pro tento článek (září 2009) uplynul téměř rok, během kterého vyšly nové stabilní verze KVM i Xenu a v jádře se objevilo několik vlastností podporujících virtualizaci. Nadešel tedy čas na další kolo souboje.

Obsah

V tomto článku se budeme výrazně odkazovat na článek předchozí, tam najdete stručný popis testovaných virtualizačních technologií i jejich loňské výsledky, se kterými se v tomto testu budeme srovnávat.

Testy a testovací sestava

link

Hardware

link

Pro testování byl použit server se základní deskou Intel S5520UR osazený následujícími komponentami:

Procesor:2× Quad-Core Intel Xeon E5506 (2.13GHz)
Paměť:12× 2GB DIMM (800MHz)
Pevné disky:2×500GB Seagate (ST3500320NS)
2×1000GB Seagate (ST31000340NS)

Z disků byla sestavena 2 pole RAID1 (softwarový RAID), na menším poli byl nainstalován hostitelský operační systém, nad větším polem bylo vytvořeno LVM, logické svazky sloužily jako disky virtuálních strojů.

Stroj disponuje dvěma síťovými kartami. První – eth0 – sloužila jako rozhraní do fyzické sítě, zároveň byla pomocí bridge spojena se síťovými kartami strojů, aby se z hostitele bylo možné pomocí SSH přihlásit na hosty. eth1 se nepoužívala.

Za zapůjčení testovacího stroje děkuji společnosti THINline interactive s.r.o, provozovateli služeb Český hosting a Spolehlivé servery.

Software

link

Jako operační systém byl tentokrát zvolen Debian Squeeze – stabilní verze (Lenny) neobsahuje ani aktuální verzi Xenu, ani KVM.

Testům byly opět podrobeny dvě výkonnostní varianty virtuálních strojů. První varianta měla k dispozici celé CPU a 2048 MB paměti, druhá měla k dispozici 1/4 CPU a 512 MB paměti (tyto varianty budou v textu nadále podle využitelného času CPU označovány jako 1/1 a 1/4.) Při všech testech bylo hostitelskému systému ponecháno k dispozici jedno jádro CPU, které hosty nesměly využívat.

Co se disků týče, tentokrát byly pro každý virtuální stroj vytvořeny pouze dva logické svazky, jeden pro systém a jeden pro datový oddíl, na kterém se prováděly testy – vzhledem k tomu, že při minulých testech hosty nikdy nevyužívaly swap, nebyl tentokrát žádnému z nich swapovací oddíl přidělen. Na systémovém oddílu byl použit souborový systém ext3, na datovém xfs.

Kompletní nastavení Xenu je možné vyčíst z konfiguračního souboru:

memory = 2048
maxmem = 2048
name = "virtual1"
cpus= "^0"
vif = ['ip=192.168.150.11,mac=00:00:10:01:23:01,bridge=br0']
disk = ['phy:mapper/obrazy2-vsys1,xvda,w','phy:mapper/obrazy2-vdata1,xvdb,w']
kernel = "/boot/vmlinuz-2.6.32-5-xen-amd64"
ramdisk = "/boot/initrd.img-2.6.32-5-xen-amd64"
root = "/dev/xvda1 ro"

KVM hosty se spouštěly následujícím skriptem:

#!/bin/bash

tunctl -t tap1_01
ip l s tap1_01 up
brctl addif br0 tap1_01

kvm -drive file="/dev/mapper/obrazy2-vsys1",index=0,if=virtio,boot=on -boot c -m 2048 \
 -drive file="/dev/mapper/obrazy2-vdata1",index=1,if=virtio,boot=off,cache=none \
 -net nic,vlan=0,macaddr=00:00:10:01:23:01,model=virtio -net tap,vlan=0,ifname=tap1_01,script=no \
 -monitor tcp::44001,server,nowait -vnc :1

ip l s tap1_01 down
brctl delif br0 tap1_01
tunctl -d tap1_01

Jako minule KVM využívá ovladač disků virtio a přidělený výkon CPU je omezován pomocí řídích skupin [control groups]. Omezení využívaného výkonu pro Xen hosty je zajištěno pomocí

xm sched-credit -d virtual1 -c 25

Testy

link

Pro srovnání výkonu strojů oproti hostiteli a také pro porovnání výkonu jednotlivých výkonnostních variant hostů byla použita obdobná sada testů jako loni. Připomeňme, že testy se příliš nepodobají reálnému provozu a v některých případech jsou příliš náročné na to, aby taková zátěž byla provozována na jediném hostitelském stroji.

Následuje popis jednotlivých testů a dosažené výsledky:

Výkon CPU

link

Výkon CPU byl testován zašifrováním 5 GB nul pomocí openssl, výsledek se zahazoval. Nuly se načítaly z /dev/zero a výsledná zašifrovaná data směřovala do /dev/null:

time dd if=/dev/zero bs=1048576 count=5120 | openssl \
enc -aes-256-cbc -salt -S "0123456789abcdef" -pass pass:opravduhloupeheslo >/dev/null

Pomocí time se měřila doba, za kterou se daná úloha dokončila.

1. Test s jediným běžícím procesem.

link

Testovací proces byl postupně spuštěn na hostiteli, na jednom KVM 1/1 hostu a jednom Xen 1/1 hostu. Ve všech případech byl test třikrát opakován. V tabulce jsou uvedeny minimální, průměrné a maximální doby běhu testovacího procesu. V závorce je uveden nárůst doby běhu na příslušném virtuálním stroji oproti hostiteli v procentech.

HostitelKVM 1/1Xen 1/1
minimum53,303 s57,366 s (+7,6 %)1m 3,076 s (+18,3 %)
průměr53,336 s57,459 s (+7,7 %)1m 3,104 s (+18,3 %)
maximum56,400 s57,592 s (+2,1%)1m 3,145 s (+12,0 %)

2. Sedm paralelně běžících procesů

link

V tomto testu bylo na hostiteli spuštěno sedm testovacích procesů zároveň, doba běhu byla porovnávána s během sedmi testovacích procesů, z nichž každý běžel na jednom testovacím stroji varianty 1/1.

HostitelKVM 1/1Xen 1/1
minimum 56,013 s 57,715 s (+3,0 %) 1m 3,688 s (+13,7 %)
průměr 56,183 s 58,136 s (+3,5 %) 1m 3,970 s (+13,9 %)
maximum 56,509 s 58,492 s (+3,5 %) 1m 4,366 s (+13,9 %)

3. 28 paralelně běžících procesů

link

Tentokrát bylo na hostiteli spuštěno 28 testovacích procesů paralelně (pomocí řídících skupin bylo zajištěno, že tyto procesy mohly využívat pouze 7 jader CPU). Doba běhu je opět porovnávána se stejným počtem testovacích procesů, každý běžel na vlastním testovacím stroji varianty 1/4.

HostitelKVM 1/4Xen 1/4
minimum 3m 3,835 s 2m 58,637 s (-2,8 %) 4m 17,554 s (+40,1 %)
průměr 3m 31,126 s 3m 34,414 s (+1,6 %) 4m 18,069 s (+22,2 %)
maximum 3m 51,438 s 3m 59,753 s (+3,6 %) 4m 19,044 s (+11,9 %)

4. Test na strojích o různém výkonu.

link

Celkem bylo paralelně spuštěno 19 testovacích procesů, 16 z nich na hostech 1/4 a tři na hostech 1/1 (na hostiteli byly procesy omezeny pomocí řídících skupin – 16 procesů mělo k dispozici 4 CPU a zbývající tři procesy každý po jednom CPU).

V tomto testu není srovnáván poměr výkonu hostitele a hostů, ale poměr výkonů mezi jednotlivými výkonnostními variantami (a jeho dodržování). V tabulce jsou uvedeny průměrné hodnoty doby běhu testů a poměr jejich doby trvání.

HostitelKVMXen
1/1 56,206 s 58,275 s 1m 10,277 s
1/4 3m 49,335 s 3m 26,637 s 4m 21,106 s
po měr 4.,80 3.,46 3.,15

Shrnutí

link

Oproti minule si v tomto testu Xen pohoršil – průměrná doba zpracování úlohy byla o 18 % větší než u hostitele; Xen se zde propadl pod úroveň KVM, které oproti hostiteli potřebovalo jenom o necelých 8 % více času. Paralelní běh procesů tak, že každý proces měl pro sebe jedno CPU, ukazuje pro obě možnosti virtualizace lepší výsledky v procentech, ty jsou nicméně dány zhoršením celkového času hostitele, nikoliv zlepšením času hostů.

U třetího testu, kde se hosty či úlohy musí o CPU dělit, dosáhlo KVM výkonu téměř srovnatelného s hostitelem (úloha na hostovaném stroji běžela pouze o 1,6 % času déle), Xen se naopak ještě více propadl a potřeboval o 22 % času navíc. I zde tedy Xen měl horší výsledky než loni, KVM naopak lepší.

Na rozdíl od výsledků z loňska KVM tentokrát příliš nerespektovalo nastavené výkonnostní varianty. Navíc se značně zvětšil rozptyl časů zpracování testovací úlohy na hostech varianty 1/4 – hostitelský stroj totiž jednotlivé virtuální stroje neumístil rovnoměrně na dostupné procesory, takže například zatímco na jednom CPU běžely tři virtuální stroje, na jiném jich běželo šest.

Xen dodržoval nastavení výkonnostních variant o něco lépe.

Přestože by úlohy na výpočetní výkon neměly být ve virtualizovaném prostředí nijak problematické, režie Xenu je zde poněkud vysoká. KVM si naopak vedlo lépe než v loňském testu, což s největší pravděpodobností souvisí s tím, že použitý procesor tentokrát disponuje technologií EPT (extended page tables), která urychluje operace s pamětí virtuálního stroje.

Práce s diskem

link

Čistá práce s diskem byla testována zápisem velkého souboru pomocí dd:

dd if=/dev/zero of=soubor.bin bs=1048576 count=16384

Testována byla doba běhu testu (a tím rychlost zápisu na disk).

1. Test bez paralelizace

link

Aby se omezil vliv diskové cache, v tomto testu se na hostiteli místo jednoho souboru postupně zapisovalo souborů sedm, každý na samostatný LVM oddíl1. Zápis na hostiteli trval 1126,696 s, což dělá 101,79 MB/s. Výsledky hostů (průměrné hodnoty ze tří běhů a zpomalení nebo zrychlení oproti hostiteli v procentech) jsou uvedeny v tabulce:

KVM 1/1 (writeback) KVM 1/1 (writethrough) KVM 1/1 (none) Xen 1/1
průměr 161,591 s (101,39 MB/s) 348,446 s (47,02 MB/s) 153,952 s (106,42 MB/s) 219,043 s (74,79 MB/s)
odchylka -0,4 % -53,8 % +4,5 % -26,5 %

Test byl pro KVM proveden několikrát, pokaždé s jiným nastavením cachování pro disk (LVM oddíl), na kterém test probíhal. Nejlepšího výsledku bylo dosaženo pro cache=none, což je i režim, který doporučují vývojáři KVM v případě, že se jako disk používá přímo diskový (LVM) oddíl. V dalších testech se tedy bude vždy používat cache=none

2. Sedm paralelně běžících procesů

link

Na hostiteli se tentokrát zapisovalo sedm souborů o velikosti 16 GB paralelně, každý z nich na samostatný souborový systém o velikosti 20 GB.

Hostitel KVM 1/1 Xen 1/1
minimum 1143,320 s (14,33 MB/s) 1203,410 s (13.61 MB/s … -5,0 %) 2308,070 s (7.10 MB/s … -50,5 %)
průměr 1053,727 s (15,55 MB/s) 1171.,90 s (13.98MB/s … -10,1 %) 2210,690 s (7.41 MB/s … -52,3 %)
maximum 841,041 s (19,48 MB/s) 1143,380 s (14.33 MB/s … -26,4 %) 2089,870 s (7.84 MB/s … -59,8 %)

Shrnutí

link

Oproti loňským testům, kde zaznamenávalo velký propad výkonu, si KVM významně polepšilo: Při běhu jednoho samostatného testovacího procesu byl dokonce host nepatrně rychlejší než hostitel. KVM si i zde s Xenem vyměnilo pozice, protože výkon Xenu se naopak snížil.

KVM si výrazně polepšilo i při paralelním běhu testovacích skriptů – oproti dřívějšímu propadu rychlosti zápisu o 80 % zde rychlost zápisu klesá o pouhých 10 % oproti hostiteli. Xen se drží na zpomalení o cca 50 %.

KVM zde překvapivě ukázalo, že dokáže poměrně dobře pracovat i v případě, že k disku přistupuje několik hostů naráz. Výkonu Xenu při paralelním přístupu je naopak na hranici použitelnosti systému; zde je nicméně dobré zopakovat, že pokud by takováto zátěž byla trvalá, zasluhovala by si více než jeden hostitelský stroj.

Poměrně zajímavé je, že vytížení hostitele (hodnota load) se při testech KVM pohybovala kolem 25, při paralelním testu sedmi KVM strojů dokonce okolo 140 – hostitel nicméně přesto reagoval bez latencí.

1 Ve všech případech, kdy se na hostiteli testuje úloha využívající souborový systém, je tento souborový systém vytvořen na stejném LVM oddílu, který používá host jako disk. V případě, že na hostiteli běží několik testovacích úloh paralelně, používá se tolik LVM oddílů, kolik úloh běží.

CPU + práce s diskem (1)

link

Výkon při využívání těchto systémových prostředků současně byl testován rozbalením zdrojových kódů jádra. Zdrojové kódy byly rozbalovány desetkrát po sobě, každá kopie do samostatného adresáře. Pomocí time bylo měřeno, za jak dlouho se rozbalování dokončí.

1. Test bez paralelní práce

link

Testovací proces byl postupně spuštěn na hostiteli, na jednom KVM 1/1 hostu a jednom Xen 1/1 hostu. Ve všech případech byl test třikrát opakován.

HostitelKVM 1/1Xen 1/1
minimum 22 m 53,633 s 23 m 37,996 s (+3,2 %) 24 m 57,020 s (+9,0 %)
průměr 23 m 5,285 s 23 m 43,299 s (+2,7 %) 25 m 5,705 s (+8,7 %)
maximum 23 m 24,293 s 23 m 48,617 s (+1,7 %) 25 m 10,790 s (+7,6 %)

2. Sedm paralelně běžících procesů

link

Test byl spuštěn sedmkrát paralelně na hostiteli, na sedmi KVM 1/1 hostech a sedmi Xen 1/1 hostech. Test byl třikrát opakován2.

HostitelKVM 1/1Xen 1/1
minimum 133m 11,251 s 129m 3,866 s (-3,1 %) 131m 48,768 s (-1,0 %)
průměr 135m 15,608 s 131m 25,420 s (-2,8 %) 133m 34,926 s (-1,2 %)
maximum 136m 36,002 s 132m 44,431 s (-2,8 %) 134m 42,039 s (-1,4 %)

Shrnutí

link

I zde zaznamenáváme výrazné zlepšení KVM oproti loňskému testu. Výkon hostů je v podstatě srovnatelný s výkonem hostitele, také se tentokrát nekonala žádná varovná hlášení v dmesg a při práci přes SSH hostitel reagoval bez prodlevy. Jak je vidět z tabulky uvedené výše, na rozdíl od loňských testů ve všech třech případech KVM podávalo rovnoměrné výkony, neopakovala se tedy situace, kdy stejný test jednou trval půl hodiny a jindy hodiny dvě.

V tomto testu si oproti minule polepšil i Xen, jehož výkon je taktéž téměř shodný s výkonem hostitele.

Časy zpracování této testovací úlohy oproti loňsku poměrně výrazně vzrostly. To je dáno tím, že souborový systém XFS byl v obou případech připojován s výchozím nastavením, které se snaží zapnout bariéry zápisu. Ve starších jádrech používaných při loňských testech tyto bariéry ale nefungovaly a práce se souborovým systémem se tak značně zrychlila (na úkor spolehlivosti při výpadku napájení/pádu systému).

U novějších jader tyto bariéry fungují a zpomalení některých operací se tak poměrně výrazně projevilo na výsledcích. Používání bariér je možné vypnout a v takovém případě se výsledky vrací na úroveň těch loňských, tj. cca 5 minut běhu bez paralelizace, cca 20 minut při paralelním běhu. S intenzivnějším využíváním disků výkon hostů oproti hostiteli klesá – například pro paralelně běžící procesy jsou výsledky následující:

HostitelKVM 1/1Xen 1/1
minimum 21 m 21,146 s 26 m 17,339 s (23,1 %) 33 m 29,624 s (56,9 %)
průměr 22 m 34,113 s 29 m 51,730 s (32,3 %) 35 m 58,357 s (59,4 %)
maximum 23 m 40,744 s 33 m 2,031 s (39,5 %) 38 m 0,297 s (60,5 %)

Výsledek KVM – zpomalení o cca 30 % – je za těchto okolností stále lepší než loňský; zpomalení o 60 % u Xenu naopak představuje zhoršení.

2 Kromě Xenu, kde při druhém běhu testu zhavaroval hostitelský stroj.

CPU + práce s diskem (2)

link

Tento test byl proveden překladem jádra (výchozí konfigurace pro architekturu amd64). Jádro bylo přeloženo třikrát po sobě, každý překlad ze samostatné kopie zdrojových kódů. Na rozdíl od předchozího testu, který značně vytěžoval hlavně disky, je v tomto případě více využíván procesor a úložiště spíše okrajově.

Měřena byla doba běhu testu, tj. celková doba překladu ze tří kopií zdrojových kódů.

1. Test bez paralelizace

link

Test byl proveden na hostiteli a porovnáván s během na hostu KVM 1/1 a Xen 1/1

HostitelKVM 1/1Xen 1/1
real 27 m 48,667 s 30 m 50,461 s (+10,9 %) 32 m 27,040 s (+16,7 %)

2. Test sedmi paralelně běžících procesů

link

Na hostiteli byl proveden test sedmi paralelně běžících testovacích procesů, které byly omezeny na používání pouze sedmi CPU v systému. Výsledek byl porovnáván s během na hostech varianty 1/1.

HostitelKVM 1/1Xen 1/1
minimum 29 m 44,016 s 34 m 13,551 s (+15,1 %) 34 m 51,304 s (+17,2 %)
průměr 32 m 0,349 s 34 m 43,744 s (+8,5 %) 37 m 14,287 s (+16,3 %)
maximum 35 m 43,761 s 35 m 9,168 s (-1,6 %) 40 m 31,374 s (+13,4 %)

3. Test 28 paralelně běžících procesů

link

Tento test byl míněn víceméně jako zátěžový, cílem bylo zjistit, jestli nedojde k pádu/zatuhnutí některého z hostů. Na hostiteli se netestovalo, testována byla varianta hostů 1/4.

KVM 1/4Xen 1/4
minimum 148 m 33,887 s 163 m 30,013 s
průměr 168 m 31,165 s 173 m 47,092 s
maximum 172 m 12,143 s 176 m 4,901 s

4. Test na strojích o různém výkonu

link

Obdobně jako u podobného testu využívání CPU bylo spuštěno 19 testovacích procesů, z toho 16 na hostech 1/4 a 3 na hostech 1/1. Opět bylo cílem zjistit, jak dobře dokáží jednotlivá virtualizační řešení zajistit rozdíly ve výkonu, když je požadujeme.

KVMXen
1/1 46 m 6,961 s 48 m 26,857 s
1/4 149m 18,316 s 146m 56,358 s
po měr 3.,37 3.,32

Shrnutí

link

Na rozdíl od minula podává KVM lepší výkony než Xen – vzhledem k podstatnému zlepšení práce KVM s diskem se zlepšil i výsledek v tomto testu. Při překladu na jediném hostu si Xen o něco pohoršil, při paralelním běhu si pohoršil o něco více.

U obou virtualizačních řešení se zhoršilo udržování nastaveného výkonu, zátěžový test hosty opět zvládly bez problémů.

Práce se sítí

link

Práce se sítí byla testována nástrojem netperf (verze 2.4.4-5 z repozitáře Debianu). Provedeny byly test počtu transakcí, které je možné uskutečnit mezi dvěma stroji (test TCP_CRR, výsledkem je počet transakcí za sekundu), a test propustnosti mezi těmito hosty (test TCP_STREAM, výsledek je udán v milionech bitů za sekundu). Všechny testy byly pětkrát opakovány.

ssh 192.168.150.1$a "sleep 5 ; netperf -t TCP_CRR -H 192.168.150.1$((a+1))" &

Test začíná pětivteřinovým čekáním, aby se hostitel stihl připojit na testované hosty bez čekání a tedy aby se všechny testy spustily pokud možno naráz. Za a je ve for cyklu dosazováno podle počtu testovaných strojů.

1. Tři paralelně běžící testy

link

Test proběhl na šesti 1/1 hostech, testovalo se v párech, tzn. první host se připojoval na druhý, třetí host na čtvrtý atd.

TCP_CRR KVM 1/1 Xen 1/1
minimum 618,10 0,00
průměr 631,59 1007,48
maximum 649,20 2204,25
TCP_STREAM KVM 1/1 Xen 1/1
minimum 831,58 1265,56
průměr 919,37 1357,36
maximum 988,27 1470,03

2. 14 paralelně běžících testů

link

Test proběhl na 28 hostech 1/4, testovalo se v párech.

TCP_CRR KVM 1/4 Xen 1/4
minimum 453,89 3,20
průměr 585,68 451,67
maximum 681,80 500,49
TCP_STREAM KVM 1/4 Xen 1/4
minimum 132,65 158,78
průměr 155,69 182,67
maximum 262,21 227,39

3. Test na různých variantách hostů

link

V tomto případě byl testován jeden pár hostů 1/1 proti 8 párům 1/4.

TCP_CRR KVM 1/1 Xen 1/1 KVM 1/4 Xen 1/4
minimum 710,70 825,38 627,69 655,49
průměr 717,86 833,31 656,36 714,75
maximum 725,50 839,48 682,70 768,58
TCP_STREAM KVM 1/1 Xen 1/1 KVM 1/4 Xen 1/4
minimum 796,81 339,10 104,59 67,68
průměr 850,83 479,00 157,95 284,11
maximum 997,91 864,74 292,01 397,37

Shrnutí

link

V minulém testu byla práce se sítí jednou slabinou Xenu oproti KVM. V nové verzi některé z problémů zmizely:

Na druhou stranu u testu TCP_CRR byly výsledky Xenu stále špatné – během až tří z pěti opakování testu přestala na hostech dočasně fungovat síť – buď se k nim nebylo ani možné připojit přes SSH, nebo se netperf nedokázal připojit na svůj testovaný protějšek. (Při výpočtech hodnot uvedených v tabulkách nebyly tyto případy započítány.)

KVM podalo přibližně stejné výkony jako při minulém testu, pouze se o něco snížil objem přenesených dat.

Závěr

link

Během uplynulého roku KVM učinilo značný pokrok. Nejvážnější výkonnostní problémy zmizely a výkonnost hostů se téměř ve všech ohledech zlepšila. Nová verze Xenu 4.0 si naopak pohoršila oproti starší 3.2 testované loni. Zde by bylo možné namítnout, že použitá verze 4.0.1~rc3 je verze vývojová, nicméně v rámci stabilní řady 4.0 nelze očekávat, že by se výkonnost mezi 4.0.1~rc a 4.0.1 nějak významně měnila.

KVM se tedy během roku dokázalo vypořádat se svými slabinami a stalo se tak zdatným konkurentem Xenu i v těch oblastech, kde měl Xen donedávna navrch.

Související články

Xen vs. KVM: Souboj v extrémních podmínkách
Xen - základy virtualizácie
Xen – představení, historie, budoucnost
Seriál: Virtualizace na úrovni jádra

Další články z této rubriky

Paralelizace běžných činností v konzoli pomocí GNU Parallel
Unixové nástroje – 26 (triky pro práci v Bashi)
Unixové nástroje – 25 ((s,c)fdisk, gdisk, parted a findmnt)
Linux: systémové volání splice()
Bootování ze sítě: pxelinux a kořenový adresář na NFS

Diskuse k tomuto článku

24.8.2010 00:20 VSi | skóre: 28
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Odpovědět | Sbalit | Link | Blokovat | Admin
Výborně zpracovaný článek s hodnotnými informacemi, ať už jde o výsledky nebo samotnou metodiku testů.

Vývoj KVM směrem k lepším výsledkům je očekávaný, zlášť po jeho "adopci" u Red Hatu. U XENu bych ale upozornil na problematické srovnání s předchozím testem. Použité Xen dom0 jádro 2.6.32 využívá tzv. pv-ops, což je zjednodušeně snaha více integrovat Xen s jádrem, což byl v minulosti u Xenu dost problém.

Xen pak funguje interně podstatně jinak než u jader 2.6.18, 2.6.26, nebo "aktuálního" 2.6.27. Pv-ops pro Xen dom0 je relativně nová věc, která není považována za zcela stabilní. O vlivu na výkon jsem se nic nedočetl. Stálo by tedy za vyzkoušení (minimálně v těch testech s největším propadem výkonu) použít např. 2.6.27 ze zdrojů Xen Cloud Platform, což je to samé jádro, které používá "nejvíc enterprise Xen" - Citrix XenServer. Navíc dom0 jádro a userland se doporučuje mít 32bit, což nemá vliv na možnost přidělení paměti na 4GB pro guesty, ale nemělo by to mít vliv ani na výkon, spíš na stabilitu.

Pravděpodobně si takové srovnání udělám, takže alespoň využiju metodiku popsanou v článku.
24.8.2010 00:48 kyytaM | skóre: 35 | blog: kyytaM | Bratislava
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Osobne som pri pvops jadrach zaznamenal tiez vykonove regresie, bolo to ale uz nejaky pol rok dozadu. Old-school Xen jadra su vdaka forwad-portovaniu dostupne aj vo verziach napr. 2.6.34, takze moze to byt tiez pekny test.

Druha vec je, ze Xen 4.0 priniesol mnoho noviniek, ale vela veci z noviniek nefungovalo vobec alebo nefungovalo tak, ako malo. Myslim, ze tento tyzden by mala vyjst verzia 4.0.1 s peknou nadielkou oprav (rc6 je zatial). :)
24.8.2010 07:23 ...
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Ta "adopce" nemusi priamo suvisiet s narastom vykonu, na Xen-e pracovali X rokov od zaciatku a teraz to vyzera ako slepa ulicka, ktorej sa chcu zbavit.
24.8.2010 08:29 VSi | skóre: 28
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Předpokládal jsem, že když v Red Hatu před nějakou dobou KVM přijali a teď to prodávají jako produkční věc, tak že na něm za tu dobu něco udělali. Ale přesně jsem to nezkoumal.

Xen jednu dobu skutečně vypadal, že bude mít špatnou budoucnost. Zvlášť relativně nedávno, kdy se pro dobré výsledky stále muselo používat jádro 2.6.18. Byly obavy po převzetí společností Citrix. Přijde mi ale, že teď už to tak špatně nevypadá. Citrix vyvíjí Xen a nové management API otevřeně, přechod na pv_ops by měl zajistit provoz i s vanilla jádrem.
24.8.2010 00:53 Dadam | skóre: 12 | blog: dadamovo
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Odpovědět | Sbalit | Link | Blokovat | Admin
Protože bych rád aktuální informace, zeptám se tady: můžu Xen použít jako náhradu za VirtualBox, nebo je určený pro jiný typ nasazení (třeba na serveru)?
A i B mají svoje výhody a nevýhody. Vyberte si to, co vám vyhovuje víc, a necpěte A tam, kam patří B.
24.8.2010 01:01 kyytaM | skóre: 35 | blog: kyytaM | Bratislava
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Na desktopovu virtualizaciu je Xen dost tazkopadne riesenie, ktore prinesie vo vacsine pripadov viac skody aka uzitku. KVM je vdaka standardnemu kernelu o nieco vhodnejsie.
25.8.2010 21:55 vaslaV
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Sel bych do KVM - preci jen se zda, ze ma lepsi budoucnost.
4.9.2010 10:23 Dadam | skóre: 12 | blog: dadamovo
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
OK, děkuju vám oběma za odpověď
A i B mají svoje výhody a nevýhody. Vyberte si to, co vám vyhovuje víc, a necpěte A tam, kam patří B.
24.8.2010 08:26 Let_Me_Be | skóre: 20 | blog: cat /proc/idea/current | Brno
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Odpovědět | Sbalit | Link | Blokovat | Admin
Hmm, sakra a to jsem si rikal ze bych ty dualboot Windows (co jsem nedavno nainstalovat kvuli hram) mohl nahodit do Xenu a dedikovat jim grafiku... no jeste si budu muset nejaky ten rok pockat.

Kazdopadne super clanek.
Linked in profil - Můj web - Nemůžete vyhrát hádku s blbcem. Nejdřív vás stáhne na svoji úroveň a pak ubije zkušenostmi.
24.8.2010 08:48 ha
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Odpovědět | Sbalit | Link | Blokovat | Admin
XEN ve verzi 4 má jednu velkou výhodu a to živou synchronizaci hostů na více fyzických hostitelích. Nevíte někdo, jak je na tom KVM (Kemari, ...)?
24.8.2010 13:37 melkors | skóre: 13 | blog: kdo_chce_kam
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Funguje
Heron avatar 24.8.2010 15:50 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Migrace v KVM funguje.
24.8.2010 17:29 ha
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Nemám na mysli migraci, ale fault tolerant synchronizaci - že na 2 fyzicky oddělených hostitelích běží identický systém a v případě výpadku jednoho převezme roli ten druhý. Dřív jsem četl o Kemari, je už součástí KVM nebo se musí pořád patchovat? Je stabilní? Jaký je výkon oproti živé synchronizaci v XEN 4?
24.8.2010 17:41 VSi | skóre: 28
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Tohle podle mě absolutně není možné bez silné podpory OS nebo aplikací. Nějaký odkaz by nebyl?

Běžná je fault-tolerance ve smyslu sdíleného nebo replikovaného datového úložiště, kde při pádu hostitele musí všechny VM znovu nabootovat na jiném hostiteli.

Na popsanou funkcionalitu by bylo potřeba synchronně replikovat paměť (a možná i CPU cache), na což neexistuje dostatečně rychlé rozhraní (neuvažujeme-li speciální věci jako SGI NUMAlink). Rozhodně běžný systém nemůže najednou běžet na 2 různých strojích ve fault-tolerant režimu. Instrukce nějakého programu např. vykonává 1 procesor v nějakém stroji. Ten stroj spadne, takže se přijde minimálně o obsah CPU registrů a CPU cache - jak by se z toho měl OS vzpamatovat, aby to nebylo poznat? Leda by se vrátil na nějaký kompletní snapshot (teoreticky třeba jen několik ms starý), což zase zavání např. ztrátou potvrzených transakcí v databázi.

Podobnou funkcionalitu má OpenVMS, ale i tam s tím podle mě musí aplikace počítat. Stejně tak IBM Parallel Sysplex. Reálně se tyhle věci řeší na aplikační úrovni, viz např. Oracle Real Application Cluster.
24.8.2010 18:12 ha
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
http://wiki.xensource.com/xenwiki/Xen4.0 "Remus Fault Tolerance".
24.8.2010 18:39 VSi | skóre: 28
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Díky. Zajímavé. Takže je to periodická (asynchronní) synchronizace kompletního stavu, kdy se vždy na okamžik musí zastavit virtuální CPU, udělat snapshot, a pak ho spustit a přenést snapshot na druhý systém. Podstata je v tom, že veškeré externí I/O jako síť je bufferované podle dokončení té synchronizace.

I při použití Infinibandu nebo 10GbE to nebude nic pro velkou zátěž, protože by to mělo nechutné latence. Možná pokud by existoval HW na propojení 2 (nebo víc) strojů na úrovni PCIe linek, by to bylo použitelnější. Ale pro určitou oblast použití, kde o výkonnost až tak nejde, je to skutečně zajímavé. Pokud to půjde omezit jen na replikaci disku ve stylu DRBD, která díky integraci přímo do Xenu bude efektivnější, bude oblast použití větší. Každopádně do produkční kvality to má podle mě ještě pár let vývoje a testování.
25.8.2010 22:04 vaslaV
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Loadbalancing—Automaticallyloadbalancevirtual desktops across available hosts to ensure optimal performance

http://www.redhat.com/virtualization/rhev/desktop/

Vzhledem k tomu, ze se ma zanedlouho ukazat RHEL6, zrejme se dockame take novinek u RHEV.

btw: on i slavny RAC ma sve mouchy (za urcitych okolnosti se umi pekne pokakat).
27.8.2010 10:13 chsajarsa | skóre: 16 | blog: V_hlouby_destneho_pralesa | Lovosice(Praha)
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Fault-tolerance ma i VMware. Vim,ze tam to delaji tak, ze kazdy VM potrebuje dedikovanou sitovku po ktere bezi kopie pameti. Maji tam nejaka pocitadla a je u toho stroje tolerovano urcite zpozdeni. Zkousel jsem to v praxi a funguje to docela obstojne. Ma to. ale jedno neprijemne omezeni, protoze to umoznuje, aby VM melo jen jedno CPU. Na VMwordu,ale ukazovali,ze takhle umeji chranit i konkretni aplikace (nejaka DB myslim Oracle tam byl) a fungovalo jim to i pro vice CPU. Duvod proc to nenasadili jsou patenty,ale pry uz to maji pripravene pustit to do produkce.
~ QED ~
28.8.2010 02:37 ..... Izak ..... | skóre: 14
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Ano, jinak to omezeni na 1 CPU neni fyzicky problem v bete to tam slo i na vice CPU ... je to licencni problem, nebot M$ podal zalobu na vmware a chce, aby se platila licence 2x (neb to bezi na 2 strojich) ... vmware ale tvrdi ze kdyz ji tam nelze vubec 2x zadat a ze je to jen jedna kopie a ze na 2 stroji v soucasnosti nebezi, nebot se na ni neni mozno pripojit ... takze az rozhodne soud, bude vice CPU a ukaze se, zda se bude, nebo nebude platit 2x M$ za licence vcetne programu ... ono totiz tohle kompletne zborilo jejich clustery ... neb je to levnejsi ;-)
24.8.2010 09:01 jura321
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Odpovědět | Sbalit | Link | Blokovat | Admin
Super článek, podrobný, odborný, aktuální a se zajímavou problematikou, která dnes táhne. Palec nahoru autorovi, jen více článků... jura321 PS. Uvítal bych i články pro méně zkušené, tj. např. instalace a konfigurace KVM na desktopu, vytváření sítě v kvm atd..
24.8.2010 09:47 pet
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
http://en.gentoo-wiki.com/wiki/KVM

Je to pro gentoo a je to v anglictine, ale je to polopatisticky.
Grunt avatar 25.8.2010 11:40 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
man qemu. KVM je teď sice hodně populární, ale jinak to není nic jiného než staré dobré Qemu.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
28.8.2010 02:38 ..... Izak ..... | skóre: 14
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
tak to je hezky blabol ;-)))

Z qemu to vyuziva jen definici virtualniho PC ... stejne jako Xen ;-)) ... ale virtualizace jiz probiha uplne jinak ;-))
Grunt avatar 28.8.2010 10:35 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Aha. Takže když napíšu man kvm tak to že tam naskočí:
QEMU(1)                                                                                                                                                                            QEMU(1)

NAME
       qemu-doc - QEMU Emulator User Documentation

SYNOPSIS
       usage: qemu [options] [disk_image]

DESCRIPTION
       The QEMU PC System emulator simulates the following peripherals:

       -   i440FX host PCI bridge and PIIX3 PCI to ISA bridge
je jen čistá shoda náhod, že?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
28.8.2010 13:14 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Hezkej blábol jsi vyplodil ty. KVM v podstatě není nic jiného, než náhrada jaderného modulu kqemu; o zbytek se stále stará Qemu, rozdíl je jenom v tom, že místo emulace/práce s kqemu využívá systémová volání, které poskytuje kvm.

Quando omni flunkus moritati
24.8.2010 11:33 none
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Odpovědět | Sbalit | Link | Blokovat | Admin
Chvalim chvalim! Dobry clanek, presne to jsou informace, ktere me zajimaji! Je jasny, ze KVMko v oblasti virtualizace jde dopredu a bude 'the best of' v linuxu. Xen jen pomalu vymira. Diky vyvojarum jadra a RH je KVM na vzestupu. Jen jednu pripominku k forme - nemohlo by byt formatovani vysledku treba v tabulkach? A jeste vetsiho efektu by bylo dosazeno peknymi barevnymi grafy.

Jeste jednou chvalim a diky!
24.8.2010 11:35 Robert Krátký | skóre: 94 | blog: Robertův bloček
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
nemohlo by byt formatovani vysledku treba v tabulkach?
Ono to je v tabulkách... máš na mysli orámování políček?
24.8.2010 12:11 none
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Mas pravdu, je to v tabulkach. Prislo mi to na prvni pohled takove neusporadane a spatne citelne. Ramecek by tomu pomohl a mozna i lepsi zarovnani hodnot.
24.8.2010 13:58 Robert Krátký | skóre: 94 | blog: Robertův bloček
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Tak jsem se to pokusil vylepšit. Doplnil jsem zarovnání čísel doprava a ohraničení tabulek.
24.8.2010 14:04 none
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Diky, zda se to byt lepsi...
24.8.2010 14:10 VSi | skóre: 28
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Je jasny, ze KVMko v oblasti virtualizace jde dopredu a bude 'the best of' v linuxu. Xen jen pomalu vymira.
To je otázka, u které bych si nebyl tak jistý. Xen byl převzat Citrixem, postavili na něm dost dalších produktů, umřít ho jen tak nenechají. Mohli Xen uzavřít, neudělali to, a vývoj je otevřený v rámci projektu Xen Cloud Platform (název se veze na aktuálním buzzwordu cloud, ale v podstatě jde o open-source bázi XenServeru a nového RPC-XML XEN API).
24.8.2010 16:01 none
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
No mas asi pravdu, ze to neni jednoznacne, ale prinejmensim velmi pravdepodobne. Velkou vyhodou KVM je to, ze je ve vanila jadre a ma zajistenou podporu komunity. Diky linuxove filozofii bude KVM jediny hypervizor v jadre a ze by ho mel nahradit Xen si prilis nedovedu predstavit. Vnimam to tak, ze je tady KVM a ti ostatni, kteri se budou muset ohanet aby si svuj utrzeny kus kolace udrzeli. Nejsem si jisty, jestli je Citrix XenServer OpenSource, nevis jak to je?
24.8.2010 16:03 none
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Odpovim si sam: http://virtualization.info/en/news/2010/02/citrix-xenserver-is-now-open-source.html
28.8.2010 02:52 ..... Izak ..... | skóre: 14
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
No v distribucich je Xen mrtvy o tom zadna, ale XenEnterprise je zivotaschopny ...

Me na nem nastaval pouze jedna vec, udelal jsem upgrade pres DVD (jina nesla), pak mi nsel dat novy klic na dalsi rok, byly spatne klice, tak jsem to opravil podle fora na citrixu a zase prd, jen uz to psalo zase neco jineho ... do toho ta jeho hloupa instalace, ktera porad tvrdi, ze zformatuje disk ... nastesti to nedela, kdyz tam neco je, ale presto rika, ze data znici ... na zabiti tohle ... a aby toho nebylo malo, tak upgrade na versi, ktera chybu nemela nesla ani pres patch, ani pres DVD ... takze tim u me XenEnterprise skoncil a byl nahrazen KVM ... KVM nastesti prevezme virt. stroje bez problemu, jen jsem si prejmenoval ten bordel, co XenEnt. udela na LVM ;-)) na neco humanreadable ....

Ale jako XenEnt. je jinak fajn produkt ... bude zit z jednoho duvodu, protoze Citrix jej vyuziva, maji i XenApp a jine veci, tedy integruji jej do svych produktu a tim padem je budou jejich zakaznici pouzivat jako bonus ... zbytek je nezajima ... hold budou mit 90% v citrix produktech a aplikacich a treba 10% v ostatnich pripadech ...
24.8.2010 13:02 Lupic
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Odpovědět | Sbalit | Link | Blokovat | Admin
Zajímalo by mě ještě srovnání toho samého stroje s pokud by bylo nainstalováno VMWARE ESXi v4. Nebo nemáte někdo porovnání?
24.8.2010 13:14 kyytaM | skóre: 35 | blog: kyytaM | Bratislava
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Pokial viem, licencia VMware neumoznuje vykonovat a publikovat benchmarky.
24.8.2010 13:21 Lupic
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
to je ale škoda, několik esxi provozujeme a pokud bude další virt. stroj potřeba,tak by KVM by mohlo přicházet v úvahu.
24.8.2010 14:33 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Hm, to zní jako "náš produkt je krám, takže vám zakazujeme to říkat nahlas"
Quando omni flunkus moritati
Heron avatar 24.8.2010 15:40 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Podobnou doložku najdeš u mnoha produktů. Má to svůj smysl.
25.8.2010 06:27 TomCat1 | skóre: 10
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Má to svůj smysl.
Jiný, než zmiňuje trekker.dk?
Have you tried turning it off and on again?
Věroš avatar 25.8.2010 08:47 Věroš | skóre: 24 | blog: Co není v hlavě | 49.29 s.š., 16.54. v.d.
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Oficiální důvod je "Nechceme, abyste dělali benchmarky při suboptimálním nastavení".

Neoficiální může být různý. :-)
Školím Ansible
Heron avatar 25.8.2010 10:24 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Jistě, že ano.
27.8.2010 16:19 Jozef Vondrák | skóre: 19
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
To je ale náhodička, našel jsem takový skripty tak jsem je spustil a vypadly z toho tydle čísílka ... tak se na vás obracím jestli nevíte co to znamená?
28.8.2010 02:39 ..... Izak ..... | skóre: 14
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
neumoznuje, ale proc se ji zabyvat ze ... zvlaste v CR ... ja ac jsem VCP, tak jsem zadnou NDA nepodepisoval ;-))
24.8.2010 14:35 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Článek se zabývá pouze FOSS řešeními a nemám v plánu na tom něco měnit (obzvlášť ne vzhledem k informaci zmíněné níže, ještě se tak nechat žalovat od nějakých neschopáků, to určitě...)
Quando omni flunkus moritati
Heron avatar 24.8.2010 15:45 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Dělali jsme interní testy pro naše potřeby mezi KVM a ESX3 (plné, nikoliv ESXi) a výkonově jsou obě virtualizace srovnatelné (co také čekat u plně HW virtualizace).

Rozdíly tedy nejsou ve výkonu ale ve službách kolem. Vmware toho nabízí daleko více. Pochopitelně za jiné peníze.
28.8.2010 02:42 ..... Izak ..... | skóre: 14
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
ESX3 a plna virtualizace bych moc nespojoval ;-)) ... to snad u ESX4, ktery uz umi i vyuzit HW-Virt, umi skutecne adresovat RAM a jine feature ;-))
24.8.2010 15:43 JoHnY2
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Odpovědět | Sbalit | Link | Blokovat | Admin
Meril jste nekdo rozdil mezi pouzitim qcow2/raw a LVM?

Slysel jsem, ze se za posledni rok hodne zlepsilo prave qcow2. Docela by me to zajimalo, protoze pro moje snazeni je qcow2/raw vyrazne sikovnejsi nez LVM, kde nemuzu s imagema zonglovat po siti jak me napadne.
24.8.2010 15:52 anon123 | skóre: 35 | blog: ganomi
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Odpovědět | Sbalit | Link | Blokovat | Admin
Clanek je hezky, ale mel bych par vyhrad.

Myslim, ze autor by si mel ujednotit co je to HOST a co je to VM. Nemluvime o konfiguraci Xenu ci KVM hostitele, ale konfiguraci VM (Virtualniho Masiny/Stroje). Dale by se mel zminovat jen o VM a ne stroj. Stroj muze byt chapan jako HOST.

Sam moc nechapu co je to Xen 1/1. Kolikrat nevim, jestli jste testovaci script spoustel na Hostiteli ci ve Virtualnim stroji.

Pro me osobne by bylo jednodusi videt tabulku s: XEN, 4x VM - 7 vCPU, 2GB RAM, atd.

Dale bych rozebral ten script. Dost zalezi, jestli dany program zvlada multithreading ci ne a jak dobre.

Zrovna ted resim python script (single thread), ktery se vykona mnohem rychleji, kdyz jadro napinuji, nez kdyz necham vsechny jadra k pouziti. Prepinani mezi jadry tvori vyssi reziji (Credit scheduler).

Xen ted vyuziva Credit Scheduler (vychozi). Vyber applikace ma tedy velky vliv na test.

Docela, by bylo zajimave udelat mix VMs, jako clovek najde v normalnim prostredi a merit idle time. Kolikrat, kdyz vidim VMware oproti Xenu (stejne prostredi), tak Xen je proste lepsi a hbytejsi.

Jinak by nebyl spatny napad nechat bezet xentrace na hostu, kdyz bezi test ve VM a pak analyzovat (xenanalyze), jak se vyuzivaji jadra a kde by mohl byt problem ve vykonu.

Kdyz budu mit cas, tak ten scriptik overim s xentrace/xenanalyze a pak sem hodim analyzu, jakym zpusobem se ty jadra vyuzivaji.

Jinak diky za tu praci. Fakt to je makacka. Delal jsem takovou analyzu na 2D performance se single/multiprocesor HAL ve Windows XP VM. Prace je to hodne...
27.10.2010 14:19 jimik
Rozbalit Rozbalit vše Re: Xen vs. KVM: Souboj v extrémních podmínkách 2010
Odpovědět | Sbalit | Link | Blokovat | Admin
Prosím jak omezit výkon cpu jednotlivých virtuální hostů pod KVM?

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.