Keď hypervízor padá: ako sme diagnostikovali problém KVM na AMD Opteron

Domov / Blog / Keď hypervízor padá: ako sme diagnostikovali problém KVM na AMD Opteron
26.10.2026 Z našej IKT dielne

Po prechode internej testovacej inštancie platformy IWCP na Ubuntu 24.04 LTS sa na časti serverov s AMD Opteron začali objavovať pády jadra Linuxu. Ukazujeme, ako sme problém izolovali, stabilizovali prevádzku a pripravili lepšie podklady na ďalšiu diagnostiku.

Virtualizačná platforma má jednu dôležitú úlohu: udržať virtuálne servery v chode aj vtedy, keď pod nimi beží zložitá kombinácia hardvéru a softvéru. Čo sa však stane, keď problém vznikne priamo na hostiteľovi, ktorý tieto virtuálne servery obsluhuje?

Pri aktualizácii našej internej testovacej inštancie platformy IWCP sme narazili na takýto scenár – a popri hľadaní príčiny sme sa sústredili aj na to, aby sa prevádzka po prípadnom páde obnovila čo najrýchlejšie.

Čo sa stalo po aktualizácii na Ubuntu 24.04 LTS

V auguste 2026 sme aktualizovali osem virtualizačných serverov HP ProLiant z Ubuntu 22.04 na Ubuntu 24.04 LTS. Servery s procesormi Intel fungovali bez problémov. Na piatich serveroch s procesormi AMD Opteron 6386 SE sa však do 24 hodín objavil pád jadra Linuxu s hlásením Attempted to kill the idle task.

Dopad bol širší než výpadok jednej virtuálnej mašiny. Ak spadol hypervízor – fyzický server, ktorý prevádzkuje virtuálne servery – prestali fungovať všetky virtuálne servery na danom hostiteľovi. Navyše mohol hostiteľ zostať zamrznutý celé hodiny, čo predlžovalo obnovu testovacej platformy IWCP TEST.

Najprv dostupnosť, potom príčina

Pri podobnom incidente treba oddeliť dve úlohy: dostať službu späť do prevádzky a zároveň zistiť, prečo k problému došlo.

Ako prvý krok sme preto AMD servery vrátili na staršie, overené jadro Linuxu. Tým sme znížili bezprostredné prevádzkové riziko a získali priestor pokračovať v analýze.

Následne sme približne dva mesiace porovnávali správanie rôznych verzií jadra, vyhodnocovali systémové záznamy a dopĺňali výsledky testov pre komunitu Ubuntu a vývojárov jadra.

Keďže sa pády neobjavovali v pravidelných intervaloch, niekedy až po niekoľkých dňoch,  krátky beh bez incidentu sme nepovažovali za dostatočný dôkaz stability.

Čo nám napovedali logy a testy

Na jednotlivých serveroch sme paralelne skúšali rôzne verzie jadra a porovnávali, pri ktorých zostavách sa problém prejavoval. Takýto postup pomáha identifikovať súvislosti, sám osebe však neurčuje konkrétnu chybnú zmenu v zdrojovom kóde.

Konzolové výstupy a systémové logy nasmerovali ďalšie skúmanie na KVM (Kernel-based Virtual Machine), virtualizačnú technológiu integrovanú v jadre Linuxu. Prvotná chyba v tejto oblasti predchádzala zamrznutiu hostiteľa.

Hlásenie Attempted to kill the idle task sme preto vyhodnocovali spolu s udalosťami, ktoré mu predchádzali, nie ako úplné vysvetlenie príčiny.

Súbežne sme preverovali aj hardvér. Kontrola pamäťových radičov a hardvérových logov nepreukázala chybu pamäte ani procesora. Rozdielne správanie serverov Intel a AMD podporilo ďalšie skúmanie interakcie jadra Linuxu, KVM a platformy AMD Opteron.

Presný mechanizmus chyby však v čase prípravy článku zostával predmetom analýzy.

 

 

Spolupráca s vývojármi Ubuntu

Problém sme nahlásili vo verejnom systéme Launchpad a priebežne sme do hlásenia dopĺňali logy, pozorovania a výsledky testov. Vývojári jadra Ubuntu tak mohli nadväzovať na doterajšie zistenia a porovnávať ich s výsledkami ďalších skúšok.

Takáto spolupráca má význam aj mimo jedného prostredia: diagnostické podklady môžu pomôcť pri skúmaní podobných problémov na porovnateľnom hardvéri.

Naše výsledky však opisujú konkrétnu kombináciu serverov, procesorov a verzií jadra. Nemožno ich automaticky preniesť na všetky KVM nasadenia s Ubuntu 24.04 LTS.

Automatická obnova a podrobnejšia diagnostika

Popri hľadaní príčiny sme upravili správanie serverov pri chybe. Podľa pozorovaní v našom prostredí sa hostiteľ namiesto dlhého zamrznutia automaticky reštartuje do 30 sekúnd a virtuálne servery sa následne spúšťajú automaticky.

Celkový čas obnovy sa tak skrátil z hodín na minúty.

Na všetkých serveroch sme zároveň nasadili kdump. Tento nástroj zbiera výpis pamäte pri páde jadra, aby bolo možné následne podrobnejšie preskúmať stav systému v okamihu incidentu.

Automatický reštart pomáha skrátiť výpadok; kdump zasa zvyšuje šancu získať dáta potrebné na vysvetlenie príčiny.

 

Čo sme si z toho odniesli

V čase prípravy článku bežali AMD servery na vybraných novších jadrách Ubuntu Linuxu viac ako mesiac bez zaznamenaného pádu. Je to povzbudivý výsledok sledovania IWCP TEST, nie však dôkaz definitívnej opravy. Analýza s vývojármi jadra Ubuntu pokračuje.

Z tejto skúsenosti si odnášame niekoľko praktických poznatkov:

  • Pri problémoch hypervízora treba riešiť stabilitu, čas obnovy aj kvalitu diagnostických dát.
  • Návrat na overenú verziu jadra môže stabilizovať prevádzku a vytvoriť priestor na systematické testovanie.
  • Automatizovaná obnova znižuje dopad incidentu, kým kdump poskytuje podrobnejšie dáta na ďalšiu analýzu.
  • Pri zriedkavých a nepravidelných pádoch treba testovať dostatočne dlho a závery formulovať podľa toho, čo merania skutočne potvrdzujú.

Tento prípad nám pripomenul, že spoľahlivosť IT infraštruktúry nestojí len na odstránení chyby. Dôležité je vedieť rýchlo obnoviť prevádzku, zachytiť dostatok diagnostických dát a spolupracovať s odborníkmi pri hľadaní príčiny. Práve kombinácia technických skúseností, systematického prístupu a dobre navrhnutých riešení pomáha minimalizovať dopady incidentov na prevádzku služieb.

Podobné princípy sú dôležité aj pri budovaní a prevádzke cloudovej infraštruktúry. Ak vás zaujíma, aké možnosti prináša cloud od InterWay, pozrite si IwayCloud.

 

 

 

 

 

 

IWAYNEWS
Kariéra 6