A lap 2012. február 3., 12:29-kori változata

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

1 Xenrő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, ami a nyílt forrású operációs rendszereknél könnyen megoldható. Hogy a nem módosított kernelt tartalmazó operációs rendszereket is futtathassuk Xen alatt, a Xen támogatja a hardveres virtualizációs technológiát (az Intel és az AMD megoldását is). Erre általában a Windows-ok miatt van szükség ( létezik paravirtualizált Windows XP is, csak a licencfeltételek miatt nem adhatja ki a University of Cambridge).

Pár Xen 4.0 fícsör:

• 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 érje 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 a guest OS használni fog (általában azonban a Xen terjesztés kínál számunkra ilyen kernelt).

1.3 Felépítés

A Xen áll egy hypervisor rétegből (ez épül be a hardver és a guest OS-ek közé), valamint a guest rendszerekből (domainek). 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). Bootoláskor a hypervisor automatikusan elindítja a dom0-t, ami aztán létrehozza 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

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

apt-get install linux-image-2.6-xen-amd64 xen-hypervisor-4.0-amd64 xen-utils-4.0

és újraindításkor már a xenes kernelt bootoljuk be.

Érdemes a domU-kat LVM partíciókra tenni, így gyorsabb lesz a guest, mintha image file(ok)-ra tennénk. 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 Guest rendszerek telepítése

3.1 Debian

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 a 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                                     # az architektúra, amit a debootstrap lehúz a netről, 64 bites hoszt rendszerek esetén kell megadni, hogy milyen legyen a userspace
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>

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).

Az új virtuális gépet a következő paranccsal indíthatjuk el (a <vm_neve>.cfg file-t a xen-create-image hozza létre, ez tartalmazza a vm beállításait, amit az xm minden indításkor innen olvas ki):

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

3.2 Windows XP

Ehhez szükség van arra, hogy a processzor támogassa a hardveres virtualizációt. Ezt Intel processzornál a következő paranccsal tudjuk ellenőrizni:

xm dmesg | grem VMX

Először telepítsük a xenwatch és a xen-qemu-dm-4.0 csomagokat, és hozzunk létre egy logical volume-ot a guest-nek:

apt-get install xenwatch xen-qemu-dm-4.0
lvcreate -L 1800M -n <lv_neve> <volume_group_neve>

Majd létre kell hozni a windows guest konfigurációs file-t (/etc/xen/<guest_neve>.cfg). A file a következőket tartalmazza (nálam):

kernel = "/usr/lib64/xen-4.0/boot/hvmloader"
builder='hvm'
memory = 512
shadow_memory = 8
name = "win-guest-01"
vif = [ 'type=ioemu, bridge=eth0' ]
disk = [ 'phy:/dev/<volume_group_neve>/<lv_neve>,hda,w','file:/<eleresi_ut>/xp.iso,hdc:cdrom,r' ]
device_model = '/usr/lib64/xen-4.0/bin/qemu-dm'
# boot on floppy (a), hard disk (c) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot="d"
sdl=0
vnc=1
vncconsole=0
vncpasswd='<password>'
stdvga=0
serial='pty'
usbdevice='tablet'

Ami magyarázatra szorul, az a disk paraméter. Itt adhatunk meg különböző disk eszközöket a guest számára. Az első maga a merevlemez, a második pedig egy CD meghajtó, ahova a telepítő médiát kell bemountolni. Megtehetnénk azt is, hogy a host CD lejátszót adjuk a guestnek:

'phy:/dev/hdb,hdc:cdrom,r'

A boot paraméterrel megadhatjuk a bootsorrendet, amint a kommentben is olvashatjuk (ezt a telepítés után át kell állítani d-ről c-re).

Ezen kívül kell állítanunk az /etc/xen/xend-config.sxp file-ban, hogy a VNC szerver mindenhonnan fogadjon kapcsolatot (vagy akármi más természetesen):

(vnc-listen '0.0.0.0')

Ha ezzel megvagyunk, a szokásos módon indítsuk el a vm-et, majd nézzük meg, melyik porton csatlakozhatunk a vnc szerverhez.

xm create /etc/xen/<guest_neve>.cfg
netstat -tupan | grep qemu

Ha ezzel megvagyunk, egy vnc klienssel csatlakozhatunk az így megkapott portszámon a hostgép IP címére

4 Adminisztráció

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:

• Az /etc/xen/xend-config.sxp file szerkesztésekor ügyeljünk arra, hogy a sorok elején ne maradjon whitespace karakter, mert úgy nem eszi meg a Xen.

• 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

5 Források, olvasnivaló

• 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
• Howto gyűjtemény