Anabaze jedne virtualizace

[Tomáš Koželuh]

Já jsem si toho zase docela dost užil s VMware + SUSE 10 x64 + HP Proliant.
Výsledek byl nakonec ten, že VMware Server 1.0.x je portovaný z Windows a ne
zrovna dokonale a Prolianty můžou mít problémy se sdílením IRQ, což může
vést k dost nepěknýmu propadu výkonu, takže zdaleka nejvýkonnější varianta
byla návrat na Windows Server jako hostovací OS.
Takže pokud někdo bojujete především se slabým diskovým výkonem na VMware
Server, zkuste verzi 2.0, ale pravděpodobně zdaleka nejrychlejší varianta
jsou Windows jako hostovací OS.

> -----Original Message-----
> From: linux-bounces na linux.cz [mailto:linux-bounces na linux.cz] On Behalf
> Of Vlada Macek
> Sent: Saturday, November 15, 2008 8:27 PM
> 
> Cil: Presunout 32bitovy Debian Etch na skutecnem hardwaru rsyncem na
> virtualni stroj pod 64bitovym Ubuntu 8.04 pomoci KVM. Vsechen software
> z baliku prislusnych distribuci.
> 
> Cesta: I pres predchozi pripravu a testovani rada rebootu, hodiny
> offline, nevim ale o zadne ztrate dat.
> 
> Mohl bych si ty hrozne cenne zkusenosti nechat pro sebe. Ale protoze
> budou za rok dva stejne zastaraly, je to jedno. Treba to nekdo z vas
> vyuzije. Tezko predam po textu pocity stresu, ktery jsem radu dni
> zazival, kdyz ted ma vetsina z vas vedle sebe kaficko a dorticek. Ale
> proc taky, ty pocity znate z vlastnich prusvihu. :-)
> 
> Popisu sekvenci udalosti, jez se projevovaly tim, ze mym milym
> uzivatelum nebyly radu hodin k dispozici dulezite sluzby serveru.
> 
> Poznamka: "Novy" hw koupeny z druhe ruky (Intel Quad-Core EM64T)
> neprojevil po celou dobu zadne zavady, hypervisor OS slapal stabilne,
> sw RAIDy celou dobu ok.
> 
> Doma jsem si to vsechno od 20.10. zkousel a odzkousel ke sve vysledne
> spokojenosti.
> 
>     Tedy ne ze by nebyly zadne potize. Z tech nezapomenutych: Kdyz se
>     jak disky, tak cdrom emulovaly jako IDE, tak bylo cteni
> instalacniho
>     CD ukrutne pomaly a v logu virtualu bylo tak po pul minute: "DSC
>     timeout". Na netu jsem nasel vykriky, ale zadne jasne reseni. Po
>     hodinach ladeni jsem prisel na to, ze kdyz po vytvoreni virtualni
>     masiny prepnu disk na jinou emulaci (SCSI), tak pohoda.
> 
> Naucil jsem se tunu veci, napr. jak nastavovat sitovani (potrebuju
> bridging i nat). Vyladil rsync a data presunul z ostreho stroje.
> Pripravil jsem si prikazy, abych v housingu uz jen provedl posledni
> synchronizaci. Pred tydnem (6.11.) jsem starou masinu v Praze (100km
> vzdalene) nahradil novou. Dobry.
> 
> Pristi den mi volali, ze muj stroj odpovida na IP pozadavky urcene
> ruznym jinym strojum. Meli z toho velkou radost. Mozna to bylo moji
> nezkusenosti s bridgingem, po dni zkoumaji a ladeni jsem zatrhl
> odpovedi pomoci iptables. A oddechl si, ze zrejme nebudu potrebovat
> ebtables, protoze to podle tcpdumpu vypadalo, ze po ARP stroj
> nereaguje.
> 
> Asi pristi den jsme zjistili nesmyslne dlouhe a nepravidelne sleepy a
> ze to nebude trivialita. Den trvalo, nez jsem dosel k tomu, ze pricina
> je v nekvalitni simulaci hardwarovych hodin -- jednotlive virtualni CPU
> dostaly vyrazne ruzny pocet tiku, takze po sobe spousteny prikaz date
> ukazoval skakani casu tam a zpet. Moc mily, demoni z toho byli na
> vetvi.
> 
> Dalsi pulden na odladeni reseni. Dalsi rebooty, kdy jsem zapnul emulaci
> ACPI a vynutil, aby virtualy pouzivaly doporucovane
> "clocksource=acpi_pm" (parametr jadra).
> 
> Pred tremi dny: Kratce po tomto prepnuti hodin zacal virtual
> "prituhavat". Proste nepravidelne tak na minutu vytuhnul, rekneme 1-4x
> za pul hodiny. Pak vse jelo rychle jako predtim. Vzdy po rozebehnuti
> load pekne pomalu klesal ze 40 az na nulu. Rikal jsem si, jestli to
> nebude zase chybou v prijmu tiku hodin.
> 
> Kdepak. V logu byla pri kazdem zmrznuti hromada hlasek jako: "sd
> 0:0:0:0: ABORT operation started. ", "sd 0:0:0:0: ABORT operation
> timed-out.", "sd 0:0:0:0: DEVICE RESET operation started.".
> 
> To uz jsem ale v noci usinal, jen jsem si nasel na netu, ze to manik
> vyresil prepnutim na IDE. Ze jsem prve ja rucne prepinal na SCSI kvuli
> jine chybe, to jsem psal vyse. Dobry, co? :-)
> 
> Hned rano me vzbudil mobil, rada z uzivatelu mi davala vedet, ze
> virtual nekomunikuje. Po nastartovani me domaci tovarny na uzasnosti a
> pripojeni k virtualu pres VNC jsem zjistil, ze "pouze" nejde sitovani.
> Bal jsem se, ze je nestabilni virtualizace, ale pres VNC jsem se
> pripojil na konzoli. Virtual byl opusten a velmi, velmi klidny.
> 
> To bylo v 9:15. A teprve po peti hodinach usilovne prace to vypadalo,
> ze sit je stabilni. Ale at to nezakriknu. :-(
> 
> Trpel tim jen hlavni virtual, druhy, podobne NATovany virtual pohoda.
> tcpdump z hypervizoru smerem k virtualu ukazoval ARP dotazy bez
> odpovedi. tcpdump z virtualu se zase ptal po ARP na hypervizor a taky
> bez odpovedi.
> 
> Na IRC mi rekli, ze jde o znamy bug implicitne emulovane sitovky
> rtl8139 a ze mam prepnout na e1000 nebo virtio. To druhe kvuli starym
> verzim ledaceho nemam k dispozici. Tak jsem prepnul na e1000 (zaroven
> prehodil disky z SCSI na IDE za pouziti UUID v /etc/fstab) a po rebootu
> zoufale sledoval, jak sit zmrzla znova. Sice pozdeji, ale prec. Zkousel
> jsem ruzne veci zmenene za poslednich 24 hodin vratit zpatky a zas a
> zas rebootoval.
> 
> Behem chvile na IRC jsem se dozvedel radu zajimavych informaci o
> libvirt. Kdyz jsem se otazal, kde jsou dokumentovane, dostal jsem
> odpoved "ted jsou ve tvem IRC". :-)
> 
> Vypadalo to vytrvale tak, ze po bootu virtualu sit chvili sla a kdyz
> boot skoncil, zase zmrzla. Pres VNC jsem mel ke konzoli pristup stale.
> Ten druhy virtual (Ubuntu Intrepid) porad nemel se siti problemy.
> 
> Nakonec jsem nerad provedl aktualizaci jadra hlavniho virtualu na
> 2.6.26
> (backporty) a v teto situaci stroj zatim pracuje a poskytuje sluzby.
> Bylo nacase, protoze dalsi napad na reseni uz nemam. Mel jsem zato, ze
> kdyz nevyjde to, pujdu se venovat vcelarstvi.
> 
> Ted uz muzete KVM vsichni vyzkouset, nema zadne jine chyby. :-)
> 
> Vlada Macek