[TUTO] Création d'une VM xen sous debian

[ZEPsikopat]

Un tuto rapide pour ceux qui auraient réussi à installer xen chez eux, et le configurer basiquement (avec les vf-route)

[*]Etape 1 : Création des images pour les VM

Nous verrons ici comment utiliser un FS virtuel avec des images disques, mais ceci est relativement facilement adaptable à des disques physiques voire du LVM (on va éviter nfs, parce que si le partage saute, ça pète tout)

Création d'un répertoire correspondant à la VM

mkdir /var/xen/vm_name

Création des images vierges pour la VM
Là on se base sur une installation simple, un seul disque dur contenant les données et une partition de swap :

# dd if=/dev/zero of=fs-root bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 17.021 seconds, 63.1 MB/s

# dd if=/dev/zero of=fs-swap bs=1M count=128 
128+0 records in
128+0 records out
134217728 bytes (134 MB) copied, 2.28222 seconds, 58.8 MB/s

Ce qui nous créera un disque principal de 1Go et un de swap de 128Mo (adaptez selon vos besoins).

Création des FS pour la VM

# mkfs -t ext3 -L krom-root fs-root 
mke2fs 1.40-WIP (14-Nov-2006)
fs-root is not a block special device.
Proceed anyway? (y,n) y
[...]
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

# mkswap fs-swap                   
Setting up swapspace version 1, size = 134213 kB
no label, UUID=6b757bba-26ed-4668-99d3-186f24d39496

Voilà, on a nos deux belles images disques de prêtes. On peut passer à la suite

[*]Etape 2 : Installation d'un système de base (avec debootsrap)
On monte l'image en loopback dans /mnt ou un autre répertoire

# mount -o loop fs-root /mnt

On installe le système par debootstrap

# debootstrap --arch i386 etch /mnt/ http://localhost:9999/debian
I: Retrieving Release
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://localhost:9999/debian...
I: Retrieving adduser
I: Validating adduser
[...]
I: Base system installed successfully.

Remplacez le serveur par un vrai serveur de packages debian (moi j'utilise apt-proxy, ça m'évite de télécharger 500 fois le même package), par exemple http://ftp.fr.debian.org/debian
Choisissez votre saveur debian aussi sarge, sid, etch, lenny, voire woody
L'architecture ne doit pas poser de problème, à priori ce sera la même que sur la machine hôte, encore qu'avec les 64bits vous ayiez le choix.
Une fois que la dernière ligne correspond, votre chroot est prêt, étape suivante.

[*]Etape 3 : Paramétrage de base de la VM
Là on peut soit bâcler, soit tout peaufiner suivant ce dont on a besoin.
Installer et configurer les locales

# aptitude install locales

# dpkg-reconfigure locales

Ceci permet d'enlever tous les messages en rapport avec un fallback sur la locale C par défaut.

Configurer le fstab
Il doit contenir quelque chose de la forme :
/etc/fstab

proc            /proc   proc    defaults        0       0
/dev/hda1       /       ext3    defaults,errors=remount-ro      0       1
/dev/hda2       none    swap    swap            0       0

Configurer les interfaces réseau
On va laisser xen se démerder, néanmoins il nous faut ajouter le loopback :
Dans /etc/network/interfaces

auto lo
iface lo inet loopback
        address 127.0.0.1
        netmask 255.0.0.0

Configurer le fichier /etc/hosts

127.0.0.1       localhost.localdomain   localhost

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Désactiver la libtls foireuse
Etape très importante, car sinon votre VM va tourner encore moins vite que dans un VMware !

mv /lib/tls /lib/tls.disabled

Là tout est bon, on peut sortir du chroot, avec exit ou ctrl-d

Copier les librairies du kernel qui seraient nécessaires

cp -dpR /lib/modules/vos_libs_du_kernel_de_la_VM /mnt/lib/modules

Une bonne de chose de faite, on approche de la fin

[*]Etape 4 : La VM vue par l'hyperviseur

Maintenant il faut configurer la VM pour que l'hyperviseur sache la traiter

Créez un fichier du genre /etc/xen/vm_name

kernel = "/boot/vmlinuz-2.6.18-4-xen-vserver-686"
ramdisk = "/boot/initrd.img-2.6.18-4-xen-vserver-686"
memory = 1024
name = "vm_name"
root = "/dev/hda1 ro"
disk = [ 'file:/var/xen/vm_name/fs-root,hda1,w', 'file:/var/xen/vm_name/fs-swap,hda2,w' ]

