Pour information

Dans ce guide, je parlerai en permanence de machines virtuelles. Cependant, Xen a sa propre terminologie. Dans une configuration Xen, les machines virtuelles instanciées (c'est à dire démarrées) sont appelées "Domaines".

Une fois votre machine configurée pour faire fonctionner Xen, tous les systèmes d'exploitation tournent dans des "domaines". Le système d'exploitation d'origine, ou se trouvent installés les outils de contrôle de Xen, est appellé le "dom0" (pour domaine n°0). Tous les systèmes d'exploitation invités sont dit installés dans un "domU" (pour domaine utilisateur).

Comme je suis un peut pantouflard, je n'ai pas envie de m'imposer cette torsion mentale, et je ne parlerai que de machines virtuelles pour simplifier le schmilblick. Aussi, si vous lisez ce guide, ne hurlez pas à mort à cause des dénominations.

Prérequis

Ce guide fait usage des possibilités de LVM. Si vous ne savez pas ce que c'est ou que vous souhaitez mettre en place LVM sur votre machine, je vous conseille de lire l'article suivant:

LVM, une autre manière de partitionner.

De plus, nous allons avoir besoin de apg pour générer les mots de passe des utilisateurs des machines virtuelles:

/usr/bin/apt-get install apg

Installation sur Debian 5.0 Lenny

En premier lieu, nous installons l'hyperviseur Xen, le noyau Xen destiné au Dom0, et d'autres outils:

/usr/bin/apt-get install xen-hypervisor-i386 linux-image-2.6-xen-686 linux-headers-2.6-xen-686 \
                         xen-utils-3.2-1 xen-tools bridge-utils

Attention: Si vous utilisez une version 64 bits de Debian, utilisez la ligne de commande suivante:

/usr/bin/apt-get install xen-hypervisor-amd64 linux-image-2.6-xen-amd64 linux-headers-2.6-xen-amd64 \
                         xen-utils-3.2-1 xen-tools bridge-utils

Une fois ceci fait, nous redémarrons afin d'utiliser le nouveau noyau:

ATTENTION : ne pas redémarrer si vous utilisez une Dédibox.

reboot

Installation sur Debian 4.0 Etch

En premier lieu, nous installons le noyau spécifique à Xen ainsi qu'une libc patchée afin que Xen fonctionne correctement:

/usr/bin/apt-get install linux-image-2.6-xen-vserver-686 linux-headers-2.6-xen-vserver-686 libc6-xen \
                         xen-hypervisor-3.0.3-1-i386-pae xen-tools bridge-utils

Attention: Si vous utilisez une version 64 bits de Debian, utilisez la ligne de commande suivante:

/usr/bin/apt-get install linux-image-2.6-xen-vserver-amd64 linux-headers-2.6-xen-vserver-amd64 \
                         xen-hypervisor-3.0.3-1-amd64 xen-tools bridge-utils

Remarque: Si votre processeur le supporte, et si vous voulez installer des systèmes d'exploitation non modifiés (tel que Windows XP), il vous faut installer un paquet supplémentaire:

/usr/bin/apt-get install xen-ioemu-3.0.3-1

Une fois ceci fait, nous redémarrons afin d'utiliser le nouveau noyau :

ATTENTION : ne pas redémarrer si vous utilisez une Dédibox.

reboot

Machines virtuelles Ubuntu 8.04 Hardy Heron et Debian 5.0 Lenny sur Debian 4.0 Etch

Enfin, afin de pouvoir utiliser Ubuntu 8.04 Hardy Heron et Debian 5.0 Etch dans nos machines virtuelles à partir d'un Dom0 Debian 4.0 Etch, nous ajoutons les outils nécessaires:

if [ "$(/bin/cat /etc/debian_version)" = "4.0" ]; then
  /bin/ln -s ubuntu.d /usr/lib/xen-tools/hardy.d
  /bin/ln -s debian.d /usr/lib/xen-tools/lenny.d
  /usr/bin/wget http://falcon.landure.fr/pool/etch/debootstrap/debootstrap_1.0.10_all.deb \
    --output-document=/tmp/debootstrap_1.0.10_all.deb
  /usr/bin/dpkg -i /tmp/debootstrap_1.0.10_all.deb
fi

Erreurs liées à Xen

Kernel panic à la création d'un domaine

Afin  d'éviter un kernel  panic de la machine hôte (dom0) lors du démarrage d'une machine virtuelle (domU), nous devons limiter le nombre de CPU disponibles pour le dom0. Ceci est réalisé par la commande:

/bin/sed -i -e 's/^[# ]*\((dom0-cpus\).*\().*\)$/\1 1\2/' \
         /etc/xen/xend-config.sxp

Source: Merci à Gerald Hochegger pour son e-mail Bug#410807: workaround: linux-image-2.6.18-4-xen-amd64: Kernel BUG at drivers/xen/core/evtchn.c:481

Problème de connexion aux machines virtuelles via le réseau

Au bout d'un certain temps, et d'un certain nombre de machines virtuelles créées, un bug apparait. L'un des symptôme de ce bug est l'apparition des messages suivants dans le syslog de la machine hôte (dom0):

xen_net: Memory squeeze in netback driver.

La correction de ce problème nécessite un redémarrage de la machine hôte. En premier lieu, modifiez le fichier de configuration de Grub afin de limiter le volume de mémoire assigné à la machine virtuelle au boot:

/bin/sed -i -e 's/\(xenhopt=.*\)/\1dom0_mem=256M/' \
         /boot/grub/menu.lst

Appliquez cette modification aux noyaux listés par Grub:

/usr/sbin/update-grub

Et appliquez le même montant à la mémoire minimum disponible pour la machine hôte (dom0):

/bin/sed -i -e 's/^[# ]*\((dom0-min-mem\).*\().*\)$/\1 256\2/' \
         /etc/xen/xend-config.sxp

Il ne vous reste plus qu'a redémarrer la machine pour prendre en compte ces modifications:

reboot

Source: Merci à Crucial Paradigm pour leur article Xen Bug: xen_net: Memory squeeze in netback driver (32bit PAE).

Erreurs /dev/mem: mmap: Bad address dans les machines virtuelles (domU)

Ce message est une erreur affichée par dmidecode. dmidecode essaie d'accéder à des informations  bas niveau sur le matériel dans le but d'obtenir une configuration par défaut adéquate. Ceci ne fonctionne pas sous Xen, mais peut être ignoré sans soucis.

Source: Merci à MingsVille pour la réponse à la question When doing an apt-get or aptitude update I see an error like /dev/mem: mmap: Bad address; is this a cause for concern ? qu'il a obtenu dans les informations techniques pour les clients VPS de BitFolk.

Configuration du réseau

Xen propose plusieurs méthodes de configuration du réseau, ce guide en aborde 2. Pour faire un rapide résumé:

• Mode bridge: les machines virtuelles sont des machines du réseau local de l'hôte Xen. C'est à dire qu'elles sont accessibles depuis d'autres ordinateurs que l'hôte Xen. C'est la configuration a préférer si votre ordinateur hôte (dom0) est dans un réseau local.
  Remarque : Le guide lui-même est normallement Bridge ready. Ce n'était pas le cas des premières version de ce guide :D.
  
• Mode NAT: les machines virtuelles sont sur un réseau local virtuel. Elles ne sont accessibles que depuis l'ordinateur hôte, jusqu'à ce qu'une régle de routage NAT soit mise en place. C'est la configuration à préférer si votre ordinateur hôte (dom0) n'est pas dans un réseau local (serveur dédié, etc...).

Choix du mode de réseau

Si vous souhaitez utiliser vos machine virtuelles en mode NAT, que je recommande à moins que vous ne sachiez ce que vous faites, réglez le mode du réseau sur NAT :

XEN_NETWORK_MODE=nat

Remarque : Si vous souhaitez utiliser le mode bridge (non recommandé si votre serveur est directement présent sur l'internet), il suffit de le spécifier à l'aide de :

XEN_NETWORK_MODE=bridge

Configuration du réseau (non Dedibox)

La première étape est de désactiver la configuration réseau précédente:

/bin/sed -i -e 's/^(network-script .*).*$/# \0/' \
            -e 's/^(vif-script .*).*$/# \0/' \
         /etc/xen/xend-config.sxp

Et nous activons la configuration adaptée au mode réseau que nous avons choisi:

/bin/sed -i -e "s/^#[ ]*\\((network-script.*network-${XEN_NETWORK_MODE}).*\\)\$/\\1/" \
            -e "s/^#[ ]*\\((vif-script.*vif-${XEN_NETWORK_MODE}).*\\)\$/\\1/" \
         /etc/xen/xend-config.sxp

Nous redémarrons le démon Xen:

/etc/init.d/xend restart

Détection de l'adresse IP du Dom0

Nous récupérons l'adresse IP de notre Dom0. Dans une configuration en mode NAT, nous utilisons 10.0.0.128, mais dans le cas d'une configuration en mode Bridge, nous devons utiliser l'adresse IP de l'interface physique (ici, j'estime qu'il s'agit d'eth0):

MAINDOM_IP=10.0.0.128
if [ $(/bin/grep "^[^#]*bridge" /etc/xen/xend-config.sxp | /usr/bin/wc --lines) -gt 0 ]; then
  MAINDOM_IP=$(/sbin/ifconfig eth0 | /bin/grep "inet adr" | /bin/sed -e 's/^.*inet adr:\([^ ]*\) .*$/\1/')
fi

Vous pouvez vérifier l'adresse IP détectée à l'aide de la commande :

/bin/echo "L'adresse IP de ce serveur pour les DomU est : ${MAINDOM_IP}"

Remarque : Si l'adresse obtenue n'est pas correcte, utilisez la commande suivante pour fournir une valeur correcte :

MAINDOM_IP=192.168.1.5

Configuration du serveur SMTP de la machine hôte

Attention: Cette section est destinée à configurer le serveur SMTP de la machine hôte. Si vous avez déjà configuré le serveur SMTP par vous même, les lignes de commandes suivantes vont écraser votre configuration. Si cela vous pose problème, et que vous avez choisi le mode NAT pour le réseau des domU, veillez simplement à ce que votre serveur SMTP écoute sur l'adresse 10.0.0.128, et accepte le relais des emails en provenance de 10.0.0.0/24.

Il est important de surveiller les journaux et les mises à jour de sécurité de vos serveurs. De nombreux outils tels que cron-apt, logwatch, rkhunter se chargent de cela pour vous. Ils envoient leurs rapports par e-mail. Le pré-requis à leur bon fonctionnement est la présence d'un serveur SMTP configuré correctement. Si vous êtes un habitué des serveurs SMTP, je pense que cette section n'aura que peut d'intérêt pour vous, mais si ce n'est pas le cas, nous allons mettre en place un serveur SMTP dans la machine hôte (dom0) destiné à recevoir les emails des différentes machines virtuelles (domU) créées à l'aide de ce guide.

En premier lieu, nous configureons le domaine de mail de notre serveur SMTP. Il s'agit en général du nom de domaine du serveur. Chez OVH, il est assez simple de l'obtenir:

/bin/echo $HOSTNAME | /usr/bin/tee /etc/mailname

Remarque: Cette adresse doit être un nom de domaine valide et fonctionnel (ie. vous devez pouvoir le "pinger" depuis n'importe quelle machine de l'internet).

Nous renseignons maintenant l'adresse électronique destinée à recevoir les courriers envoyés par les machines virtuelles:

ADMIN_EMAIL=mon-email@yahoo.fr

Remarque: Il s'agit bien évidement de votre adresse électronique habituelle.

Nous appliquons cette configuration:

/bin/sed -i -e '/^root/d' /etc/aliases
echo "root: ${ADMIN_EMAIL}" | /usr/bin/tee -a /etc/aliases

Nous mettons maintenant en place le fichier de configuration d'Exim 4 correspondant à l'envoi direct d'email.

/bin/mkdir --parent /etc/exim4
/usr/bin/wget http://howto.landure.fr/gnu-linux/debian-4-0-etch/installer-et-configurer-xen-sur-debian-4-0-etch/update-exim4-conf.conf \
    --output-document=/etc/exim4/update-exim4.conf.conf

Remarque: Cette configuration correspond à un serveur dédié chez un fournisseur de services tel que OVH. Si vous hébergez votre serveur à la maison, vous devrez l'adapter à votre fournisseur d'accès. Je ne donnerais pas d'exemple de configuration correspondant à ce besoin, car je n'en ai pas l'utiliser moi-même. Mais si vous souhaitez faire une contribution, vous pouvez m'envoyer un email avec la configuration nécessaire en utilisant le bouton "contact" en haut à droite de ce site XD.

Nous mettons à jour notre configuration d'Exim 4 afin d'accepter les e-mails en provenance de nos machines virtuelles :

MAINDOM_RANGE=$(/bin/echo ${MAINDOM_IP} | /bin/sed -e 's/\(.*\)\.[0-9]*/\1/')
/bin/sed -i -e "s|dc_local_interfaces=.*\$|dc_local_interfaces='127.0.0.1;${MAINDOM_IP}'|" \
            -e "s|dc_relay_nets=.*\$|dc_relay_nets='${MAINDOM_RANGE}.0/24'|" \
         /etc/exim4/update-exim4.conf.conf

Nous pouvons maintenant installer Exim 4:

/usr/bin/apt-get install exim4

Remarque: si Exim 4 est déjà installé sur votre serveur, il vous suffit de mettre à jour la configuration avec la commande:

/usr/sbin/update-exim4.conf
/etc/init.d/exim4 restart

Nous allons maintenant tester votre nouvelle configuration. Pour ce faire, installez mailx:

/usr/bin/apt-get install mailx

Et lancez la commande suivante:

/bin/echo "test" | /usr/bin/mail -s "test" root

Résolution des problèmes

Si vous avez configuré Exim 4 correctement, vous devriez recevoir un email ayant pour sujet "test". Si au bout de quelques minutes vous n'avez rien reçu, vérifiez le résultat de la commande:

/usr/bin/mailq

et le contenu du fichier journal d'Exim:

tail -n 250 /var/log/exim4/mainlog

Si l'erreur rencontrée est du type :

root@my-hostname: Unrouteable address

Il s'agit d'un problème d'incohérence entre le contenu de la variable d'environement ${HOSTNAME} et le contenu du fichier /etc/hosts. Pour régler ce problème, il faut que le contenu du fichier /etc/mailname contienne "my-hostname.my-domain.lan". Pour ce faire, vous pouvez l'éditer manuellement, ou tenter cette ligne de commande (sans aucune garantie de succès) :

/bin/grep "${HOSTNAME}" /etc/hosts | /usr/bin/cut --field=2 | /usr/bin/tee /etc/mailname

Mettez à jour la configuration d'Exim4 :

/usr/sbin/update-exim4.conf
/etc/init.d/exim4 restart

Supprimer vos messages de tests gelés :

mailq | grep frozen | sed -e 's/.* \(.\{6\}-.\{6\}-.\{2\}\) .*/\1/' | xargs exim4 -Mrm

Et envoyez à nouveau un message de test :

/bin/echo "test" | /usr/bin/mail -s "test" root

Avec de la chance, cette nouvelle configuration a fonctionné. Pour le vérifier, il suffit de regarder si cette commande ne renvoie rien :

mailq

Configuration des sauvegardes

Ce guide met en place une architecture de sauvegardes relativement complexe basée sur l'utilisation de l'outil Backup Manager. Vos machines virtuelles (domU) rapatrieront leurs sauvegardes dans le dossier /var/archives de la machine hôte (dom0). Nous devons donc créer ce dossier:

/bin/mkdir /var/archives
/bin/chown root:backup /var/archives
/bin/chmod ug+rwx /var/archives

Une fois ceci-fait, votre machine hôte (dom0) peut recevoir les sauvegardes des machines virtuelles.

Installation de Backup Manager

Cela n'est toutefois pas suffisant puisque seules les machines virtuelles sont sauvegardées. Il faut aussi penser à sauvegarder la machine hôte. Pour ce faire je vous recommende d'installer Backup Manager en suivant mon guide:

Installer et configurer Backup Manager sur Debian 4.0 Etch

Une fois Backup Manager installé, nous devons le configurer afin que le dossier /var/archives puisse être inscriptible par les machines virtuelles, et que les archives des domU soient purgées en même temps que celles du dom0

/bin/sed -i -e 's/[#]*\(.*BM_REPOSITORY_GROUP=\).*$/\1"backup"/' \
            -e 's/[#]*\(.*BM_REPOSITORY_CHMOD=\).*$/\1"770"/' \
            -e 's/[#]*\(.*BM_ARCHIVE_STRICTPURGE=\).*$/\1"false"/' \
         /etc/backup-manager.conf

Je vous recommande de transférer vos archives sur un serveur tiers à l'aide de Backup Manager. Si vous utilisez un serveur OVH, cette société met à disposition des espaces de stockages FTP.

Configuration de la création des machines virtuelles par Xen Tools

Configuration par défaut

Par défaut, Xen Tools est configuré pour créer des machines virtuelles basées sur Debian 3.1 Sarge.Nous allons modifier cela. Utilisez la ligne de commande suivante pour faire en sorte de créer des machines virtuelles Debian 4.0 Etch ou 5.0 Lenny (suivant la distribution du Dom0) par défaut:

if [ "$(/bin/cat /etc/debian_version)" = "4.0" ]; then
  /bin/sed -i -e 's/^\(dist[ ]*=[ ]*\)[^ ]*\([ ]*#.*\)$/\1etch\2/' /etc/xen-tools/xen-tools.conf
else
  /bin/sed -i -e 's/^\(dist[ ]*=[ ]*\)[^ ]*\([ ]*#.*\)$/\1lenny\2/' /etc/xen-tools/xen-tools.conf
fi

De même, nous passons la taille par défaut du swap de 128Mo à 1Go (par sécurité, la plupart du temps, il n'est pas utilisé).

/bin/sed -i -e 's/^\(swap[ ]*=[ ]*\)[^ ]*\([ ]*#.*\)$/\11Gb\2/' /etc/xen-tools/xen-tools.conf

Remarque : Si vous disposez de peu d'espace disque, vous pouvez diviser par 2 la taille du swap et du root (c'est à dire passer respectivement de 1 Go et 4 Go à 512 Mo et 2 Go). Pour ce faire, utilisez cette commande :

/bin/sed -i -e 's/^\(size[ ]*=[ ]*\)[^ ]*\([ ]*#.*\)$/\12Gb\2/' \
            -e 's/^\(swap[ ]*=[ ]*\)[^ ]*\([ ]*#.*\)$/\1512Mb\2/' \
         /etc/xen-tools/xen-tools.conf

Nous déclarons que la méthode de création de machines virtuelles par défaut est "debootstrap":

/bin/sed -i -e 's/^[# ]*\(debootstrap[ ]*=\).*$/\1 1/' /etc/xen-tools/xen-tools.conf

Dans le cas ou nous utilisons le mode nat, nous confirons les paramètres réseau pour la création de machine virtuelles utilisant une adresse IP fixe:

if [ $(/bin/grep "^[^#]*nat" /etc/xen/xend-config.sxp | /usr/bin/wc --lines) -gt 0 ]; then
  /bin/sed -i -e 's/^[# ]*\(gateway[ ]*=\).*$/\1 10.0.0.128/' \
            -e 's/^[# ]*\(netmask[ ]*=\).*$/\1 255.255.255.0/' \
         /etc/xen-tools/xen-tools.conf
fi

Remarque : Dans le cas ou vous utilisez le mode bridge, vous pouvez configurer manuellement les paramètres de votre réseau local en éditant le fichier /etc/xen-tools/xen-tools.conf

Utilisation d'un volume LVM pour les disques

Nous allons maintenant configurer Xen pour utiliser un group de volumes LVM. Commencez par renseigner le nom du groupe de volumes à utiliser. La ligne de commande suivante trouve automatiquement le nom du premier groupe de volumes :

LVM_VG=$(/sbin/vgdisplay \
  | /bin/grep "VG Name" \
  | /usr/bin/head --lines=1 \
  | /usr/bin/cut --characters=25-)

Remarque : Si vous disposez de plus d'un groupe de volumes (cas relativement rare je pense), vous devriez spécifier manuellement le nom du groupe de volumes de destination :

LVM_VG=vhd3

Et modifiez la configuration de Xen:

/bin/sed -i -e "s/^# \(lvm = \).*/\1${LVM_VG}/" /etc/xen-tools/xen-tools.conf

Une fois ceci fait, nous configureons Xen Tools pour se baser sur le bon kernel lors de la création de machines virtuelles:

/bin/sed -i -e "s/^\(kernel =\).*\$/\1 \/boot\/vmlinuz-$(uname -r)/" \
            -e "s/^\(initrd =\).*\$/\1 \/boot\/initrd.img-$(uname -r)/" \
            /etc/xen-tools/xen-tools.conf

Configuration du miroir de téléchargement des paquets

Par défaut, le miroir APT utilisé est situé aux états unis. Il est préférable d'utiliser un miroir plus proche de chez vous:

APT_MIRROR=http://ftp.fr.debian.org/debian/

Remarque: si votre serveur est hébergé par OVH, vous pouvez utiliser le mirroir suivant:

APT_MIRROR=ftp://mir1.ovh.net/debian/

Appliquez la nouvelle configuration:

CLEAN_APT_MIRROR=$(/bin/echo $APT_MIRROR | sed -e 's/\//\\\//g')
/bin/sed -i -e "s/^\(mirror = \).*/\1$CLEAN_APT_MIRROR/" /etc/xen-tools/xen-tools.conf

Correction du problème "clocksource/0: Time went backwards"

Afin d'éviter que nos DomU deviennent inaccessibles après un redémarrage du Dom0 car leur CPU est occupé à 100%, et que le syslog se remplissent de messages "clocksource/0: Time went backwards", nous allons modifier le template Xen-Tools utilisé pour la création des fichiers de configuration des machines virtuelles, et y ajouter l'option "extra = 'clocksource=jiffies'" :

/bin/sed -i -e "/^on_crash/a\\
\\
# Preventing clocksource/0: Time went backwards\\
extra = 'clocksource=jiffies'" \
    /etc/xen-tools/xm.tmpl

Source : Merci à Anapivirtua pour son article clocksource/0: Time went backwards.

Création d'un rôle pour nos machines virtuelles

Afin de pouvoir gérer proprement nos machines virtuelles, nous allons créer un rôle qui effectue les manipulations suivantes sur chaque machines virtuelles que nous allons créer:

• Installation de paquets locales, sudo, ntp, cron-apt, logwatch, rkhunter, chkrootkit, vim, screen, backup-manager et fail2ban
• Création de l'utilisateur "xen-upgrade" avec sa clef ssh d'identification qui permettront d'automatiser les tâches de mise à jour (nous utilisons sudo pour cela).
• Configuration de Backup Manager pour sauvegarder les machines virtuelles et copier les sauvegardes dans le dossier /var/archives de la machine hôte (dom0).
  

En premier lieu, nous téléchargeons le fichier de configuration de notre nouveau rôle "automatic":

/usr/bin/wget http://howto.landure.fr/gnu-linux/debian-4-0-etch/installer-et-configurer-xen-sur-debian-4-0-etch/automatic \
    --output-document=/etc/xen-tools/role.d/automatic
/bin/chmod +x /etc/xen-tools/role.d/automatic

Nous créons l'utilisateur xen-backup dans la machine hôte (dom0):

/usr/sbin/adduser --system --shell /bin/sh --home /var/lib/xen-backup --disabled-password xen-backup

Et nous l'ajoutons au groupe backup

/usr/sbin/adduser xen-backup backup

Nous allons créer les clefs SSL permettant l'identification SSH sans saisie de mot de passe. Pour ce faire, créez le dossier destiné à contenir ces clefs dans l'hôte:

/bin/mkdir /etc/xen-tools/ssh-keys

Et créez les clefs pour l'identification automatique dans le comptes "xen-upgrade" créé par le rôle "automatic" et "xen-backup" créé sur la machine hôte (dom0) pour le rapatriement des sauvegardes.

/usr/bin/ssh-keygen -t rsa -C "upgrade account key" -N "" -f /etc/xen-tools/ssh-keys/xen-upgrade-rsa
/usr/bin/ssh-keygen -t rsa -C "backup account key" -N "" -f /etc/xen-tools/ssh-keys/xen-backup-rsa

Nous configureons le compte xen-backup pour pouvoir être accédé facilement à l'aide de la clef que nous venons de créer:

/bin/mkdir /var/lib/xen-backup/.ssh
/bin/cat /etc/xen-tools/ssh-keys/xen-backup-rsa.pub \
    | /usr/bin/tee -a /var/lib/xen-backup/.ssh/authorized_keys
/bin/chown -R xen-backup:nogroup /var/lib/xen-backup/.ssh

Nous installons aussi le script permettant de mettre à jour les machines virtuelles (domU) depuis la machine hôte (dom0):

/usr/bin/wget http://howto.landure.fr/gnu-linux/debian-4-0-etch/installer-et-configurer-xen-sur-debian-4-0-etch/xen-apt-get \
    --output-document=/usr/bin/xen-apt-get
/bin/chmod +x /usr/bin/xen-apt-get

Ce script permet de mettre à jour toutes les machines virtuelles avec ces deux commandes:

xen-apt-get update
xen-apt-get upgrade

Ou une machine virtuelle spécifiques, vous obtiendrez plus d'information sur son utilisation avec la commande:

xen-apt-get

Accès facilité aux machines virtuelles (optionnel)

Si vous ne souhaitez pas utiliser l'identification par mot de passe pour les comptes root des machines virtuelles, vous pouvez créer une clef pour l'identification automatique de l'utilisateur root du dom0 dans le compte root des domU. Le rôle "automatic" en tiendra automatiquement compte si elle est présente. Veillez toutefois à la protéger par une passphrase. Utilisez la commande suivante pour créer une paire RSA pour votre utilisateur root si cela est nécessaire :

if [ ! -e ${HOME}/.ssh/id_rsa ]; then
  /usr/bin/ssh-keygen -t rsa -f ${HOME}/.ssh/id_rsa
fi

Configuration du squelette des machines virtuelles

Nous allons mettre en place quelque fichiers de configuration (Exim 4, bash et vim principalement) de façon à minimiser les configurations à modifier dans les machines virtuelles.

En premier lieu, nous créons l'arborescence des dossiers contenant les fichiers de notre squelette (il s'agit de l'arborescence standard de Linux: le squelette est copié tel quel dans la machine virtuelle):

/bin/mkdir --parent /etc/xen-tools/skel/root
/bin/mkdir --parent /etc/xen-tools/skel/root/.ssh
/bin/mkdir --parent /etc/xen-tools/skel/etc/default
/bin/mkdir --parent /etc/xen-tools/skel/etc/exim4
/bin/mkdir --parent /etc/xen-tools/skel/etc/cron.d
/bin/mkdir --parent /etc/xen-tools/skel/etc/apt/apt.conf.d
/bin/mkdir --parent /etc/xen-tools/skel/etc/xen-data
/bin/mkdir --parent /etc/xen-tools/skel/usr/bin

Nous copions les fichiers de configuration de la machine hôte que nous souhaitons voir appliqués dans la machine virtuelle (Bash, Vim, fuseau horaire, langue):

/bin/cp /root/.bashrc /etc/xen-tools/skel/root/
if [ -e /root/.vimrc ]; then
  /bin/cp /root/.vimrc /etc/xen-tools/skel/root/
fi
/bin/cp /etc/timezone /etc/xen-tools/skel/etc/
/bin/cp /etc/localtime /etc/xen-tools/skel/etc/
/bin/cp /etc/locale.gen /etc/xen-tools/skel/etc/
/bin/cp /etc/environment /etc/xen-tools/skel/etc/
/bin/cp /etc/default/locale /etc/xen-tools/skel/etc/default/

Remarque: Une partie de ceci est valide uniquement pour les machines virtuelles Debian 4.0 Etch et 5.0 Lenny (mais ca marche bien sur Ubuntu quand même XD).

Nous ajoutons le script de mise à jour de la base des signatures de fichiers de RkHunter après utilisation de Apt :

/bin/echo '// Update rkhunter file signatures databases after running dpkg.
DPkg::Post-Invoke {
  "if [ -x /usr/bin/rkhunter ]; then if [ $(/usr/bin/rkhunter --help | /bin/grep "propupd" | /usr/bin/wc -l) -gt 0 ]; then /usr/bin/rkhunter --propupd; fi; fi";
};' | /usr/bin/tee /etc/xen-tools/skel/etc/apt/apt.conf.d/90rkhunter

Nous y ajoutons la configuration d'Exim4 de façon à ce que tous les e-mails de la machine virtuelle (domU) soient redirigés vers le serveur Exim de la machine hôte (que nous avons configuré plus haut dans cette page):

/usr/bin/wget http://howto.landure.fr/gnu-linux/debian-4-0-etch/installer-et-configurer-xen-sur-debian-4-0-etch/update-exim4-conf-conf.xen \
    --output-document=/etc/xen-tools/skel/etc/exim4/update-exim4.conf.conf
/bin/sed -i -e "s/dc_smarthost=.*\$/dc_smarthost='${MAINDOM_IP}'/" \
         /etc/xen-tools/skel/etc/exim4/update-exim4.conf.conf
echo "root@$(/bin/cat /etc/mailname)" > /etc/xen-tools/skel/root/.email

Et nous ajoutons la clef publique de la machine hôte aux clefs autorisées du client SSH pour que les sauvegardes puissent se dérouler correctement:

/usr/bin/ssh-keyscan -H -t rsa ${MAINDOM_IP} | /usr/bin/tee /etc/xen-tools/skel/root/.ssh/known_hosts

De même, nous ajoutons la clef publique du compte root du dom0 aux clefs autorisées du compte root des domU:

if [ -e ${HOME}/.ssh/id_rsa.pub ]; then
    /bin/cat ${HOME}/.ssh/id_rsa.pub \
        | /usr/bin/tee -a /etc/xen-tools/skel/root/.ssh/authorized_keys
fi

Configuration des sauvegardes

Le rôle automatic installe l'outil de sauvegarde Backup Manager. La plupart des guides présents sur ce site seront mis à jour avec les informations nécessaires pour gérer les sauvegardes des données avec cet outil. Nous allons ici configurer la sauvegarde des données de nos machines virtuelles avec cet outil.

En premier lieu, nous ajoutons le script update-bm-folders présenté dans mon guide Installer et configurer Backup Manager sur Debian 4.0 Etch au squelette des machines virtuelles:

/usr/bin/wget http://howto.landure.fr/gnu-linux/debian-4-0-etch/installer-et-configurer-backup-manager-sur-debian-4-0-etch/update-bm-folders \
    --output-document=/etc/xen-tools/skel/usr/bin/update-bm-folders
/bin/chmod +x /etc/xen-tools/skel/usr/bin/update-bm-folders

Nous téléchargeons la configuration par défaut du Backup Manager pour les machines virtuelles:

/usr/bin/wget http://howto.landure.fr/gnu-linux/debian-4-0-etch/installer-et-configurer-xen-sur-debian-4-0-etch/backup-manager.conf \
    --output-document=/etc/xen-tools/skel/etc/backup-manager.conf
/bin/sed -i -e "s|[#]*\(.*BM_UPLOAD_SSH_HOSTS=\).*$|\1\"${MAINDOM_IP}\"|" \
         /etc/xen-tools/skel/etc/backup-manager.conf

Et enfin, nous ajoutons la clef privée d'identification du compte xen-backup de la machine hôte à notre squelette:

/bin/cp /etc/xen-tools/ssh-keys/xen-backup-rsa /etc/xen-tools/skel/etc/xen-data/

Création d'une machine virtuelle Xen

Installation du système de base

Nous allons maintenant créer notre première machine virtuelle Xen. En premier lieu, nous configurons son nom d'hôte:

XEN_HOSTNAME=xen-vm1

Renseignez la configuration réseau de votre machine virtuelle:

IP_ADDRESS=10.0.0.3

Puis créez la machine virtuelle en utilisant ces paramètres à l'aide des commandes ci-dessous.

Important: Ne perdez pas le mot de passe que vous saisissez dans ces commandes, il s'agit du mot de passe de vos machines virtuelles.

• Pour la distribution par défaut (Debian 4.0 Etch ou 5.0 Lenny):
  

  /usr/bin/xen-create-image --hostname $XEN_HOSTNAME \
      --ip $IP_ADDRESS --passwd --role automatic
  

  Remarque: Pour créer une machine virtuelle obtenant son adresse IP par DHCP (ce qui peut être intéressant si vous utilisez le mode bridge pour le réseau des domU, vous pouvez utiliser la commande:

  /usr/bin/xen-create-image --hostname $XEN_HOSTNAME \
      --dhcp --passwd --role automatic
  

• Pour Ubuntu 8.04 Hardy Heron:
  

  /usr/bin/xen-create-image --hostname $XEN_HOSTNAME \
      --ip $IP_ADDRESS --passwd --role automatic \
      --dist=hardy --mirror=http://archive.ubuntu.com/ubuntu/
  

  Remarque: Pour créer une machine virtuelle obtenant son adresse IP par DHCP (ce qui peut être intéressant si vous utilisez le mode bridge pour le réseau des domU, vous pouvez utiliser la commande:

  /usr/bin/xen-create-image --hostname $XEN_HOSTNAME \
      --dhcp --passwd --role automatic \
      --dist=hardy --mirror=http://archive.ubuntu.com/ubuntu/

Remarque : Les DomU sous Ubuntu posent parfois des problèmes de configuration des locales. Il y a deux actions a effectuer pour résoudre les problème. Générer vos locales:

locale-gen fr_FR.UTF-8

et modifier le fichier /etc/environment pour qu'il contienne "LANG=fr_FR.UTF-8". Une fois ces deux actions effectuées, redémarrez le domU pour les prendre en compte (il y a sans doute une autre méthode, mais celle la est la plus simple :)

Création d'une partition pour le /var

Une fois ceci fait, nous y ajoutons une partition /var de 10 Giga octets. Commencez par renseignez la taille souhaitée pour la partition :

VAR_SIZE=10g

Créez ensuite le volume logique de la partition :

LVM_VG=$(/bin/grep lvm /etc/xen-tools/xen-tools.conf | /bin/sed -e 's/lvm = //')
/sbin/lvcreate -n $XEN_HOSTNAME-var -L ${VAR_SIZE} $LVM_VG
/sbin/mkfs.ext3 /dev/$LVM_VG/$XEN_HOSTNAME-var

Nous modifions la configuration de la machine virtuelle pour prendre en compte cette partition:

if [ $(/bin/grep "disk[\t ]*=.*\]" /etc/xen/$XEN_HOSTNAME.cfg | /usr/bin/wc --lines) -eq 0 ]; then
  /bin/sed -i -e "/^disk[\t ]*=.*/a\\
    'phy:$LVM_VG\/$XEN_HOSTNAME-var,sda3,w'," \
         /etc/xen/$XEN_HOSTNAME.cfg
else
  /bin/sed -i -e "s/^\(disk[\t ]*=.*\)\]/\1, 'phy:$LVM_VG\/$XEN_HOSTNAME-var,sda3,w' ]/" /etc/xen/$XEN_HOSTNAME.cfg
fi

Et nous modifions de même le fichier fstab de la machine virtuelle:

/bin/umount /dev/$LVM_VG/$XEN_HOSTNAME-disk
MOUNT_POINT=$(/bin/mktemp -d)
/bin/mount /dev/${LVM_VG}/${XEN_HOSTNAME}-disk ${MOUNT_POINT}
/bin/echo "/dev/sda3   /var    ext3    defaults                0       1" | /usr/bin/tee -a ${MOUNT_POINT}/etc/fstab
VAR_MOUNT_POINT=$(/bin/mktemp -d)
/bin/mount /dev/${LVM_VG}/${XEN_HOSTNAME}-var ${VAR_MOUNT_POINT}
/bin/cp -a ${MOUNT_POINT}/var/* ${VAR_MOUNT_POINT}
/bin/umount ${VAR_MOUNT_POINT}
/bin/umount ${MOUNT_POINT}

Démarrage de la machine virtuelle (domU)

Nous pouvons maintenant démarrer notre nouveau serveur virtuel (aka. domaine):

/usr/sbin/xm create /etc/xen/$XEN_HOSTNAME.cfg

Vous pouvez obtenir la liste des domaines démarré à l'aide de la commande:

/usr/sbin/xm list

Nous allons utiliser SSH pour nous connecter à notre nouvelle machine virtuelle:

/usr/bin/ssh root@$XEN_HOSTNAME

Remarque: Si vous avez créé une clef d'identification pour votre compte root, vous devez saisir le mot de passe de cette clef, et non celui du compte root du DomU Xen.

Accès "matériel" à la machine virtuelle

En cas de problème pour vous connectez en SSH à votre machine virtuelle, vous pouvez accéder à la console de votre domaine récemment créé:

/usr/sbin/xm console $XEN_HOSTNAME

Attention: La console Xen se comporte comme une console série réelle. Cela pose problème avec vim.

Pour quitter cette console, utilisez le raccourci clavier: <Ctrl> <Alt Gr> <]>.

Ouverture des ports des machines virutelles en mode NAT

Si vous souhaitez que vos machines virtuelles hébergent des serveurs (sinon, pourquoi créer des machines virtuelles XD), il est nécessaire d'ouvrir les ports à l'aide d'IP tables. En effet, configurer Xen en mode NAT revient à créer un pare-feu naturel. Il faut donc configurer le routage des ports en NAT à l'aide d'IP tables. Si vous avez déjà créé votre propre passerelle Internet, vous savez probablement de quoi je parle.

En premier lieu, si vous ne l'avez pas déjà fait, nous allons créer le fichier destiné à contenir les règles Iptables. Ces règles seront appliquées après le démarrage des interfaces réseaux:

if [ ! -e /etc/network/if-up.d/iptables ]; then
  echo '#!/bin/sh
# IpTables rules.

# Purging prerouting rules before reloading them
iptables -t nat -F PREROUTING' | /usr/bin/tee /etc/network/if-up.d/iptables
fi
/bin/chmod +x /etc/network/if-up.d/iptables

Nous autorisons le NAT sur le système :

sed -i -e 's/[# ]*\(net\.ipv4\.conf\.default\.forwarding=\).*/\11/g' \
       -e 's/[# ]*\(net\.ipv4\.ip_forward=\).*/\11/g' \
    /etc/sysctl.conf
echo 1 > /proc/sys/net/ipv4/ip_forward

Ouverture d'un port

En premier lieu, renseignez les paramètres du port que vous souhaitez ouvrir. C'est à dire, l'adresse IP de la machine virtuelle dont vous souhaitez ouvrir le port :

VM_IP=10.0.0.1

et le numéro du port à ouvrir :

VM_PORT=80

Vous pouvez maintenant ouvrir effectivement le port :

iptables -A PREROUTING -t nat -p tcp -i eth0 --dport ${VM_PORT} -j DNAT --to ${VM_IP}:${VM_PORT}

Et nous faisons en sorte qu'elle s'execute au démarrage du système :

echo "
# Opening port ${VM_PORT} for IP address ${VM_IP} :
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport ${VM_PORT} -j DNAT --to ${VM_IP}:${VM_PORT}" \
    | /usr/bin/tee -a /etc/network/if-up.d/iptables

Votre configuration iptables sera rechargée à chaque redémarrage par la suite.

A la fin de cette procédure, vous devrier pouvoir accéder au serveur hébergé par la machine virtuelle en saisissant pour adresse l'IP du serveur matériel.

Démarrage automatique des machines virtuelles

Si vous souhaitez que certaines de vos machines virtuelles démarrent automatiquement avec votre système (souhaitable si ce guide vous sert à mettre en oeuvre un serveur), il vous faut en premier lieu créer un dossier nommé auto:

/bin/mkdir --parent /etc/xen/auto

Une fois ceci-fait, placez les fichiers de configuration des machines virtuelles que vous souhaitez voir démarrées automatiquement dans ce dossier. Par exemple, pour la machine virtuelle "apache2", exécutez la commande:

/bin/mv /etc/xen/httpd.cfg /etc/xen/auto/

Quelques lignes de commandes

Dans certains cas il peut être utile d'appliquer une commande à tous les domU créés. Pour ce faire, vous pouvez utiliser cette ligne de commande (ici pour la commande destroy) :

xm list | tail -n +3 | cut -d " " -f 1 | xargs -I DOMU xm destroy DOMU

De même, si vous souhaitez lancez tous les domU devant être lancés automatiquement :

find /etc/xen/auto -name "*.cfg" -print0 | xargs -0 -I DOMU_CFG xm create DOMU_CFG

Ou encore copier un fichier sur tous les DomU existants :

xm list | tail -n +3 | cut -d " " -f 1 | xargs -I DOMU scp -pr sudoers DOMU:/etc/sudoers

Remerciements

• Merci à Michele Petrazzo pour son article Debian Etch And Xen From The Debian Repository.
• Merci à TMS pour son article Sécuriser l’accès au serveur openssh avec une authentification par clés sur Génération Libre.
• Merci aux développeurs du logiciel de sauvegarde Backup Manager.
  
• Merci à Nyarla sur irc.freenode.net#ubuntu-fr pour avoir répondu à mes questions sur Backup Manager.
• Merci à l'auteur du guide Backup Manager sur la documentation Ubuntu francophone.
• Merci à Falko pour son guide The Perfect Xen 3.1.0 Setup For Debian Etch.
• Merci à l'auteur de la page Xen Networking sur le wiki dedié à Xen.
• Merci à GaB pour son article Manage SSH known_hosts entries.