Compilation de Xen à partir des

sources
1 Introduction
Le but de ce document est de guider les utilisateurs tout au long du processus d’installation du
logiciel Xen Project à partir des sources (soit à partir des versions de l’archive tar, soit à partir d’un
référentiel de code source).
Ce document a été rédigé pour la version 4.2 du projet Xen, mais nous tenterons de souligner les
différences par rapport aux versions précédentes, le cas échéant.
On suppose qu’il est familier avec le concept général de construction de logiciels et avec
l’utilisation de votre gestionnaire de paquets de distributions pour installer des outils de compilation
pertinents, etc.

2 Pourquoi construire à partir des

sources ?
Avant de vous lancer dans le processus de création du logiciel Xen Project, il convient de se
demander si cela est même nécessaire. Il existe de nombreuses distributions de nos jours qui ont un
excellent support pour Xen disponible directement à partir du gestionnaire de paquets, une liste
partielle est disponible sur Dom0 Kernels for Xen. Dans la mesure du possible, il est fortement
recommandé aux utilisateurs de consommer Xen Project via la distribution de leur choix dans la
mesure du possible. L’utilisation de l’emballage de distribution vous donnera une solution beaucoup
plus intégrée et vous permettra de profiter de toutes les ressources fournies par votre distribution
(par exemple, la documentation, le support, etc.).
Le reste de ce document suppose que vous avez pris en compte cela et que vous voulez vraiment
compiler à partir des sources.

3 Installation du système d’exploitation

de l’hôte (domaine 0)
Avant d’installer Xen Project, vous devrez d’abord installer votre système d’exploitation de
domaine 0, sauf si vous l’avez déjà fait. Considérations relatives à l’installation du système
d’exploitation hôte contient certains éléments que vous voudrez peut-être prendre en compte lors de
cette opération.

4 Obtention du code source du projet Xen

Les principaux moyens d’obtenir le code source du projet Xen pour une version stable sont via
les archives de la version ou par clonage à partir du référentiel source Mercurial approprié. Pour la
version de développement de Xen Project (xen-unstable), Git est la source primaire et Mercurial est
la source secondaire.
 4.1 Libérer les archives
Les dernières versions de Xen Project sont liées à partir de la page de téléchargement de The
Xen.org

4.2 Git
Les dépôts de code source sont hébergés à l’aide du système de contrôle de version Git sur
xenbits.
Chaque version stable a sa propre branche stable-X.Y (par exemple stable-4.2 sur la page de
résumé de Xen.git). Le code destiné à la prochaine version stable est ajouté à la branche staging-
X.Y (par exemple, staging-4.2 sur la page de résumé de Xen.git), et après avoir passé les tests
automatisés, il sera poussé vers stable-X.Y pour la prochaine version. Les versions ponctuelles sont
marquées dans l’arborescence principale avec RELEASE-X. Y.Z (par exemple, RELEASE-4.2.2 sur
la page de résumé de Xen.git). Les résultats des tests automatisés sont disponibles sur la liste de
diffusion xen-devel.
Xen Project Repositories contient des informations sur les différents dépôts pour les branches
stable et development.
Pour cloner la source, installez d’abord Git à l’aide du gestionnaire de paquets de votre
distribution. Exécutez ensuite la commande suivante :
$ git clone URL
Où URL est l’URL du référentiel que vous souhaitez cloner. Dans notre cas, nous devrions
utiliser :
$ git clone git://xenbits.xen.org/xen.git
Comme la tête par défaut dans xen.git est master, votre dépôt local aura également une branche
appelée master pointant vers la branche en amont. Si vous souhaitez utiliser d’autres HEAD (par
exemple, le staging), vous pouvez :
$ cd xen; git checkout -b staging origin/staging
Vous pouvez également vérifier toutes les balises, branches comme vous le souhaitez.