vif = ['ip=10.0.0.20' ]

Adaptez les paramètres à vos besoin.

Mais attention ! En mode routed, l'ip de la VM doit être obligatoirement 10.0.0.0/16 du à une limitation de xen 3.0.3 codée en hard !

[*]Etape 5 : Faire démarrer la VM et jouer avec

Votre vm est prête et configurée, vous pouvez jouer avec maintenant.
Pour la lancer et se connecter directement à la console

xm create -c vm_name

Pour la tuer

xm destroy vm_name

Pour s'y attacher

xm console vm_name

Pour s'en détacher

Ctrl-]

Sur un clavier azerty, ce sera [Ctrl] + [Alt gr] + [°]

Voilà, votre nouveau joujou est opérationnel.

Si vous voulez avoir des informations sur les VM xen lancées

# xm list
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0     1822     4 r-----   6365.5
kradok                                     8      192     1 -b----    283.9
krom                                       9     1024     1 -b----     10.7

[dricfr]

Super tuto
Est-il possible de mettre en place un serveur Xorg sur une machine virtuelle ?
J'ai essayé une installation basique de xorg (debian etch), mais lors du lancement le host n'est pas trouvé et donc X part en erreur.

@++

[ZEPsikopat]

Ça j'ai encore jamais testé.
en théorie on pourrait, en attribuant un accès direct à la carte vidéo pour le guest qui aurait X, mais cela nécessite d'avoir plus d'une carte vidéo.

[dricfr]

Apparemment ce n'est pas "évident" (FAQ XEN SOURCES):

[cpp]7.3. In DomU, how can I use 3D graphics.

In a para-virtualized domain, you could give access to the graphics card by hiding the device from Dom0 and giving the DomU of choice access to this card. [Sorry, I don't know more details than this - maybe someone else can fill in more here. --Mats Petersson] The frequently asked question comes from people who want to use Windows in a HVM domain to play games or run high-end 3D graphics applications, and the answer here is "Not yet". The problem here is that the OS isn't loaded directly at address zero when it is a guest-OS (DomU), so we're lying to the OS about it's location (because most OS's don't quite understand the concept of memory that doesn't actually start at address zero). So, the OS thinks that it's been loaded at an address of, say, 0..256MB, but in reality it's been loaded at 256MB..512MB. When it then talks to the graphics cards, it will give the graphics card a physical address of somewhere between 0..256MB, which of course doesn't work for the graphics card - as it should really be reading somewhere between 256MB..512MB. So what can we do about it? There are a number of different solutions that could work: 1. Rewrite the graphics driver so that it understands Xen. Possible, but hard work, even if you have easy access to the source-code. Most graphics chip manufacturers do not have open-source drivers. 2. Use some alternative way to access the desktop, such as Remote Desktop. This doesn't necessarily work for real high-end apps or games, but it's probably better than the graphics card emulation in HVM. 3. Wait for hardware and software to support IOMMU. An IOMMU is a device that will support mapping memory addresses for a domian to some different address when that domain's hardware is being used. There is currently (high-end) server hardware that support this, but no desktop machines. Expect this to change in the future, but not very soon.[/cpp]

Manifestement il faut passer par un soft de bureau virtuel. Je vais faire des recherches dans ce sens.

Merci pour la réponse

[dricfr]

Me voila enfin avec un noyau à la sauce Xen 3.1.0 . Je m'y suis remit maintenant que j'ai un peu de temps.

Je me permets de mettre ci-dessous la procédure que j'ai employée :

Xen sous Debian 64 sur plate-forme bi-opteron+k8x+2Go RAM
J'ai tout d'abord installer un système de base de Debian64 sur la machine en réalisant une net installation.
Puis,

1)Récupération des sources :
[cpp]wget http://bits.xensource.com/oss-xen/relea ... .0-src.tgz[/cpp]

2)Décompression des sources dans /usr/src/
[cpp]tar xzvf xen-3.1.0-src.tgz[/cpp]

3)Installation des dépandances et utilitaires pour environ 100Mo :
->bzip2
->make
->python-dev
->gcc
->binutils
->zlib1g-dev (zlib-dev)
->libcurl3-dev
->bridge-utils
->iproute
->patch
->xorg-dev
->gettext-base
->libncurses5-dev

