Xen
a (→Xen telepítése) |
a (→Windows XP) |
||
(2 szerkesztő 19 közbeeső változata nincs mutatva) | |||
2. sor: | 2. sor: | ||
− | =Xen-ről általában= |
+ | =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. |
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. |
||
9. sor: | 9. sor: | ||
== Bemutatkozás == |
== 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). |
+ | 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). |
− | Xen 4.0 fiécsörök: |
+ | Pár Xen 4.0 fícsör: |
* 128 virtuális CPU |
* 128 virtuális CPU |
||
* 1 TB RAM HVM esetén, paravirtualizáció esetén 512 GB |
* 1 TB RAM HVM esetén, paravirtualizáció esetén 512 GB |
||
* USB eszközök csatolása guest-hez |
* 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) |
* live migration (vm átköltöztethető kikapcsolás nélkül, majd átkapcsolás a másik rendszerre) |
||
− | |||
== [[Virtualiz%C3%A1ci%C3%B3s_technik%C3%A1k,_technol%C3%B3gi%C3%A1k#Paravirtualiz.C3.A1ci.C3.B3|Paravirtualizáció]] == |
== [[Virtualiz%C3%A1ci%C3%B3s_technik%C3%A1k,_technol%C3%B3gi%C3%A1k#Paravirtualiz.C3.A1ci.C3.B3|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). |
+ | 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). |
+ | == Felépítés == |
||
− | == Felépites == |
+ | 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 a 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 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. |
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. |
||
[[Fájl:XEN-schema.png]] |
[[Fájl:XEN-schema.png]] |
||
− | |||
== Alkalmazási példa: [http://www.cs.ucsd.edu/~mvrable/papers/2005-sosp-potemkin-presentation.pdf Potemkin VMM] == |
== Alkalmazási példa: [http://www.cs.ucsd.edu/~mvrable/papers/2005-sosp-potemkin-presentation.pdf Potemkin VMM] == |
||
46. sor: | 45. sor: | ||
* 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ő) |
* 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... |
* Pár tucat PC segítségével látszólag megtölthető gépekkel egy /8-as hálózat... |
||
− | |||
=Xen telepítése= |
=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 nem működik ez (broken dependencies), úgyhogy nem mindig ússzuk meg a forrásból telepítést. |
+ | 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. |
− | |||
− | == 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: |
Föltelepítjük a szükséges csomagokat: |
||
− | <pre>apt-get install xen-linux-system-2.6.26-2-xen-amd64 |
+ | <pre>apt-get install linux-image-2.6-xen-amd64 xen-hypervisor-4.0-amd64 xen-utils-4.0</pre> |
− | apt-get install xen-tools</pre> |
||
− | és újraindításkor már a xen-es kernelt bootoljuk be. |
+ | és újraindításkor már a xenes kernelt bootoljuk be. |
− | == Telepítés forrásból == |
+ | É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: |
− | |||
− | TODO (Ez eddig nem sikerült) |
||
− | |||
− | |||
− | == 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: |
||
<pre>pvcreate /dev/sdxY |
<pre>pvcreate /dev/sdxY |
||
69. sor: | 67. sor: | ||
(vif-script vif-bridge)</pre> |
(vif-script vif-bridge)</pre> |
||
− | =Guest rendszerek telepitese= |
+ | =Guest rendszerek telepítése= |
== Debian == |
== Debian == |
||
93. sor: | 91. sor: | ||
kernel = /boot/vmlinuz-`uname -r` # így a dom0 kernelét használjuk a létrehozandó guest-hez |
kernel = /boot/vmlinuz-`uname -r` # így a dom0 kernelét használjuk a létrehozandó guest-hez |
||
initrd = /boot/initrd.img-`uname -r` |
initrd = /boot/initrd.img-`uname -r` |
||
− | arch=amd64 # lehet persze i386 is, de akkor olyan kernel is kell megadnunk |
+ | 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/</pre> |
mirror = http://ftp.hu.debian.org/debian/</pre> |
||
Ha ezzel megvagyunk, hozzuk létre a guest-et a következő paranccsal: |
Ha ezzel megvagyunk, hozzuk létre a guest-et a következő paranccsal: |
||
− | <pre>xen-create-image --hostname <vm_neve> --role udev</pre> |
+ | <pre>xen-create-image --hostname <vm_neve></pre> |
− | 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: |
+ | 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). |
− | <pre>extra = "xencons=tty"</pre> |
+ | 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): |
− | |||
− | Enélkül nem kapnénk konzolt a vm-hez. |
||
− | |||
− | Az új virtuális gépet a következő paranccsal indíthatjuk el: |
||
<pre>xm create /etc/xen/<vm_neve>.cfg</pre> |
<pre>xm create /etc/xen/<vm_neve>.cfg</pre> |
||
108. sor: | 106. sor: | ||
==Windows XP== |
==Windows XP== |
||
− | TODO |
+ | 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: |
+ | <pre> |
||
+ | xm dmesg | grep VMX |
||
+ | </pre> |
||
+ | |||
+ | 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: |
||
+ | |||
+ | <pre>apt-get install xenwatch xen-qemu-dm-4.0 |
||
+ | lvcreate -L 1800M -n <lv_neve> <volume_group_neve> |
||
+ | </pre> |
||
+ | |||
+ | 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): |
||
+ | |||
+ | <pre> |
||
+ | 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' |
||
+ | </pre> |
||
+ | |||
+ | 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: |
||
+ | <pre>'phy:/dev/hdb,hdc:cdrom,r'</pre> |
||
+ | 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): |
||
+ | |||
+ | <pre>(vnc-listen '0.0.0.0')</pre> |
||
+ | |||
+ | 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. |
||
+ | |||
+ | <pre> |
||
+ | xm create /etc/xen/<guest_neve>.cfg |
||
+ | netstat -tupan | grep qemu |
||
+ | </pre> |
||
+ | |||
+ | Ha ezzel megvagyunk, egy vnc klienssel csatlakozhatunk az így megkapott portszámon a hostgép IP címére |
||
=Adminisztráció= |
=Adminisztráció= |
||
124. sor: | 171. sor: | ||
Pár megjegyzés: |
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. |
* 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. |
||
134. sor: | 183. sor: | ||
=Források, olvasnivaló= |
=Források, olvasnivaló= |
||
− | TODO (plusz telerakni linkekkel a szöveget) |
||
* [http://www.xen.org/support/documentation.html Xen hivatalos dokumentációk] |
* [http://www.xen.org/support/documentation.html Xen hivatalos dokumentációk] |
||
* [http://en.wikipedia.org/wiki/Xen Xen a Wikipedián] |
* [http://en.wikipedia.org/wiki/Xen Xen a Wikipedián] |
||
* [http://www.gluon.hu/files/bme_unix_2006.pdf Szalai Ferenc előadásának fóliái] |
* [http://www.gluon.hu/files/bme_unix_2006.pdf Szalai Ferenc előadásának fóliái] |
||
* [http://ian.blenke.com/xen/3.0/limitations/xen_limitations.html A xen 3.0.x korlátai] |
* [http://ian.blenke.com/xen/3.0/limitations/xen_limitations.html A xen 3.0.x korlátai] |
||
+ | * [http://wiki.xensource.com/xenwiki/HowTos Howto gyűjtemény] |
A lap jelenlegi, 2012. március 5., 10:02-kori változata
--Tmarlok 2010. november 30., 13:49 (UTC)
Tartalomjegyzék |
[szerkesztés] 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.
[szerkesztés] 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)
[szerkesztés] 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).
[szerkesztés] 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 a 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.
[szerkesztés] 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...
[szerkesztés] 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)
[szerkesztés] 3 Guest rendszerek telepítése
[szerkesztés] 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
[szerkesztés] 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 | grep 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
[szerkesztés] 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