4.3 Inconstant
Veuillez noter que XenProject.org est passé à l’utilisation de Git. La section suivante est
obsolète. Nous maintenons des dépôts Mercurial reflétant ceux de Git, nous conservons donc
la section suivante pour référence.
Les dépôts de code source de Xen Project sont hébergés à l’aide du système de contrôle de
version Mercurial sur xenbits.
Chaque version stable a sa propre branche xen-X.Y-testing.hg (par exemple xen-4.2-testing.hg)
où le code destiné à la prochaine version stable est ajouté. La branche de développement du projet
Xen est connue sous le nom de xen-unstable et possède son propre dépôt xen-unstable.hg.
Chaque branche stable et de développement est disponible sous deux formes, soit testée (la
branche principale), soit non testée (la branche staging). Lorsque des validations sont effectuées
dans une arborescence de projet Xen, elles sont d’abord ajoutées à la branche intermédiaire et ne
sont propagées à la branche principale qu’une fois les tests automatisés passés. Par exemple, tous
les commits de la branche de développement du projet Xen apparaîtront initialement dans
staging/xen-unstable.hg, puis se propageront dans xen-unstable.hg une fois les tests automatisés
terminés. Les résultats des tests automatisés sont postés sur la liste de diffusion xen-devel.
Xen Project Repositories contient des informations sur les différents dépôts pour les branches
stable et development.
Pour cloner la source, installez d’abord l’outil mercurial à l’aide du gestionnaire de paquets de
votre distribution. Exécutez ensuite la commande suivante :
 $ hg clone URL
Où URL est l’URL du référentiel que vous souhaitez cloner. Par exemple, pour cloner le dernier
arbre Xen-Unstable testé :
$ hg clone http://xenbits.xen.org/hg/xen-unstable.hg
Ou pour cloner l’arbre xen-instable (par exemple, pas encore testé) :
$ hg clone http://xenbits.xen.org/hg/staging/xen-unstable.hg
Vous voudrez peut-être obtenir un ensemble de modifications spécifique (révision), par exemple
lorsque vous essayez de répliquer la version de quelqu’un d’autre, ou lorsque vous traitez d’autres
correctifs que vous devez appliquer par la suite. Vous pouvez le faire avec l’option -r. Par exemple,
pour obtenir l’ensemble de modifications 25364 :
$ hg clone -r 25364 http://xenbits.xen.org/hg/xen-unstable.hg

5 Démarrage rapide
Le fichier README au niveau supérieur de l’arborescence du code source du projet Xen
contient un guide de démarrage rapide pour la création du logiciel. Cela fournit un aperçu rapide du
processus et des exigences pour la création du logiciel Xen Project et contiendra généralement les
informations les plus récentes spécifiques à l’arborescence source particulière que vous consultez.
Après avoir obtenu le code source du projet Xen, c’est le premier document que vous devriez lire.

6 Construire à partir de la source

Cette section documente toutes les exigences connues pour compiler à partir des sources.

6.1 Mise à jour de /sbin/installkernel sous Linux

Les distributions Linux livrées avec grub2 devront s’assurer que leur script /sbin/installkernel,
qui doit être fourni par chaque distribution Linux, copie la configuration du noyau lors d’une
installation personnalisée du noyau. L’exigence du fichier de configuration provient de grub2 en
amont /etc/grub.d/20_linux_xen qui n’ajoutera xen en tant qu’instance à votre grub.cfg que si et
seulement s’il trouve dans votre fichier de configuration l’un des éléments suivants :
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
Sans cela, un utilisateur compilant et installant son propre noyau avec un support approprié pour
xen et avec l’hyperviseur xen présent n’obtiendra pas son script de mise à jour grub2 respectif pour
récupérer l’hyperviseur xen. Les tests Debian ont un support approprié pour cela, OpenSUSE a
exigé ce changement en amont sur mkinitrd, donc les gens d’OpenSUSE voudront obtenir la
dernière version de /sbin/installkernel hébergée sur le dépôt OpenSUSE mkinitrd sur github
# If on OpenSUSE update your /sbin/installkernel
git clone https://github.com/openSUSE/mkinitrd.git
cd mkinitrd
sudo cp sbin/installkernel /sbin/installkernel
Fedora pourrait avoir besoin d’une mise à jour similaire. S’il vous plaît modifier ce wiki une fois
que vous avez confirmé.

6.2 Dépendances de build

Xen Project utilise plusieurs bibliothèques et outils externes. La liste principale de ces prérequis
est la liste présente dans le fichier README.
 Même cette liste suppose une sorte d’environnement de développement de base. Un bon point de
