Anabaze jedne virtualizace

Vlada Macek macek na sandbox.cz
Sobota Listopad 15 20:27:24 CET 2008


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



Další informace o konferenci Linux