Co nejstrucneji popisu sekvenci udalosti, jez se projevovaly tim, ze mym milym
uzivatelum nebyly k dispozici sluzby serveru.
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. Predesilam, ze tez nevim o zadnem problemu
noveho hardwaru, hypervisor OS slape stabilne, sw RAIDy ok celou dobu.
Doma jsem si to vsechno od 20.10. zkousel a odzkousel, virtualizace krasne
slapala.
(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
v pohode.)
Naucil jsem se tunu veci, 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 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
bridgingu, 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 to s nesmyslne dlouhymi a nepravidelnymi 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). Rikali jsme si s ostatnima virtualikama, ze pockame par
hodin, jestli nedojde k desynchronizaci.
Vcera: 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. 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? :-)
Dnes rano me vzbudil mobil, rada z vas uzivatelu mi davala vedet, ze virtual
nekomunikuje. Dekuju vsem za zpravu a ze jste s otazkami pockali. Po
nastartovani me domaci tovarny na uzasnosti 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 vypada, ze sit je
stabilni. Ale at to nezakriknu. :-(
Trpel tim jen nas hlavni virtual, druhy podobne NATovany virtual pohoda.
tcpdump z hypervizoru smerem k virtualu ukazoval ARP dotazy bez odpovedi.
tcpdump z virtualu se zase ptal 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 jsem 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 rebootovat.
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 provedl aktualizaci jadra hlavniho virtualu na nejnovejsi
backport 2.6.26 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.
Mohl bych si ty hrozne cenny zkusenosti nechat pro sebe. Ale protoze budou za
rok dva stejne zastaraly, je to jedno. Treba to nekdo z vas vyuzije.
Tuttle
automaticky spravce
|