départ pour cela est d’utiliser l’option d’installation du package de développement de votre
distribution.
6.2.1 Construire des dépendances - Debian / Ubuntu
Sous Debian / Ubuntu (et les distributions dérivées), installez le paquet build-essential :
# apt-get install build-essential
Vous devez également installer ces DEB supplémentaires :
# apt-get install bcc bin86 gawk bridge-utils iproute libcurl3 libcurl4-openssl-dev bzip2 module-
init-tools transfig tgif
# apt-get install texinfo texlive-latex-base texlive-latex-recommended texlive-fonts-extra texlive-
fonts-recommended pciutils-dev mercurial
# apt-get install make gcc libc6-dev zlib1g-dev python python-dev python-twisted libncurses5-dev
patch libvncserver-dev libsdl-dev libjpeg62-turbo-dev
# apt-get install iasl libbz2-dev e2fslibs-dev git-core uuid-dev ocaml ocaml-findlib libx11-dev
bison flex xz-utils libyajl-dev
# apt-get install gettext libpixman-1-dev libaio-dev markdown pandoc
Et si vous vous lancez sur Wheezy :
# apt-get install libc6-dev-i386
Un raccourci utile peut être d’utiliser le gestionnaire de paquets de votre distribution pour
installer tous les paquets prérequis est d’installer les paquets qui sont notés comme étant nécessaires
pour construire les propres paquets Xen de la distribution. Par exemple, sous Debian ou une
distribution dérivée de Debian :
# apt-get build-dep xen
Cependant, vous devez être conscient des nouvelles conditions préalables ajoutées entre la
version du logiciel Xen Project dans votre distribution et la version que vous construisez lorsque
vous utilisez cette astuce.
6.2.2 Dépendances de build - OpenSUSE
Si vous utilisez maintenant la dernière version d’OpenSUSE, vous remarquerez qu’il s’agit
maintenant d’un base de distribution roulante. Les instructions par défaut ne vous incitent pas à
installer les dépôts sources, et même si vous l’avez fait installez-les les instructions les désactivent
par défaut, donc Assurez-vous de les installer et de les activer autrement La commande zypper
source-install -d ne fonctionnera pas. Pour activer le référentiel requis si vous l’aviez déjà Installé:
# zypper mr -e repo-src-oss
Obtenez maintenant les dépendances de build pour Xen
# zypper source-install -d xen
Voici une liste des éléments qui ne sont pas actuellement détectés par les dépendances de build
qui se sont avérées nécessaires :
# zypper install systemd-devel gettext-tools\
ocaml ocaml-compiler-libs ocaml-runtime \
ocaml-ocamldoc ocaml-findlib glibc-devel-32bit make patch
Pendant qu’il y est, obtenez également les dépendances de build pour Linux :
# zypper source-install -d kernel-desktop

6.2.3 Compiler les dépendances - Fedora

Ces instructions sont séparées de celles de RHEL/Centos car Fedora est mis à jour plus
fréquemment, vous devez donc faire moins de travail pour construire le dernier et le meilleur Xen.
Installez les dépendances de build connues :
 # yum-builddep xen
Installez les éléments qui ne sont pas récupérés par les dépendances de build actuelles :
# yum install glibc-devel.x86_64 systemd-devel.x86_64
Obtenez les dépendances de compilation pour Linux, le noyau, pendant que vous y êtes :
# yum-builddep kernel

6.2.4 Dépendances de build - RHEL / Centos

Sous RHEL, CentOS, distributions basées sur Fedora, vous souhaitez installer les groupes de
paquets Development Tools :
# yum groupinstall "Development Tools"
(Sur les anciens CentOS et Fedora, un groupe appelé Bibliothèques de développement devrait,
s’il est disponible, également être installé. Ce n’est plus présent dans les versions récentes des
distributions, cependant).
Installez ensuite les dépendances de build connues (confirmation nécessaire si cela fonctionne
sur RHEL / Centos) :
# yum-builddep xen
Vous devez également installer ces RPM supplémentaires :
# yum install transfig wget tar less texi2html libaio-devel dev86 glibc-devel e2fsprogs-devel gitk
mkinitrd iasl xz-devel bzip2-devel
# yum install pciutils-libs pciutils-devel SDL-devel libX11-devel gtk2-devel bridge-utils PyXML
qemu-common qemu-img mercurial texinfo
# yum install libidn-devel yajl yajl-devel ocaml ocaml-findlib ocaml-findlib-devel python-devel
uuid-devel libuuid-devel openssl-devel
# yum install python-markdown pandoc systemd-devel glibc-devel.i686
S’il s’agit de CentOS, pour certains de ces paquets (par exemple, dev86 et pandoc), l’activation
du référentiel supplémentaire EPEL est nécessaire.
6.2.5 Notes supplémentaires
Après l’avoir installé, vous devez ensuite installer chacun des prérequis listés dans le fichier
README à l’aide de l’outil de gestion des paquets de votre distribution. En général, le code du
projet Xen essaie de ne dépendre que d’outils et de bibliothèques externes qui sont couramment
disponibles dans les distributions, donc l’obtention des prérequis autres que ceux du système de
gestion de paquets de votre distribution est hors du cadre de ce document. Si vous avez des
difficultés à trouver un prérequis particulier, veuillez contacter la liste de diffusion xen-users.

