A lap 2010. november 30., 15:54-kori változata

--Tmarlok 2010. november 30., 13:49 (UTC)

1 Xen-ről általában

A Xen egy nyílt forráskódú paravirtualizációs megoldás. Biztonságosan tud futtatni több virtuális gépet ugyanazon a hoszton, közel natív futási sebességgel.

1.1 Bemutatkozás

A Xen többféle hardverarchitektúrát támogat, úgymint: x86 (PAE támogatással), x86/64 és IA64. A paravirtualizációhoz egy módosított kernel szükséges. Támogatja a hardveres virtualizációs technológiát (az Intel és az AMD megoldását is), amire a módosítatlan kernelt használó guest operációs rendszereknek van szüksége (Windows többnyire - létezik paravirtualizált Windows XP is, csak a licencfeltételek miatt nem adhatja ki a University of Cambridge).

Xen 4.0 fiécsörök:

• 128 virtuális CPU
• 1 TB RAM HVM esetén, paravirtualizáció esetén 512 GB
• USB eszközök csatolása guest-hez
• live migration (vm átköltöztethető kikapcsolás nélkül, majd átkapcsolás a másik rendszerre)

1.2 Paravirtualizáció

A paravirtualizáció az a virtualizációs technika, amelyben a guest operációs rendszert módosítjuk, hogy egy speciális API-n keresztül érjék el a hardvert. Ezzel a technikával közel natív futási sebességet érhetnek el a guest OS-ek is, szemben például azzal a megoldással, ahol a teljes hardverarchitektúrát a host OS emulálja (elképzelhető, ez milyen overhead-et jelent). Ráadásul a nyílt forrású operációs rendszerek kernelének módosítása könnyen kivitelezhető, így akár magunk is fordíthatunk például egy minimális, csak a szükséges drivereket tartalmazó kernelt a nekünk tetsző processzorarchitektúrára, amit aztán guest OS használni fog (általában azonban a XEN terjesztés kínál számunkra ilyen kernelt).

1.3 Felépites

A Xen áll egy hypervisor rétegből, ez épül be a hardver és a guest OS-ek közé. Ez felel guest-ek ütemezéséért, az egyes guest-ek pedig a számukra kiosztott időben a saját alkalmazásaikat ütemezhetik. Van egy kiemelt fontosságú guest, a dom0 (Általában linux, de lehet NetBSD vagy OpenSolaris). Ez bootoláskor automatikusan létrejön és speciális jogkörrel rendelkezik. Ő hozza létre a többi guest-et, menedzseli a virtuális device-okat (a virtuális gépek nem a valódi hardvert látják, hanem ezeket), valamint adminisztrálja a többi guest-et.

A dom0-án fut a xend nevű processz ami a domU-k adminisztrációjáért felel, és hozzáférést ad azok konzoljához.

1.4 Alkalmazási példa: Potemkin VMM

(átemelve a korábbi Xen szócikkból)

• A UCSD-n (University of California, San Diego) van egy üresen álló A osztályú címtartomány, amit "Network Telescope"-nak használnak
• Ide normális esetben nem jön csomag; ha mégis, akkor az pl. ész nélkül próbálkozó portscan vagy féreg
• Nosza, rakjunk bele honeypotokat, hogy lássuk, mit csinálnak a megtámadott gépek
• Csakhogy: kinek van tizenhatmillió-hétszázhetvenhétezer-kétszáztizennégy számítógépe? (Talán a Google-nak... :)
• Megoldás: pár tucat PC, mindegyiken egy módosított Xen
• A domU-kban különféle Windowsok, párféle szolgáltatásmixszel
• Ha érdekesnek tűnő csomag jön be, akkor a cél-IP-hez párszáz milliszekundum alatt klónoznak egy új domU-t egy meglevőből úgy, hogy a memóriája copy on write szemantikával allokálódik, tehát amihez nem nyúl, azon osztozik az eredeti példánnyal
• Így egy PC-n százával lehet (nagyon hasonló) virtuális gépeket futtatni
• Ha az új Windows semmi izgalmasat nem csinál a csomaggal, egyszerűen megszüntetik
• Ha ő is elkezd miatta kommunikálni, akkor megtartják egy darabig és nézik, mit csinál
• Az Internet felé nem tud új kapcsolatot nyitni, ha megpróbálja, az egy új virtuális géphez jut el (így a fertőzések dinamikája is nyomon követhető)
• Pár tucat PC segítségével látszólag megtölthető gépekkel egy /8-as hálózat...

2 Xen telepítése