Liste non exhaustive mais qui se rapproche de la réalité

4)Dans le répertoire xen,
[cpp]taper "make dist"[/cpp]
durant la traitement, téléchargement de linux-2.6.18.tar.bz2 :
Cannot find linux-2.6.18.tar.bz2 in path .:..
wget http://www.kernel.org/pub/linux/kernel/ ... 18.tar.bz2 -O./linux-2.6.18.tar.bz2
--20:58:36-- http://www.kernel.org/pub/linux/kernel/ ... 18.tar.bz2
=> `./linux-2.6.18.tar.bz2'
(40 mo)

=> Compilation du noyau.

Par défaut, Xen va compiler un noyau pour votre architecture locale. Cepandant, si vous voulez une autre architecture il est possible de la spécifier dans la ligne de commande en spécifant le kernel.
Ou en modificant le fichier Config.mk qui se trouve à la racine des sources de XEN. Après la détection de l'architecture locale, modifier la valeur de XEN_TARGET_ARCH. Dans l'example qui suit, je force l'architecture x86_64:
[cpp]XEN_COMPILE_ARCH ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
-e s/ppc/powerpc/ -e s/i86pc/x86_32/)
XEN_TARGET_ARCH ?= $(XEN_COMPILE_ARCH)
XEN_OS ?= $(shell uname -s)

XEN_TARGET_ARCH ?= x86_64[/cpp]

5) Une fois la compilation finie, la documentation est générée si LATEX et installé.

Puis, dans le répertoire racine de Xen, taper :
[cpp]"make install"[/cpp]

6) Création de l'image initrd :
Aller dans /lib/modules et vérifier la version du noyau compilée, ex 2.6.18-xen
Pour créer un fichier image initrd dans /boot saisir :
"update-initramfs -k 2.6.18-xen -c initrd.img-2.6.18-xen"

Ensuite, éditer le fichier "/boot/grub/menu.lst"
[cpp]title Xen 3.1.0 / XenLinux 2.6
root (hd0,0)
kernel /boot/xen-3.1.0.gz dom0_mem=262144
module /boot/vmlinuz-2.6.18-xen root=/dev/hda1 ro console=tty0
module /boot/initrd.img-2.6.18-xen
savedefault[/cpp]

7) redémarrer, choisir le nouveau noyau Xen. Normalement il devrait démarrer sans problème. Une première partie de l'initalisation concerne Xen et donne des informations de bas niveau. Une information est donnée pour améliorer les performances :
***************************************************************
***************************************************************
** WARNING: Currently emulating unsupported memory accesses **
** in /lib/tls glibc libraries. The emulation is **
** slow. To ensure full performance you should **
** install a 'xen-friendly' (nosegneg) version of **
** the library, or disable tls support by executing **
** the following as root: **
** mv /lib/tls /lib/tls.disabled **
** Offending process: init (pid=783) **
***************************************************************
***************************************************************
RMQ : A priori l'installation de libc6-xen permet de corriger le pb. Cependant, le message continue à s'afficher au boot... malgré une réinstallation complète du noyau xen.

8) Compiler un noyau pour les machines virtuelles. Il existe plusieurs noyaux pré-configurés pour les machines virtuelles.
Ils se trouvent dans le répertoire : "buidconfigs" à la racine des sources de Xen.
Pour généré un noyau standard "xenU", à la racine de Xen taper :
[cpp]make KERNELS="linux-2.6-xenU"[/cpp].
Un noyau dépouvu des pilotes pour matériel physique est généré.
L'ensemble des modules, image noyau ... générés se trouvent dans le sous répertoire dist/install.
Ainsi, dans le sous répertoire dist/install/boot on peut vérifier que l'on a le fichier vmlinuz-2.6.18-xenU par exemple.

Ensuite, on crée une machine virtuelle ....

[dricfr]

Un truc bête, mais je n'arrive pas à définir le mot de passe root de la machine virtuelle.
Quand je me loge dessus avec xm console, j'arrive directement root sans saisir de mot de passe. C'est plus génant pour passer via SSH ?

@++

[ZEPsikopat]

ben une fois logué en root, tu tapes passwd

[dricfr]

ouaip, je viens de m'en rendre compte
je suis quand même très nul

Fait au moins une 1/2 heure que je cherche une option dans le fichier de conf de la vm ...

Merci

[dricfr]

Yop.

Je refais un peu de Xen, le 3.1.3 et j'ai un soucis récurrent avec le réseau, que ce soit avec une installation depuis les paquets, en compilant ou en utilisant la distribution binaire.

En fait, il y a trois interfaces réseaux reconnues dans le PC
eth0 est à priori un port Firewire,
eth1 est une première carte réseau non utilisée pour le moment
eth2 est la carte réseau actuellement utilisée.

Une fois le pc démarré sans VM lancée , seulement trois interfaces sont actives, lo, eth2 et xenbr0. Et c'est là que le bas blesse. Xen s'évertue à configurer xenbr0 plutôt que xenbr2. Du coup, si je lance des VM, elles vont directement sur xenbr0 et ne peuvent accéder au réseau local puisque xenbr0 pointe sur eth0 qui est dans le vent.

J'ai essayé de forcer l'utilisation de xenbr2 lors de la création des VM en modifiant le xend-config.sxp et en spécifiant le bridge=xenbr2 lors du lancement du script network-bridge. Mais bien sûr, le lancement d'une VM plante car xenbr2 n'existe pas (j'ai également précisé le bridge dans le champ vif du fichier de configuration de la VM).

J'ai donc tripatouillé le script network-bridge et j'ai constaté que pour créé le "pont par défaut", il récupère la ligne de ip route et récupère le numéro de l'interface ethX de la ligne contenant la route par défaut (qui commence par "default"). Or, cette route n'existe pas chez moi.
J'ai donc configuré l'interface eth2 à la main en static et spécifié une gateway par défaut.
En ajoutant quelques echo dans network-bridge, je me suis aperçu que ça n'était pas suffisant, en fait, au début du script, il semblerait que le "vifnum" recherché via le numéro de l'interface par défaut soit écrasé par "0" en dur dans le code. En commentant la dite ligne et en relançant le script network-bridge, ça marche ! xenbr2 est bien créé, les VM se lancent et peuvent accèder au réseau local (pas encore essayé le oueb).

Mais, si je relance la machine hôte, Xen crée toujours et encore xenbr0 et pas xenbr2. IL faut que je lance manuellement le script network-config ... du coup je l'ai ajouté dans le lanceur de xend (dans /etc/init.d). C'est crade, je sais mais je ne sais pas quoi faire :/

En parcourant les scripts, il serait possible que cela viennent d'un nombre limité à 8 d'interfaces du module "loop", mais je n'y comprend rien.

Sinon, un ifconfig -a, fait bien apparaitre une veth2 et des vif0.X[1,3].

Je suis preneur d'une méthode pour réussir à configurer ce réseau :/

Merci

[gizmo78]

et si tu changeais juste le nom des interfaces? eth0 passe en eth2 et inversement

[dricfr]

Je ne savais pas que c'était possible... merci pour l'info, je fais googler là dessus.

@+

[gizmo78]

bas tu édite le fichier /etc/network/interfaces et tu inverse les noms

[dricfr]

eth0 n'est pas configuré dans interfaces (: . Il faut manifestement toucher le fichier géré par udev qui affecte une nom ethX à une adresse MAC.

Je vais tenter pour voir (si j'ai le courage, là j'ai trop faim ^^)

@+

[dricfr]

Bon, j'ai modifié le fichier :
/etc/udev/rules.d/z25_persistent-net.rules

pour que eth0 soit associée avec l'adresse mac de la carte utilisée.

Hélas, il y a toujours un problème avec le réseaux de la machine virtuelle. Il faut tout de même que je relance manuellement le script network-bridge pour que la VM puisse accéder au réseau local. Apparemment, lors de la création au démarrage, le "bridge" n'est renseigné que d'un seul côté. l'interface vif est bien associée avec xenbr0, mais il n'y a pas d'autre interface. Une fois le script relancé, le "status" du bridge permet de voir que peth est également associée.

@+

[dricfr]

Salut,

pour une machine virtuelle, il ne me semble obligatoire d'avoir une image. Il me semble qu'elle n'est plus fournie. il faut donc la créer soit même avec mkinitrd (je ne me souviens plus de la syntaxe exacte ).

Sinon, je crois que le paquet xen-tools permet de générer tout ce qu'il te faut. En modifiant son fichier de configuration tu dois pouvoir générer les fichiers initrd de tes machines virtuelles.
Un lien intéressant :
http://www.howtoforge.com/debian_etch_xen_3.1_p3

@+