6.3 Configurer
À partir de Xen Project 4.2, le logiciel utilise l’outil autoconf couramment utilisé pour fournir
une configurabilité au moment de la compilation de la pile d’outils. Cela permet un certain contrôle
des fonctionnalités intégrées à Xen Project, ainsi que la vérification de l’intégrité au moment de la
compilation. Pour configurer Xen Project, il suffit d’exécuter le script de configuration fourni :
$ ./configure
Pour voir les différentes options, exécutez le script configure avec --help, par exemple :
$ ./configure --help
[...]
Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--enable-githttp Download GIT repositories via HTTP (default is
 DISABLED)
Cette étape n’est requise qu’à partir de Xen Project 4.2. Avant Xen Project 4.2, ces options
pouvaient être configurées en passant une variable sur la ligne de commande make lors de la
compilation et de l’installation ou en écrivant la variable dans un fichier nommé .config au niveau
supérieur de l’arborescence des sources.
6.3.1 Utilisez http:// plutôt que git:// pour cloner des référentiels
supplémentaires
Lors de la création du logiciel à partir de Mercurial, le système de compilation clonera
automatiquement plusieurs référentiels supplémentaires à partir du réseau. Certains de ces dépôts
utilisent le système de contrôle de version qui utilise son propre protocole sur un port spécifique.
Parfois, cela provoque des problèmes dus au blocage du port git par les pare-feu, etc. Cela peut être
contourné en demandant au système de compilation Xen de cloner de tels dépôts à l’aide d’un
protocole HTTP moins efficace :
$ ./configure --enable-githttp
Avant Xen Project 4.2, cela pouvait être réalisé en écrivant GIT_HTTP=y dans votre .config :
$ cat .config
GIT_HTTP = y

6.3.2 Répertoire d’installation de la bibliothèque

Xen Project 4.2 et versions ultérieures installe par défaut les bibliothèques dans /usr/lib et à partir
de la version 4.3 installe par défaut dans /usr/local/lib par défaut.
Les utilisateurs sur les systèmes qui utilisent /usr/local/lib64 pour les bibliothèques 64 bits
doivent utiliser l’option --libdir. Par exemple :
$ ./configure --libdir=/usr/local/lib64
Le non-respect de cette consigne entraîne généralement des erreurs concernant les bibliothèques
introuvables ou l’utilisation d’anciennes versions des bibliothèques qui ne fonctionneront
probablement pas.
_NB_ : Si vous utilisez '--prefix=/usr' vous devriez aussi utiliser '--libdir=/usr/lib64'.
6.3.3 systemd
Si le système cible utilise systemd, n’oubliez pas de l’activer :
$ ./configure --enable-systemd

6.3.4 Préfixe Python et disposition du module