A legkönnyebb módszer csomagból feldobni, van ahol ez működik is. Sajnos például Ubuntu Maverick-nél a nem működik ez (broken dependencies), ugyhogy nem mindig ússzuk meg a forrásból telepítést.

2.1 Telepítés csomagból (Debian)

Ha olyan oprendszert használunk, amely tartalmazza csomagként a xen-t a módosított xen-es kernellel (Debian Lenny például), akkor jól jártunk. Föltelepítjük a szükséges csomagokat:

apt-get install xen-linux-system-2.6.26-2-xen-amd64
apt-get install xen-tools

és újraindításkor már a xen-es kernelt bootoljuk be.

2.2 Telepítés forrásból

TODO (Ez eddig nem sikerült)

2.3 Egyéb beállítások

Érdemes a domU-kat LVM partíciókra tenni, így gyorsabb lesz a guest, ehhez létre kell hoznunk egy volume groupot:

pvcreate /dev/sdxY
vgcreate <volume_group_neve> /dev/sdxY

A logical volume-okat majd a xen-tools létrehozza telepítéskor.

Érdemes még a hálózati interfészt beállítani a domU-knak, amit az /etc/xen/xend-config.sxp file-ban tehetünk meg. Én bridge-et állítottam be:

(network-script network-bridge)
(vif-script vif-bridge)

3 Debian guest telepitese

Elsőként egy Debian Lenny guest telepítését mutatom be, mert ez a legegyszerűbb (főleg ha a dom0 is ugyanez a rendszer) és a legtöbb esetben elég is.

A virtuális gép létrehozásához a xen-toolst érdemes használni (van más módszer is, de számomra ez tűnt e legegyszerűbbnek). Úgy működik, hogy a hozzá tartozó konfigurációs file-ban megadjuk, hogy milyen guest-et szeretnénk, majd ez alapján legeneráljuk azt.

A Lenny-t létrehozó konfiguráció: (file helye: /etc/xen-tools/xen-tools.conf):

lvm = <a_letrehozott_volume_group>
install-method = debootstrap
size = 4Gb                   # Disk image size.
memory = 128Mb               # Memory size
swap = 256Mb                 # Swap size
# noswap = 1                 # Don't use swap at all for the new system (ez nem kell nekünk)
fs = ext3                    # use the EXT3 filesystem for the disk image (nyilván lehet más is)

dist = etch                  # Default distribution to install. (fel van még sorolva pár támogatott disztró)

dhcp = 1                     # megadhatunk statikus ip beállításokat is, a minta benne van a konfigfile-ban kikommentezve
passwd = 1
kernel = /boot/vmlinuz-`uname -r`              # így a dom0 kernelét használjuk a létrehozandó guest-hez
initrd = /boot/initrd.img-`uname -r`
arch=amd64                                     # lehet persze i386 is
mirror = http://ftp.hu.debian.org/debian/

Ha ezzel megvagyunk, hozzuk létre a guest-et a következő paranccsal:

xen-create-image --hostname <vm_neve> --role udev

A dolog eltarthat egy darabig, mert a netről húzza le az oprendszert (azért maradjunk gép előtt mert majd kér egy root jelszót az újszülött guestnek). Ha elkészültünk, még adjuk hozzá az elkészült vm leírófile-jához (/etc/xen/<vm_neve>.cfg) a következő sort:

extra = "xencons=tty"

Enélkül nem kapnénk konzolt a vm-hez.

Az új virtuális gépet a következő paranccsal indíthatjuk el:

xm create /etc/xen/<vm_neve>.cfg

Egyéb fontos parancsok:

xm list                # listázza a virtuális gépeket
xm console <vm_neve>   # csatlakozás az adott vm konzoljához
xm shutdown <vm_neve>  # vm leállítása
xm destroy <vm_neve>   # vm törlése
xm help                # az összes egyéb parancs listázása

Pár megjegyzés:

• Ne lepődjünk meg, ha listázásnál azt írja, hogy az állapot b (blokkolt), és a time értéke nem nagyon növekszik. Ez normális, a vm alszik, amíg nincs mit csináljon.

• ha xm console-al csatlakozunk a vm konzoljára, QUIT signallal (Ctrl-\) lehet kilépni a guest konzoljáról.

• xm destroy parancs után a teljes image törléséhez és a logical volume-ok megszüntetéséhez adjuk ki a következő parancsot:

xen-delete-image lv-guest-01

4 Windows XP guest telepítése

TODO

5 Források, olvasnivaló

TODO (plusz telerakni linkekkel a szöveget)

• Xen hivatalos dokumentációk
• Xen a Wikipedián
• Szalai Ferenc előadásának fóliái
• A xen 3.0.x korlátai