Virtualizációs technikák, technológiák
A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
a (→Virtualizációs technikák csoportositasa: szerző lemaradt) |
Bc (vitalap | szerkesztései) a (helyesírási hibák, szóhasználat) |
||
1. sor: | 1. sor: | ||
− | Adott: |
+ | Alternatívák: |
− | * sok-sok PC a Salgó polcon: mindegyik valamelyik osztályé, tanszéké, haveré, ügyfélé stb.; vagy |
+ | * adott sok-sok PC a salgó polcon: mindegyik valamelyik osztályé, tanszéké, haveré, ügyfélé stb.; vagy |
− | * egy nagy szerver, ami Sokmindent Csinál. |
+ | * adott egy nagy szerver, ami "Sokmindent Csinál". |
− | Baj a sok-sok PC-vel: |
+ | A sok PC esetében fellépő problémák: |
− | * A Salgó Polcon Álló PC Nem Professzionális; |
+ | * A salgó polcon álló PC nem professzionális; |
− | * ha gagyik: |
+ | * ha a PC-k ósdiak, megbízhatatlanok, „gagyik”: |
− | ** lefagynak - ilyenkor oda kell menni és belerúgni; |
+ | ** gyakran lefagynak - ilyenkor fizikai jelenlét szükséges az újraindításhoz; |
− | ** kereshetünk bele való gagyi hardvert; |
+ | ** meghibásodás esetén kereshetünk beléjük való „gagyi” hardvert; |
** papírfecnivel ki kell ékelni a processzorhűtőt; |
** papírfecnivel ki kell ékelni a processzorhűtőt; |
||
** poroltót kell tartani a közelben. |
** poroltót kell tartani a közelben. |
||
− | * ha újak, esetleg márkásak: |
+ | * ha újak, megbízhatóak, esetleg márkásak: |
− | ** bonyolultabb és/vagy sokkal drágább lesz az alkatrészcsere, amikor elromlik; |
+ | ** bonyolultabb és/vagy sokkal drágább lesz az alkatrészcsere, ha elromlanak; |
− | ** fáj, hogy Ott Az A Szép Nagy Gép És Nem Is Csinál Semmit; |
+ | ** „Ott Az A Szép Nagy Gép És Nem Is Csinál Semmit” szindróma, azaz gyakran kihasználatlanok az erőforrások; |
− | ** sok áramot fogyaszt; |
+ | ** sok áramot fogyasztanak; |
− | ** sok hőt ad le (drága lesz a légkondi). |
+ | ** sok hőt adnak le - megnövekedett hűtési (légkondícionáló) igények. |
− | * ha nem mi menedzseljük őket: |
+ | * ha a gépeket mások menedzselik: |
** a rendszergazdák folyton elfelejtik a rootjelszót, és mehetünk oda a konzolhoz betörni; |
** a rendszergazdák folyton elfelejtik a rootjelszót, és mehetünk oda a konzolhoz betörni; |
||
** a rendszergazda lusta, dilettáns, rosszhiszemű és rosszindulatú; |
** a rendszergazda lusta, dilettáns, rosszhiszemű és rosszindulatú; |
||
26. sor: | 26. sor: | ||
* ha mi menedzseljük őket: |
* ha mi menedzseljük őket: |
||
− | ** akkor is macerás mindig odamenni a konzolhoz, amikor valamelyiknek valami baja van; |
+ | ** akkor is problémás mindig odamenni a konzolhoz, amikor valamelyik gépnél probléma lép fel; |
** LOM (Lights Out Management) megoldás lehet erre, de elég drága. |
** LOM (Lights Out Management) megoldás lehet erre, de elég drága. |
||
− | Baj az egy nagy szerverrel, ami Sokmindent Csinál: |
+ | Az egy nagy szerverrel kapcsolatos problémák: |
− | * az Ezen A Héten Divatos Projekt fejlesztőjének azonnal kell a még csak bétában elérhető PHP 8.0, de |
+ | * az EzenAHétenDivatosProjekt fejlesztőjének azonnal kell a még csak bétában elérhető PHP 8.0, de |
* ennek lefordításához és futtatásához kell az új, szintén béta libc6, viszont |
* ennek lefordításához és futtatásához kell az új, szintén béta libc6, viszont |
||
− | * a Múlt Héten Divatos És Még Mindig Fontos Projekt fejlesztői által írt alkalmazás az előző libc6 egy olyan "nemdokumentált funkcióját" használja ki, ami az új libc6-ban nincs benne; valamint |
+ | * a MúltHétenDivatosÉsMégMindigFontosProjekt fejlesztői által írt alkalmazás az előző libc6 egy olyan „nem dokumentált” funkcióját használja ki, ami az új libc6-ban nincs benne; valamint |
* kernelt is kell cserélni, mert a jelenlegiben túl régi az a NagyonTáposAPI, amit a szintén szükséges új Java is használ, de |
* kernelt is kell cserélni, mert a jelenlegiben túl régi az a NagyonTáposAPI, amit a szintén szükséges új Java is használ, de |
||
− | * a Menedzsment Által Preferált Kereskedelmi Csoportmunka-Alkalmazás kizárólag a Sun Java 1.3.02 litván nyelvű változatának 1633-as buildjével működik helyesen. |
+ | * a MenedzsmentÁltalPreferáltKereskedelmiCsoportmunka-Alkalmazás kizárólag a Sun Java 1.3.02 litván nyelvű változatának 1633-as buildjével működik helyesen. |
* Rövidebben: a különböző funkciókhoz tartozó szoftverek között túl sok lehet az összefüggés, így az egyiknek az upgrade-je interferálhat egy másikkal. |
* Rövidebben: a különböző funkciókhoz tartozó szoftverek között túl sok lehet az összefüggés, így az egyiknek az upgrade-je interferálhat egy másikkal. |
||
41. sor: | 41. sor: | ||
* Legyen egy (vagy több, de kevés) nagyteljesítményű, rendkívül megbízható szerverünk, és |
* Legyen egy (vagy több, de kevés) nagyteljesítményű, rendkívül megbízható szerverünk, és |
||
− | * ezeken külön virtuális szerverekben futtassuk az egyes kisPC-ket vagy a Sokmindent Csináló Gép egyes funkcióit. |
+ | * ezeken külön virtuális szerverekben futtassuk az egyes kis PC-ket vagy a Sokmindent Csináló Gép egyes funkcióit. |
− | Sok virtualizációs megoldás van, ezek sokmindenben hasonlítanak, és meg több mindenben különböznek; most nem megyünk bele. |
+ | Sok virtualizációs megoldás létezik, amelyek sokmindenben hasonlítanak, és meg több mindenben különböznek. Ezeket most nem részletezzük. |
== Virtualizációs technikák == |
== Virtualizációs technikák == |
||
− | Ez most az aktuális buzzword. A gyári 2.6.19-ben bizonyos előkészületek már lesznek a virtualizáció támogatására. |
+ | Ez most az aktuális „buzzword”. A gyári 2.6.19-ben bizonyos előkészületek már lesznek a virtualizáció támogatására. |
Addig is a legfontosabb megoldások: |
Addig is a legfontosabb megoldások: |
||
57. sor: | 57. sor: | ||
=== chroot === |
=== chroot === |
||
− | * Csak fájlrendszer-szintű szétválasztás: |
+ | * csak fájlrendszer-szintű szétválasztás: |
* a System V IPC közös, a két különböző chrootban azonos UID-del futó processzek küldhetnek egymásnak signalt stb.; |
* a System V IPC közös, a két különböző chrootban azonos UID-del futó processzek küldhetnek egymásnak signalt stb.; |
||
* egy chrootnak nem lehet saját IP-je, saját tűzfalszabályai; |
* egy chrootnak nem lehet saját IP-je, saját tűzfalszabályai; |
||
− | * két chrootban ugyanolyan UID alatt futó processzek küldhetnek egymásnak signalt; stb. |
+ | * két chrootban ugyanolyan UID alatt futó processzek küldhetnek egymásnak signalt stb. |
* nem igazán lehet egy-egy chroot erőforrásfoglalását korlátozni. |
* nem igazán lehet egy-egy chroot erőforrásfoglalását korlátozni. |
||
− | ** Nincs diszk-kvóta; |
+ | ** nincs diszk-kvóta; |
** nem méltányos az osztozkodás a CPU-n, a hálózaton, a diszken; |
** nem méltányos az osztozkodás a CPU-n, a hálózaton, a diszken; |
||
** live migrációról pedig ne is álmodjunk. |
** live migrációról pedig ne is álmodjunk. |
||
− | * A FreeBSD jailje azért biztosít hálózati leválasztást, tehát a jailben futó alkalmazásnak lehet saját IP-je. |
+ | * a FreeBSD jailje biztosít hálózati leválasztást, tehát a jailben futó alkalmazásnak lehet saját IP-je |
=== [[vserver]] === |
=== [[vserver]] === |
||
107. sor: | 107. sor: | ||
* Checkpointing segítségével egy élő VE migrálható fizikai gépek között. |
* Checkpointing segítségével egy élő VE migrálható fizikai gépek között. |
||
* Külön eszközzel támogatja az új VE fájlrendszerének létrehozását. |
* Külön eszközzel támogatja az új VE fájlrendszerének létrehozását. |
||
− | * Egy közepes PC 1G RAMmal akár 100 VE-t is gond nélkül futtathat (mindegyikben apache-val és sshd-val). |
+ | * Egy közepes PC 1G RAM-mal akár 100 VE-t is gond nélkül futtathat (mindegyikben apache-csal és sshd-vel). |
* x86, amd64, ia64, ppc |
* x86, amd64, ia64, ppc |
||
118. sor: | 118. sor: | ||
* Természetesen minden guestnek saját, korlátos memóriája van, de használhat saját swapet. |
* Természetesen minden guestnek saját, korlátos memóriája van, de használhat saját swapet. |
||
* A guestek: |
* A guestek: |
||
− | ** saját tűzfalszabályokat állíthatnak be; |
+ | ** saját tűzfalszabályokat állíthatnak be |
− | ** szabadon mountolhatnak fájlrendszereket (persze csak azok közül, amikhez hozzáférnek); |
+ | ** szabadon mountolhatnak fájlrendszereket (persze csak azok közül, amikhez hozzáférnek) |
− | ** egyszerűen kaphatnak közvetlen hozzáférést fizikai diszkhez vagy LV-hez, amin aztán olyan filerendszert csinálnak, amilyet csak akarnak. |
+ | ** egyszerűen kaphatnak közvetlen hozzáférést fizikai diszkhez vagy LV-hez, amin aztán olyan fájlrendszert hoznak létre, amilyet csak akarnak. |
* Az UML elvileg titkosíthatja a saját fájlrendszerét úgy, hogy a hosztgép üzemeltetője ne tudja elolvasni (kivéve a rootfs-t). |
* Az UML elvileg titkosíthatja a saját fájlrendszerét úgy, hogy a hosztgép üzemeltetője ne tudja elolvasni (kivéve a rootfs-t). |
||
* A hosztgépen debugolhatjuk a guest kernelt (ha kernelfejlesztők vagyunk). |
* A hosztgépen debugolhatjuk a guest kernelt (ha kernelfejlesztők vagyunk). |
||
* Elvileg az UML hibája miatt nem fagyhat szét a hosztgép kernele. |
* Elvileg az UML hibája miatt nem fagyhat szét a hosztgép kernele. |
||
− | * Nem (feltétlenül) kell hozzá kernelt patchelni (legalábbis ezen a héten). |
+ | * Nem (feltétlenül) szükséges hozzá kernelt patchelni (legalábbis ezen a héten). |
− | * Nem kell annyi fizikai memóriával rendelkezni, amennyit elosztogatunk a guestek között (használhatnak swapet). |
+ | * Nem szükséges annyi fizikai memóriával rendelkezni, amennyit elosztogatunk a guestek között (használhatnak swapet). |
* 64 bites hoszton futtathatunk 32 bites guestet (a Xen pl. ezt nem tudja). |
* 64 bites hoszton futtathatunk 32 bites guestet (a Xen pl. ezt nem tudja). |
||
* Bonyolult virtuális hálózati topológiákba szervezhetjük az UML-eket anélkül, hogy a valódi hálózatra kilátnának. |
* Bonyolult virtuális hálózati topológiákba szervezhetjük az UML-eket anélkül, hogy a valódi hálózatra kilátnának. |
||
− | * Egy vendéggép konzolját kirakhatjuk egy tcp portra, úgyhogy elérhető lehet a hálózatról anélkül, hogy neki magának lenne hálózati kapcsolata (a TCP-kapcsolat a hoszttal épül fel). |
+ | * Egy vendéggép konzolját kirakhatjuk egy tcp portra, így elérhetővé válik a hálózatról anélkül, hogy neki magának lenne hálózati kapcsolata (a TCP-kapcsolat a hoszttal épül fel). |
* Eleinte a guestben gyakorlatilag nem volt memóriavédelem, mivel a hosztkernel szempontjából egyetlen processz volt az egész (ez ma már szerencsére nem igaz). |
* Eleinte a guestben gyakorlatilag nem volt memóriavédelem, mivel a hosztkernel szempontjából egyetlen processz volt az egész (ez ma már szerencsére nem igaz). |
||
* x86, IA64, PowerPC, Sparc? |
* x86, IA64, PowerPC, Sparc? |
||
134. sor: | 134. sor: | ||
=== Xen === |
=== Xen === |
||
− | * "Paravirtualizáció" (de most már tud hardvereset is: Vanderpool, Pacifica) |
+ | * „Paravirtualizáció” (de most már tud hardvereset is: Vanderpool, Pacifica) |
* Hypervisor, Dom0, DomU |
* Hypervisor, Dom0, DomU |
||
* A Xen virtuális gépei idővel futni fognak a Longhorn hypervisora alatt is. |
* A Xen virtuális gépei idővel futni fognak a Longhorn hypervisora alatt is. |
||
153. sor: | 153. sor: | ||
=== Emuláció === |
=== Emuláció === |
||
− | * teljes hardware architektura emuláció. |
+ | * teljes hardver architektúra emuláció |
− | * emulalt processzor lehet eltero a host cpu-tol. |
+ | * emulált processzor lehet eltérő a host cpu-tól |
− | * guest OS-t nem kell modositani. |
+ | * guest OS-t nem kell módositani |
− | * x86: [http://bochs.sourceforge.net/ Boch], [http://fabrice.bellard.free.fr/qemu/ Qemu] (gyorsitas nelkuli) |
+ | * x86: [http://bochs.sourceforge.net/ Boch], [http://fabrice.bellard.free.fr/qemu/ Qemu] (gyorsítás nélküli) |
=== Full/Native virtualizáció === |
=== Full/Native virtualizáció === |
||
− | * hardware architektura emuláció, de kihasznalja, hogy a host geppel azonosat emulal. |
+ | * hardver architektúra emuláció, de kihasználja, hogy a host géppel azonosat emulál |
− | * csak ua processzort tud emulalni, mint amin a host van. |
+ | * csak ugyanolyan processzort tud emulálni, mint amin a host van |
− | * guest OS-t nem kell modositani. |
+ | * guest OS-t nem kell módositani |
− | * tobb guest is lehet. |
+ | * több guest is lehet |
* x86: [http://kvm.sourceforge.net/ KVM], [http://www.vmware.com/ VMWare] (Iron, Workstation, Server) |
* x86: [http://kvm.sourceforge.net/ KVM], [http://www.vmware.com/ VMWare] (Iron, Workstation, Server) |
||
− | === Paravirtualizacio === |
+ | === Paravirtualizáció === |
− | * nem feltetlen emulal, hanem spec API-n keresztul eri el a guest a hardwaret |
+ | * nem feltétlen emulál, hanem speciális API-n keresztül éri el a guest a hardvert |
− | * guest OS-t modositani kell |
+ | * guest OS-t módositani kell |
* x86: [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ Xen] |
* x86: [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ Xen] |
||
− | * x86, IA-64, PPC: [http://user-mode-linux.sourceforge.net/ UML] (csak linux) |
+ | * x86, IA-64, PPC: [http://user-mode-linux.sourceforge.net/ UML] (csak Linux) |
− | === OS-level virtualizacio === |
+ | === OS-level virtualizáció === |
− | * a guest es host OS/kernel ugyanaz, guestek szeparalva vannak a hosttol |
+ | * a guest és host OS kernel ugyanaz, guestek szeparálva vannak a hosttól |
* kis overhead |
* kis overhead |
||
* unix: chroot |
* unix: chroot |
||
− | * linux: [[vserver]], OpenVZ |
+ | * Linux: [[vserver]], OpenVZ |
* FreeBSD: jail |
* FreeBSD: jail |
||
* [http://en.wikipedia.org/wiki/Operating_system-level_virtualization Wikipedia - OS-level virtualization] |
* [http://en.wikipedia.org/wiki/Operating_system-level_virtualization Wikipedia - OS-level virtualization] |
||
184. sor: | 184. sor: | ||
=== Virtual hosting === |
=== Virtual hosting === |
||
− | * ugyanazon a fizikai szerveren egy web szerver tobb kulonbozo domain nev alatt nyujt kulonbozo szolgaltatasokat |
+ | * ugyanazon a fizikai szerveren egy web szerver több különböző domain név alatt nyújt különböző szolgáltatásokat |
* lehet name-based vagy IP-based |
* lehet name-based vagy IP-based |
||
* pl: Apache Virtualhost |
* pl: Apache Virtualhost |
A lap 2007. január 19., 14:05-kori változata
Alternatívák:
- adott sok-sok PC a salgó polcon: mindegyik valamelyik osztályé, tanszéké, haveré, ügyfélé stb.; vagy
- adott egy nagy szerver, ami "Sokmindent Csinál".
A sok PC esetében fellépő problémák:
- A salgó polcon álló PC nem professzionális;
- ha a PC-k ósdiak, megbízhatatlanok, „gagyik”:
- gyakran lefagynak - ilyenkor fizikai jelenlét szükséges az újraindításhoz;
- meghibásodás esetén kereshetünk beléjük való „gagyi” hardvert;
- papírfecnivel ki kell ékelni a processzorhűtőt;
- poroltót kell tartani a közelben.
- ha újak, megbízhatóak, esetleg márkásak:
- bonyolultabb és/vagy sokkal drágább lesz az alkatrészcsere, ha elromlanak;
- „Ott Az A Szép Nagy Gép És Nem Is Csinál Semmit” szindróma, azaz gyakran kihasználatlanok az erőforrások;
- sok áramot fogyasztanak;
- sok hőt adnak le - megnövekedett hűtési (légkondícionáló) igények.
- ha a gépeket mások menedzselik:
- a rendszergazdák folyton elfelejtik a rootjelszót, és mehetünk oda a konzolhoz betörni;
- a rendszergazda lusta, dilettáns, rosszhiszemű és rosszindulatú;
- emiatt viszonylag nehezen tudunk rendet tartani a hálózatban.
- ha mi menedzseljük őket:
- akkor is problémás mindig odamenni a konzolhoz, amikor valamelyik gépnél probléma lép fel;
- LOM (Lights Out Management) megoldás lehet erre, de elég drága.
Az egy nagy szerverrel kapcsolatos problémák:
- az EzenAHétenDivatosProjekt fejlesztőjének azonnal kell a még csak bétában elérhető PHP 8.0, de
- ennek lefordításához és futtatásához kell az új, szintén béta libc6, viszont
- a MúltHétenDivatosÉsMégMindigFontosProjekt fejlesztői által írt alkalmazás az előző libc6 egy olyan „nem dokumentált” funkcióját használja ki, ami az új libc6-ban nincs benne; valamint
- kernelt is kell cserélni, mert a jelenlegiben túl régi az a NagyonTáposAPI, amit a szintén szükséges új Java is használ, de
- a MenedzsmentÁltalPreferáltKereskedelmiCsoportmunka-Alkalmazás kizárólag a Sun Java 1.3.02 litván nyelvű változatának 1633-as buildjével működik helyesen.
- Rövidebben: a különböző funkciókhoz tartozó szoftverek között túl sok lehet az összefüggés, így az egyiknek az upgrade-je interferálhat egy másikkal.
Tartalomjegyzék |
1 Az elképzelt megoldás
- Legyen egy (vagy több, de kevés) nagyteljesítményű, rendkívül megbízható szerverünk, és
- ezeken külön virtuális szerverekben futtassuk az egyes kis PC-ket vagy a Sokmindent Csináló Gép egyes funkcióit.
Sok virtualizációs megoldás létezik, amelyek sokmindenben hasonlítanak, és meg több mindenben különböznek. Ezeket most nem részletezzük.
2 Virtualizációs technikák
Ez most az aktuális „buzzword”. A gyári 2.6.19-ben bizonyos előkészületek már lesznek a virtualizáció támogatására.
Addig is a legfontosabb megoldások:
2.1 Apache Virtualhost
- igazából max. viszonyítási alapnak illik ide
2.2 chroot
- csak fájlrendszer-szintű szétválasztás:
- a System V IPC közös, a két különböző chrootban azonos UID-del futó processzek küldhetnek egymásnak signalt stb.;
- egy chrootnak nem lehet saját IP-je, saját tűzfalszabályai;
- két chrootban ugyanolyan UID alatt futó processzek küldhetnek egymásnak signalt stb.
- nem igazán lehet egy-egy chroot erőforrásfoglalását korlátozni.
- nincs diszk-kvóta;
- nem méltányos az osztozkodás a CPU-n, a hálózaton, a diszken;
- live migrációról pedig ne is álmodjunk.
- a FreeBSD jailje biztosít hálózati leválasztást, tehát a jailben futó alkalmazásnak lehet saját IP-je
2.3 vserver
- Olyan mint a chroot, csak jobb.
- Minden virtuális gép ugyanazon a kernelen fut.
- Minimális overhead, úgyhogy gyors.
- Pl. az összes vserver osztozik a diszk-cache-en.
- Cserébe ha borul a kernel, az egész rendszer borul.
- A vservereket logikailag teljesen szétválasztja egymástól:
- IPC,
- processzkezelés,
- saját IP.
- Viszont: nem lehet fájlrendszereket mountolni a guestben, és
- a host automatikusan hozzáfér a guest összes adatához.
- Elvileg változtatás nélkül elindul vserverben a legtöbb Linux-disztribúció.
- Egyáltalán nincs szükség emulációra
- Még olyan eszköz is van, ami megkeresi több guestben az azonos tartalmú fájlokat, és összehardlinkeli őket; de ha valamelyik írna bele, megszűnik a hardlink.
- Ehhez persze a vservereknek egy fájlrendszeren kell lenniük (de elvileg van vserver-szintű diszk-kvóta, úgyhogy annyira nem baj).
- Megadhatunk egy-egy vserverre vonatkozó erőforráslimiteket.
- Egy vserver migrálása nagyon egyszerű: tar.
- A vserver hálózati konfigurációját a hoszt állítja be, úgyhogy a migráció tényleg teljesen átlátszó a vserver számára.
- De: még mindig nem tudunk saját tűzfalszabályokat adni a virtuális gépeknek, és nem csinálhatunk komplex virtuális routingot sem.
- Sajnos patchelni kell a kernelt.
- Nincs IPv6-támogatás.
Ilyesmi lehet a FreeVPS és az OpenVZ is. Házi feladat. :)
Kedvcsinálónak:
2.4 OpenVZ
- Olyasmi, mint a vserver (egy kernelen fut az összes virtuális gép).
- De pl. a VE-knek (Virtual Environment) lehet saját routingja és tűzfala.
- A PID-kat virtualizálja, így az init mindig megkapja az 1-est.
- Virtualizálja a /proc és a /sys fájlrendszereket is (a vserver csak részben - konkrétumok?).
- A VE-k megkaphatnak valódi hardvert, pl. sorosportot, hálózati interfészt.
- A VE-k erőforráskorlátai menet közben növelhetők és csökkenthetők(!).
- A CPU-t méltányosan ütemezi az egyes VE-k között.
- Checkpointing segítségével egy élő VE migrálható fizikai gépek között.
- Külön eszközzel támogatja az új VE fájlrendszerének létrehozását.
- Egy közepes PC 1G RAM-mal akár 100 VE-t is gond nélkül futtathat (mindegyikben apache-csal és sshd-vel).
- x86, amd64, ia64, ppc
2.5 User Mode Linux
- Egy linuxos hoszton több guest kernelt futtathatunk, mindegyik kisszámú userspace processznek látszik.
- Viszonylag gyors (CPU-korlátos műveletek esetén közel natív teljesítmény, I/O esetén jelentősen lassúbb).
- Minden guest-rendszerhívást emulálni kell.
- A hardver kezelését a hoszt kernel végzi, a guest kernel csak hardver-absztrakciókkal találkozik.
- Természetesen minden guestnek saját, korlátos memóriája van, de használhat saját swapet.
- A guestek:
- saját tűzfalszabályokat állíthatnak be
- szabadon mountolhatnak fájlrendszereket (persze csak azok közül, amikhez hozzáférnek)
- egyszerűen kaphatnak közvetlen hozzáférést fizikai diszkhez vagy LV-hez, amin aztán olyan fájlrendszert hoznak létre, amilyet csak akarnak.
- Az UML elvileg titkosíthatja a saját fájlrendszerét úgy, hogy a hosztgép üzemeltetője ne tudja elolvasni (kivéve a rootfs-t).
- A hosztgépen debugolhatjuk a guest kernelt (ha kernelfejlesztők vagyunk).
- Elvileg az UML hibája miatt nem fagyhat szét a hosztgép kernele.
- Nem (feltétlenül) szükséges hozzá kernelt patchelni (legalábbis ezen a héten).
- Nem szükséges annyi fizikai memóriával rendelkezni, amennyit elosztogatunk a guestek között (használhatnak swapet).
- 64 bites hoszton futtathatunk 32 bites guestet (a Xen pl. ezt nem tudja).
- Bonyolult virtuális hálózati topológiákba szervezhetjük az UML-eket anélkül, hogy a valódi hálózatra kilátnának.
- Egy vendéggép konzolját kirakhatjuk egy tcp portra, így elérhetővé válik a hálózatról anélkül, hogy neki magának lenne hálózati kapcsolata (a TCP-kapcsolat a hoszttal épül fel).
- Eleinte a guestben gyakorlatilag nem volt memóriavédelem, mivel a hosztkernel szempontjából egyetlen processz volt az egész (ez ma már szerencsére nem igaz).
- x86, IA64, PowerPC, Sparc?
2.6 Xen
- „Paravirtualizáció” (de most már tud hardvereset is: Vanderpool, Pacifica)
- Hypervisor, Dom0, DomU
- A Xen virtuális gépei idővel futni fognak a Longhorn hypervisora alatt is.
- Hardveres virtualizációval fut benne a Windows XP is.
- Tud live migrációt: apránként átmásolja a domU-t egy másik gépre, majd 1 másodpercnél rövidebb idő alatt átkapcsol rá.
- x86, amd64, ia64, ppc; Sparc készülőben
- dom0-ban lehet: Linux, NetBSD (hamarosan FreeBSD is).
- paravirtualizált domU-ban lehet: Linux, NetBSD, FreeBSD, Minix, Plan9, OpenSolaris, NetWare
- Létezik paravirtualizált Windows XP is, csak a licencfeltételek miatt nem adhatja ki a University of Cambridge.
- Később lesz róla szó részletesebben is.
Szalai Ferenc előadásának fóliái
3 Virtualizációs technikák csoportositasa
(Írta: NSzabolcs)
3.1 Emuláció
- teljes hardver architektúra emuláció
- emulált processzor lehet eltérő a host cpu-tól
- guest OS-t nem kell módositani
- x86: Boch, Qemu (gyorsítás nélküli)
3.2 Full/Native virtualizáció
- hardver architektúra emuláció, de kihasználja, hogy a host géppel azonosat emulál
- csak ugyanolyan processzort tud emulálni, mint amin a host van
- guest OS-t nem kell módositani
- több guest is lehet
- x86: KVM, VMWare (Iron, Workstation, Server)
3.3 Paravirtualizáció
- nem feltétlen emulál, hanem speciális API-n keresztül éri el a guest a hardvert
- guest OS-t módositani kell
- x86: Xen
- x86, IA-64, PPC: UML (csak Linux)
3.4 OS-level virtualizáció
- a guest és host OS kernel ugyanaz, guestek szeparálva vannak a hosttól
- kis overhead
- unix: chroot
- Linux: vserver, OpenVZ
- FreeBSD: jail
- Wikipedia - OS-level virtualization
3.5 Virtual hosting
- ugyanazon a fizikai szerveren egy web szerver több különböző domain név alatt nyújt különböző szolgáltatásokat
- lehet name-based vagy IP-based
- pl: Apache Virtualhost
4 Ajánlott irodalom
- Nem ajánlott: Projects on the move, ismeretterjesztő cikk többek között a virtualizációs technikákról. Óvatosan olvassátok, vannak benne marhaságok (pl. "As each VServer has its own init process, it can launch services with their own IP addresses." - nem igaz, igaz, nincs összefüggés). Azért szerepel itt, mert a google esetleg kidobja, mint találatot.
- Egy thread a debian-administration.org fórumán a virtualizációs technikákról.
- Annotated HOWTO for creating an SELinux enabled UML system - szakácskönyv.
- Comparison of virtual machines
- ZAP - userspace-ben megvalósított processz-migráció Linuxra