Sur certaines distributions (par exemple Debian et Ubuntu), le projet Xen peut installer les
parties python du code au mauvais endroit (voir le bogue Debian #693721). Par conséquent, il est
nécessaire de définir PYTHON_PREFIX_ARG=--install-layout=deb :
$ cat .config
PYTHON_PREFIX_ARG=--install-layout=deb
Certaines versions d’Ubuntu ont un bogue qui nécessite à la place que
PYTHON_PREFIX_ARG soit de définir la chaîne vide :
$ cat .config
PYTHON_PREFIX_ARG=
À partir de la version 4.2, cette option n’est pas encore prise en charge par le script configure et
doit donc toujours être définie via .config ou sur la ligne de commande make.
Le symptôme le plus courant de ce problème est que pygrub ne fonctionne pas, avec un résultat
similaire à :
 Traceback (most recent call last):
File "/usr/lib/xen/bin/pygrub", line 20, in <module>
import xen.lowlevel.xc
ImportError: No module named xen.lowlevel.xc

6.4 Construire et installer

Xen Project télécharge divers composants au moment de la génération. Cela signifie
que la construction de Xen Project nécessite actuellement une connexion active à Internet

Pour construire tous les composants (hyperviseur, outils, documents, stubdomains, etc.), vous
pouvez utiliser la cible dist.
$ make dist
Si vous souhaitez simplement (re)construire un seul composant, vous pouvez utiliser la
cible dist-COMPONENT appropriée :
$ make dist-xen
$ make dist-tools
$ make dist-docs
$ ... etc ...
Si vous voulez reconstruire un arbre comme s’il s’agissait d’un nouveau test, vous pouvez
utiliser la cible mondiale. C’est effectivement la même chose que propre et le dist
$ make world
Toutes les cibles ci-dessus construisent et installent le composant approprié dans le sous-
répertoire dist, mais ne l’installent pas réellement sur le système.
Pour l’installer sur la machine locale, il suffit d’appeler la cible d’installation (en tant que root) :
# make install
Comme pour dist, vous pouvez également installer des composants individuels à l’aide de la
cible install-COMPONENT appropriée :
# make install-xen
# make install-tools
# make install-docs
# ... etc ...
Si vous souhaitez l’installer sur une machine distante, vous pouvez simplement copier le
répertoire dist et TBD
Une meilleure option est de faire un « package-ball » -- un paquet qui est l’équivalent d’une
archive sans vérification ni configuration des dépendances. Il existe des cibles pour l’un ou l’autre
des systèmes basés sur deb :
# make debball
ou des systèmes basés sur RPM :
# make rpmball
Les paquets sont placés dans le répertoire dist/.
L’installation du package résultant est fonctionnellement équivalente à la cible make install ci-
dessus, mais comme les fichiers sont suivis par le gestionnaire de packages, il est plus facile de les
supprimer ou de les mettre à jour.
Après l’installation (soit via make install, soit via un packageballl), vous reconstruisez votre
cache de l’éditeur de liens dynamique en exécutant :
# /sbin/ldconfig
Pour obtenir plus d’informations sur les cibles disponibles, utilisez la cible d’aide :
 $ make help

6.5 Mise à jour Linux grub2

Lorsque vous êtes sous Linux et que vous utilisez grub2 après avoir installé Xen, vous devrez
également vous assurer que grub2 récupère votre nouvel hyperviseur Xen. Les distributions
diffèrent sur la façon de procéder. Cette section explique comment procéder pour les distributions
connues.
6.5.1 mettre à jour la configuration de grub2 sur OpenSUSE
# update-bootloader --refresh

6.5.2 mettre à jour la configuration grub2 sur Debian

# update-grub

6.5.3 mettre à jour la configuration de grub2 sur Fedora

TBD
6.5.4 mise à jour de la configuration grub2 sur RHEL / Centos
TBD

6.6 Dépannage
Si SeaBIOS ne parvient pas à se compiler lors de la génération de Xen 4.2 sur un système dont
les paramètres régionaux ne sont pas anglais, essayez de définir LC_ALL sur en_US. UTF-8 avant
d’appeler make :
# export LC_ALL=en_US.UTF-8
# make world

6.7 Noyaux
Le noyau Linux prend désormais en charge différents hyperviseurs avec un seul noyau. Il n’est
pas non plus nécessaire qu’un noyau de domaine 0 (ou invité) corresponde à votre hyperviseur,
vous êtes donc libre de choisir le noyau qui correspond le mieux à vos besoins (par exemple, de
nombreuses distributions fournissent un noyau compatible avec Xen Project, ce qui est un chemin
rapide et facile). Dom0 Kernels for Xen contient des conseils à ce sujet.
6.7.1 Compilation de la dernière prise en charge du noyau Linux
Si vous compilez Linux à partir des sources pour dom0 ou un invité, vous pouvez maintenant
activer le support Xen pour les deux via un simple assistant de configuration du noyau, ceci a été
ajouté à partir de la v4.2 :
make xenconfig
Cela vous permet de construire un noyau qui peut prendre en charge xen dom0 ou xen invités sur
i386, x86-64 et arm64.

6.8 Après l’installation

Quelques services système doivent être activés manuellement après l’installation :
 6.8.1 SystemV (en anglais seulement)
Obligatoire:
update-rc.d xencommons defaults 19 18
Optionnel:
update-rc.d xendomains defaults 21 20
update-rc.d xen-watchdog defaults 22 23

6.8.2 systemd
Obligatoire:
systemctl enable xen-qemu-dom0-disk-backend.service
systemctl enable xen-init-dom0.service
systemctl enable xenconsoled.service
Optionnel:
systemctl enable xendomains.service
systemctl enable xen-watchdog.service
systemctl enable xendriverdomain.service
Après avoir effectué ces modifications, redémarrez le système.

7 Configuration de l’hôte
Une fois le code du projet Xen installé, il reste encore une configuration au niveau de l’hôte
requise.