CRIU 1.0 - userspace checkpoint / restore eszköz Linuxra

Címkék

A virtualizációs szoftvermegoldásairól ismert Parallels alkalmazásában álló Pavel Emelyanov tegnap bejelentette a Linux Kernel Mailing List-en, hogy (több évnyi fejlesztés után) elérhető a CRIU 1.0-s kiadása. A CRIU jelentése: Checkpoint/Restore In Userspace. A CRIU egy olyan (nagyrészt) userspace szoftvereszköz Linuxhoz, amelynek segítségével "megfagyaszthatunk" egy futó alkalmazást (vagy annak egy részét), pillanatnyi állapotát lemezre írhatjuk (checkpointing). Majd ezen lemezre írt fájl(ok) segítségével később az alkalmazás állapotát visszaállíthatjuk a "fagyasztáskori" állapotra és onnan újra futtathatjuk. Akár egy másik rendszeren is.

Hogy mire lehetne ezt használni?

Hozzászólások

Ez még hasznos is lehet. A kérdés az, hogy milyen kompromisszumokkal jár.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Eddig ez miért nem volt? :-)

Tán' még a "KSplice" (vagy hogy hívják!) is búcsúzhat az egyeduralomtól? :-)

Amennyire én látom, a ksplice lényege, hogy a futó kerneled bizonyos részeit tudod kicserélni javított vagy módosított utasítássorra. Ez a cucc inkább azt tenné lehetővé, hogy a szolgáltatások és programok leállítása majd bootolás utáni újbóli elindítása helyett elmentsd a rendszered aktuális állapotát, normál módon betöltsd az új kerneled, majd annak a tetején "userspaceben" visszatérj pont oda, ahol a mentést csináltad.

Nagyjából értem a különbséget (bár nem vagyok programozó).
Külön köszönöm ezt a leegyszerűsített leírást.

Őszintén, mibe (mekkora munkába) kerülne egy ilyen Ksplice helyettesítő kiváltása, elkészítése?
Konkrétan engem az zavar - persze ezt az Oralce szíve-joga eldönteni -, hogy az openSUSE részére INGYENESEN miért nem érhető el ez a csoda "kernelkavaró" alkalmazás (nem mintha ezen múlna az életem...)?
Ebből a szempontból az Ubuntu és tsai mitől, miért kivételek?

„Konkrétan engem az zavar - persze ezt az Oralce szíve-joga eldönteni -, hogy az openSUSE részére INGYENESEN miért nem érhető el ez a csoda "kernelkavaró" alkalmazás (nem mintha ezen múlna az életem...)?
Ebből a szempontból az Ubuntu és tsai mitől, miért kivételek?”

Lehetséges, hogy az Ubuntu mögött álló cég fizet nekik ezért…? :think:

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Nem feltetlenul. Ha a Canonical allna a koltseget, mar mindenhol azt nyomatnak, hogy milyen jofejek.

Ubi serverre fizetos a szolgaltatasuk, es gondolom nem jon nekik rosszul a nagyon hasonlo betateszter tabor. Ha mar ott vannak az onkentes kiserleti nyulak, akkor celszeru minel kevesebb plusz munkaval megoldani a tesztet (per tesztelo).

Plusz a beetetes marketingvonzata is szamithat (ha egy rendszergazda desktopon es serveren is ezt a disztrot hasznalja, es desktopon ingyen mar raszokott, a cegnel is valoszinubb, hogy kibulizza a licencet).

--
Why did the chicken cross the road?
It was trying to get a signal on its iPhone 4.

"Konkrétan engem az zavar - persze ezt az Oralce szíve-joga eldönteni -, hogy az openSUSE részére INGYENESEN miért nem érhető el ez a csoda "kernelkavaró" alkalmazás "

A Ksplice GPLv2 cucc. A forrása letölthető, szabadon módosítható stb. Maga a technológia adott mindenki számára.

Bárki - akár az openSUSE is - csinálhat saját repót, ahonnan a saját Ksplice-a húzza a saját frissítéseit. Hogy miért nem csinál? Azt az openSUSE-től kéne megkérdezni. Lehet, hogy ők nem tartják a technológiát érdekesek, értelmesnek stb.

--
trey @ gépház

Vajon mit szól az egyszerű kis alkalmazás, ha hirtelen bezáródik minden fájl/pipe/socket/etc leíró? Van pár probléma, amit a suspend miatt is meg kell oldani, de azért van sok új is, ha nem a teljes rendszer állapotával játszunk.

--

Debugnál visszafele lépés lehetősége! Bár ez főleg IDE integráción áll vagy bukik. VMware-nek volt erre (windows-only) megoldása, de csak Visual studio-val volt integrálva.

BTW volt már hasonló tool: http://home.gna.org/jockey/
---
Régóta vágyok én, az androidok mezonkincsére már!

gdb mar tudja egy ideje. bar a jelenlegi target hatranya hogy amint engedelyezed elkezd minden egyes gepi utasitast logolni (hogy aztan vegre tudja hajtani visszafele), ami iszonyat lassu, na meg a memoriat jo gyorsan megeszi. es igazabol nem vagom debugnal ez hol segitene, minden egyes vegrehajtott programsornal/gepi utasitasnal/akarmi csinalna egy snapshotot? az se lenne gyorsabb

I hate myself, because I'm not open-source.