Découverte de XEN sur Debian Wheezy
Classé dans : Serveur, Virtualisation, Réflexions | 3 commentaires | publié le 08 avril 2014

XEN n'est pas nouveau pour moi, j'en parlais sur ce blog en 2011. Mais à l'exception de la solution XenServer, c'était relativement obscur, compliqué, et déprécié par les distributions Linux au profil de solutions alternatives (KVM et LXC). Je pensais vraiment que Xen allait disparaitre ou sombrer dans l'oubli. En fait non car en 2014 non seulement XEN est toujours très utilisé (par exemple chez AWS, le cloud Amazon), mais il est en plus upstream dans le kernel Linux et géré par la Linux Fundation. Il est donc revenu en force dans toutes les distributions Linux. J'ai été surpris de constater que maintenant on peut l'installer et l'utiliser très facilement sur Debian Wheezy, je vais partager mon expérience sur cet article ;)

Notions Dom0 et DomU

Sur des hyperviseurs comme Hyper-V ou VMware nous sommes habitués à exécuter des machines virtuelles depuis l'hôte. Or sur XEN cette notion est différente, l'hôte devient une machine virtuelle XEN avec des privilèges d'administration nommée Dom0. Donc au démarrage votre serveur doit démarrer XEN et ensuite le Dom0 sur lequel vous vous connectez. On peut limiter la RAM et les vcpus de Dom0 comme pour les autres.

Les autres VMs que l'on va faire tourner sur XEN, et qui elles n'ont pas de privilèges particuliers, sont nommés DomU. Voici un schéma pour récapituler :

Dans le cas de cet article, le Dom0 est Debian Wheezy. Cela peut paraître assez abstrait comme ça, mais si vous le mettez en oeuvre, vous comprendrez !

Installation de Debian

L'installation se fait à partir d'une ISO tout à fait normale de Debian. Personnellement je suis parti sur une Wheezy amd64 en netinstall, donc la debian-7.4.0-amd64-netinst.iso. Il est possible d'utiliser LVM avec XEN, mais je préfère faire simple pour le moment, je choisis donc un partitionnement assisté avec tout dans une même partition.

Installation de XEN

Sur une Debian Wheezy fraichement installée, il suffit d'installer le paquet xen-hypervisor :

# apt-get install xen-hypervisor

Boot automatique sur Xen

Passer Xen en priorité dans grub :

# dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen
# update-grub

Configuration du réseau (bridge)

Il suffit de modifier le fichier /etc/network/interfaces pour avoir un Bridge. Exemple pour moi qui suis en DHCP :

#The loopback network interface
auto lo
iface lo inet loopback

iface eth0 inet manual

auto xenbr0
iface xenbr0 inet dhcp
   bridge_ports eth0

Note : Si comme moi vous faites vos essais dans VirtualBox, méfiance. Si on utilise déjà un pont dans VirtualBox, xenbr0 ne fonctionnera pas correctement (les domU peuvent pinger dom0 mais pas internet). J'ai pas mal bloqué sur ce problème et finalement la solution consiste à laisser VirtualBox en NAT.

Installation des Xen Tools

Xen-tools permet de créer facilement des domU à partir de templates, et c'est la solution la plus simple :

# apt-get install xen-tools

Configuration du template Xen Tools

On édite le fichier /etc/xen-tools/xen-tools.conf. Voici les lignes à modifier pour notre cas :

dir = /home/xen
size   = 10Gb      # Disk image size.
fs     = ext4     # use the EXT4 filesystem for the disk image.
bridge = xenbr0
ext4_options     = noatime,nodiratime,errors=remount-ro

Et voilà.

Déploiement d'un DomU Debian

Note : Il faut prendre soin de rebooter après les manipulations précédentes, afin d'avoir Xen et le Dom0 opérationnels avant d'aller plus loin.

Voici la commande pour créer un hôte de type Debian Wheezy qui sera nommé Wheezy :

# xen-create-image --hostname wheezy --dhcp --vcpus 1 --pygrub --dist wheezy

WARNING
-------

  You appear to have a missing vif-script, or network-script, in the
 Xen configuration file /etc/xen/xend-config.sxp.

  Please fix this and restart Xend, or your guests will not be able
 to use any networking!


General Information
--------------------
Hostname       :  wheezy
Distribution   :  wheezy
Mirror         :  http://ftp.fr.debian.org/debian/
Partitions     :  swap            128Mb (swap)
                  /               10Gb  (ext4)
Image type     :  full
Memory size    :  128Mb
Kernel path    :  /boot/vmlinuz-3.2.0-4-amd64
Initrd path    :  /boot/initrd.img-3.2.0-4-amd64

Networking Information
----------------------
IP Address     : DHCP [MAC: 00:16:3E:EB:96:45]


Creating swap on /dev/vg0/wheezy-swap
Done

Creating ext4 filesystem on /dev/vg0/wheezy-disk
Done
Installation method: debootstrap
Done

Running hooks
Done

No role scripts were specified.  Skipping

Creating Xen configuration file
Done

No role scripts were specified.  Skipping
Setting up root password
Generating a password for the new guest.
All done


Logfile produced at:
	 /var/log/xen-tools/wheezy.log

Installation Summary
---------------------
Hostname        :  wheezy
Distribution    :  wheezy
IP-Address(es)  :  dynamic
RSA Fingerprint :  83:21:28:49:d9:93:38:ae:5a:11:41:23:fa:3a:6e:05
Root Password   :  UzNRAZe4

Pour démarrer notre DomU :

# xm create wheezy.cfg 
Using config file "/etc/xen/wheezy.cfg".
Started domain wheezy (id=2)

Pour se connecter à ce DomU, deux possibilités : avec SSH si on connaît l'IP, ou avec la commande xm console :

# xm console wheezy

Pour en sortir, arrêter la VM, ou utiliser la combinaison CTRL+]

Pour arrêter le DomU depuis le Dom0, utiliser la commande xen-delete-image :

# xm destroy wheezy

Note : la commande xm destroy va provoquer l'arrêt brutal du domU.

Déploiement d'un DomU NetBSD

Bon un DomU en Debian c'était facile parce qu'on peut utiliser xen-tools qui automatise tout. Maintenant la même chose avec NetBSD, qu'il va falloir installer à la main. Tout d'abord, on télécharge et on extrait la version installable et la version normale de NetBSD version Xen :

# wget ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.1.3/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
# wget ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.1.3/amd64/binary/kernel/netbsd-XEN3_DOMU.gz
# gunzip netbsd-INSTALL_XEN3_DOMU.gz
# gunzip netbsd-XEN3_DOMU.gz

Ensuite on doit créer un fichier une image qui servira de support de stockage pour le DomU :

# mkdir -p /home/xen/domains/netbsd
# dd if=/dev/zero of=/home/xen/domains/netbsd/disk.img bs=1 count=0 seek=10G

Création d'un fichier de configuration pour notre domU NetBSD (il est possible de copier celui du domU Wheezy précédemment créé pour aller plus vite puis le modifier) :

# vi /etc/xen/netbsd.cfg
kernel = "/root/netbsd-INSTALL_XEN3_DOMU"
memory = '128'
disk = [
'file:/home/xen/domains/netbsd/disk.img,xvda1,w';
]
name = 'netbsd'
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:EB:96:41,bridge=xenbr0' ]

On démarre notre domU NetBSD créé (cette fois l'argument c va directement connecter la console) :

# xm create -c netbsd.cfg

On obtient ceci :

Il faut maintenant procéder à une installation personnalisée, en sélectionnant uniquement base et system (pas besoin du kernel qui ne sera pas utilisé car GENERIC) et une source HTTP ou FTP (l'équivalent du netinstall) pour récupérer les paquets.

Si tout se passe bien :

Une fois l'installation terminée, il faut modifier le netbsd.cfg pour utiliser l'autre kernel :

# vi /etc/xen/netbsd.cfg
kernel = "/root/netbsd-XEN3_DOMU"

Il est maintenant possible de booter sur NetBSD :

# xm create -c netbsd.cfg

Conclusion

Xen est relativement simple à utiliser sur Debian Wheezy, grâce à Xen-tools qui facilite la création de domU à partir d'un template. Quand il s'agit de créer un domU "exotique" comme NetBSD, la procédure est un peu plus longue mais reste simple et logique. Il se positionne donc comme une solution intéressante pour les serveurs n'ayant pas le support de la virtualisation complète (Intel VT-X / AMD-V). Néanmoins lorsque ces instructions sont disponibles, les solutions alternatives telles que KVM ou ses concurrents propriétaires (Hyper-V, VMware...) me semblent toujours beaucoup plus simples à administrer et offrent des performances excellentes. Y a-t-il toujours un avenir à la paravirtualisation, qui est à mi chemin entre les containers (LXC, jails...) et la virtualisation complète ? A voir...

Mon bilan est positif sur l'utilisation, mais je me questionne toujours sur la pertinence de Xen en 2014.

Ressources

Migration du serveur sous FreeBSD 9.2
Classé dans : Serveur, Virtualisation, OS, Planet-Libre | 1 commentaire | publié le 22 janvier 2014

EDIT : Oui je sais, FreeBSD 10 vient de sortir, je suis d'ailleurs l'un des auteurs de cette dépêche sur Linuxfr. Mais quand j'ai commencé à migrer mon serveur, c'était encore la 9.2 qui était stable. Et avec les jails et les ports je préfère éviter de tourner sur les versions non stables...

Puisque mon serveur perso n'est pas critique (je peux me permettre une coupure d'une journée) j'en profite changer l'OS assez souvent, en quête de la perle rare ou tout simplement pour apprendre de nouvelles choses. Actuellement mon serveur ne sert que pour Jabber et la messagerie, mais à terme j'aimerai récupérer l'hébergement de mon blog (web). Or je souhaite séparer la partie web et messagerie pour la sécurité. Pour cela plusieurs solutions :

  • Utiliser 2 serveurs : très consommateur en énergie et prend plus de place.
  • Utilisez Linux + KVM (virtualisation) : incompatible avec mon serveur (Atom 32 bits).
  • Utiliser Linux + LXC ou Linux + OpenVZ : LXC déjà exploré j'ai envie d'autre chose.
  • Utiliser FreeBSD + Jails : Ouais !!!

Schéma cible

Compilation vs packages binaires

Bien que mon serveur soit de faible puissance, j'ai choisi de compiler moi-même les ports. Pourquoi ? Simplement parce que les packages binaires sont trop basiques et n'incluent pas les options sont j'ai besoin. Exemple : pour le serveur web, j'avais besoin du support fpm pour php. Or le seul moyen pour avoir cela c'est de compiler soi-même le paquet php55 et activer l'option fpm. Avec le package binaire officiel, pas de fpm.

Hôte : TARDIS

L'hôte est FreeBSD 9.2 i386 installé en UFS, avec les rôles d'hôte pour les jails et serveur DNS (named). Pour l'instant uniquement du cache, on verra ultérieurement s'il y a besoin de déclarer des zones. Named est installé dans le système de base, donc aucune manipulation particulière à faire à part l'activer dans le rc.conf et commenter la petite ligne dans /var/named/etc/namedb/named.conf qui spécifie qu'il ne faut écouter qu'en 127.0.0.1. Pour gérer mes jails, j'utilise ezjail, un outil de fainéant qui permet non seulement de tout gérer très facilement, mais en plus de générer un template avec des montages dynamiques.

root@TARDIS:~ # jls

   JID  IP Address      Hostname                      Path

     1  192.168.0.4     xmpp                          /usr/jails/xmpp

     2  192.168.0.3     www                           /usr/jails/www

     3  192.168.0.2     mail                          /usr/jails/mail

Pour que toutes mes nouvelles jail utilisent le bon serveur DNS, il faut éditer le fichier /usr/jails/newjail/etc/resolv.conf et ajouter l'IP qui va bien.

Jail : mail

La jail mail est destinée à recevoir, stocker, envoyer des mails. J'utilise un backend sqlite que j'ai mis en place en suivant ce tutoriel très complet (légère adaptation à faire pour utiliser sqlite à la place de mysql). Il faut commencer par installer dovecot2 en activant le support sqlite. Puis on installe Postfix en activant aussi le support sqlite mais également l'authentification SASL via dovecot. Je voulais que mon serveur de messagerie puisse gérer plusieurs domaines, d'où mon choix d'une structure plus complexe avec un backend sql.

Lorsqu'un mail est reçu, il est traité par Postfix qui vérifie dans la base sqlite si le domaine existe bien. Si oui il le transmet alors à Dovecot qui va se charger de le stocker à l'emplacement qui va bien. Lorsqu'un utilisateur veut envoyer un mail, il le soumet à Postfix (submission 587) qui demande à Dovecot si l'utilisateur est authentifié. Tous les échanges sont sécurisés en STARTTLS.

Jail : www

La jail www est destinée à faire office de serveur web. Pour l'installation de php, il faut compiler php55 avec le support de fpm, mais aussi php55-extensions qui permet de supporter session, gd (requis par pluxml), et d'autres si besoin.

C'est sur cette jail que mon blog (maniatux.fr) sera bientôt rapatrié. L'adresse e-mail de contact sera elle rapatriée sur la jail précédente (mail) car comme je l'ai indiqué, je peux gérer plusieurs domaines. Pluxml étant très léger et sans base de données, le serveur devrait tenir.

Jail : xmpp

La jail xmpp est destinée à faire office de serveur Jabber. J'utilise une fois de plus Prosody, que j'ai couplé avec sqlite pour le stockage des comptes (je n'aime pas le stockage en clair dans /var/lib/prosody qui est utilisé par défaut). La mise en place a été assez compliquée car en cas d'erreur, Prosody refuse de démarrer mais n'indique pas pourquoi. J'ai du spécifier un emplacement pour les logs et mettre les bons droits dessus (chown -R prosody:wheel) afin d'avoir un debug. En fait il n'arrivait pas à écrire le pid. Pour pouvoir utiliser sqlite il faut installer le port luadbi avec l'option sqlite. Après avoir un peu bataillé, ça marche.

Charge système

root@TARDIS:~ # df -h

Filesystem             Size    Used   Avail Capacity  Mounted on

/dev/ada0p2            140G    2.5G    126G     2%    /

devfs                  1.0k    1.0k      0B   100%    /dev

devfs                  1.0k    1.0k      0B   100%    /var/named/dev

/usr/jails/basejail    140G    2.5G    126G     2%    /usr/jails/xmpp/basejail

devfs                  1.0k    1.0k      0B   100%    /usr/jails/xmpp/dev

fdescfs                1.0k    1.0k      0B   100%    /usr/jails/xmpp/dev/fd

procfs                 4.0k    4.0k      0B   100%    /usr/jails/xmpp/proc

/usr/jails/basejail    140G    2.5G    126G     2%    /usr/jails/www/basejail

devfs                  1.0k    1.0k      0B   100%    /usr/jails/www/dev

fdescfs                1.0k    1.0k      0B   100%    /usr/jails/www/dev/fd

procfs                 4.0k    4.0k      0B   100%    /usr/jails/www/proc

/usr/jails/basejail    140G    2.5G    126G     2%    /usr/jails/mail/basejail

devfs                  1.0k    1.0k      0B   100%    /usr/jails/mail/dev

fdescfs                1.0k    1.0k      0B   100%    /usr/jails/mail/dev/fd

procfs                 4.0k    4.0k      0B   100%    /usr/jails/mail/proc

L'espace disque utilisé est de 2,5GB, sachant que l'on compte le système de base, le template, et l'arbre de ports. C'est assez intéressant. Voyons maintenant la charge CPU et mémoire :

last pid: 12938;  load averages:  0.00,  0.00,  0.00    up 0+22:54:08  13:14:23

48 processes:  1 running, 47 sleeping

CPU:  1.1% user,  0.0% nice,  1.5% system,  0.2% interrupt, 97.2% idle

Mem: 55M Active, 216M Inact, 113M Wired, 69M Buf, 589M Free

Swap: 4096M Total, 4096M Free

En gros même avec 3 VPS le système est très peu sollicité : 55Mo de mémoire utilisé, et CPU à 3% de charge.

Supervision

Pour assurer la supervision j'utilise tout simplement logwatch. C'est un script qui génère un rapport et envoie régulièrement un mail qui indique l'espace disque, les connexions ssh, les tentatives infructueuses d'accès à certain services. Logwatch peut être installé à partir de /usr/ports/sysutils/logwatch. Ensuite il faut spécifier Output = mail dans le logwatch.conf et ajouter un cron (@daily /usr/local/sbin/logwatch.pl).

On peut soit installer logwatch sur l'hôte uniquement, soit le mettre sur chaque jail. J'ai choisi la deuxième option pour avoir plus de détails.

Sur le serveur mail, c'est Postfix qui est utilisé pour l'envoi du rapport. Par contre sur les autres jail, j'ai laissé sendmail. Il faut éditer le fichier /etc/mail/freebsd.mc puis spécifier :

define(`SMART_HOST', `192.168.0.2')

Sauvegarder puis entrer :

m4 /etc/mail/freebsd.mc > /etc/mail/freebsd.cf

Sendmail va ensuite utiliser notre relay. Pas besoin de l'activer dans le rc.conf car il ne fonctionne pas comme un daemon dans ce cas là.

Sauvegarde

Pour les sauvegardes on parle beaucoup de bacula ou rsync. Dans mon cas j'ai choisi de faire plus simple car : 1) bacula est adapté pour les grosses infra avec plusieurs serveurs et du stockage dédié 2) rsync nécessite un support de stockage distant que je n'ai pas (mon NAS ne tourne pas 24/24). Donc je me contente d'un simple script sh :)

#!/bin/sh

tar -zcvf /root/"sauvegarde-`date -v-1d +%B-%Y`".tar.gz \

/etc \

/var/named/etc \

/usr/jails/mail/etc \

/usr/jails/mail/home \

/usr/jails/mail/usr/local/etc \

/usr/jails/www/etc \

/usr/jails/www/home \

/usr/jails/www/usr/local/etc \

/usr/jails/xmpp/etc \

/usr/jails/xmpp/home \

/usr/jails/xmpp/usr/local/etc

Et dans crontab -e :

@monthly /root/sauvegarde.sh

Le 1er du mois à minuit le script sera exécuté, et dans son nom il sera indiqué le mois (précédent). Ainsi une sauvegarde exécutée le 1er Fevrier 2014 sera nommée January-2014.tar.gz si tout se passe bien.

Je n'ai pas de bases de données dont pas besoin d'arrêter les jail avant la sauvegarde. Je sauvegarde les /etc qui contiennent la configuration et les /home qui contiennent les données. Pas besoin du reste.

Note : ezjail-admin permet de sauvegarder les jails, mais je ne l'utilise pas en raison de deux inconvénients majeurs : 1) ça sauvegarde tout incluant l'arbre des ports, ce qui est long et inutile 2) ça nécessite d'arrêter la jail, et je n'ai pas envie d'avoir des interruptions de service à chaque sauvegarde, on est pas sur Windows Server.

Conclusion

FreeBSD ça envoie du rêve, c'est très puissant, ezjail-admin est un outil qui m'a fait franchir le pas. On gère ses jails avec une facilité déconcertante. Je suis volontairement resté vague sur cet article, car le but était de présenter un retour d'expérience, et non un tutoriel qui aurait été de toutes manières trop long. Si vous vous lancez dans l'aventure et souhaitez obtenir mes fichiers de configuration ou des explications, n'hésitez pas !

VirtualBox : P2V
Classé dans : Virtualisation, Astuces, OS | 1 commentaire | publié le 20 décembre 2013

Un P2V (Physical to Virtual) est une opération qui consiste à transférer le système d'exploitation d'un ordinateur physique vers une machine virtuelle. C'est très pratique lorsque le hardware est défaillant ou sous-dimensionné et que vous souhaitez redonner un peu de patate à un serveur ou un poste de travail. Dans mon cas il s'agit d'un poste sous Windows XP que je souhaite virtualiser afin de l'utiliser sur une autre machine plus récente équipée de Windows 7. Voici la procédure.

Etape 1 : Génération du fichier VHD

Téléchargez l'utilitaire Disk2vhd sur la machine cible et exécutez-le en administrateur. Pensez à stopper l'antivirus et tous les services pouvant ralentir l'opération. Sélectionnez votre disque C:\ puis décochez la case "Use VhdX" (VirtualBox supporte mal) et sélectionnez l'emplacement du fichier cible (qui peut très bien être en local).

Exécutez l'opération, et patientez. Pour information, 40GB de vhd prennent à peu près 1 heure. Lorsque le fichier est complète généré, transferez-le sur votre machine qui va exécuter VirtualBox. Privilégiez un réseau 1000Mbps sinon cela risque d'être long (quasiment 1h20 pour mon fichier vhd de 40GB!).

Etape 2 : Création de la VM

Sur la machine qui exécute VirtualBox cliquez sur le bouton pour créer une nouvelle VM. Donnez-lui un nom, sélectionnez le type d'OS adapté dans la liste, allouez de la RAM (2GB pour XP 32 bits est suffisant) et sélectionnez "Utiliser un fichier de disque dur virtuel existant" et allez chercher votre fichier vhd. Pour finir, cliquez sur "créer".

Etape 3 : Configuration

Pour ma machine virtuelle en Windows XP j'ai du activer IO-APIC et PAE/NX. Pour cela sélectionnez votre VM puis cliquez sur "Configuration". IOi-APIC se situe dans la catégorie "Système" puis onglet "Carte mère". PAE/NX se situe dans l'onglet "Processeur".

Exécuter la VM

Plus qu'à cliquer sur le bouton "Démarrer" ! Attention si votre Windows XP était enregistré sur un domaine, pensez à le renommer pour éviter les conflits sur l'A.D.

ezjail : gérer facilement des jail sur FreeBSD
Classé dans : Serveur, Virtualisation, OS, Planet-Libre | 3 commentaires | publié le 29 avril 2013

Les jails permettent de créer des VPS sur un système FreeBSD. Les processus sont emprisonnés dans un niveau d'exécution et un environnement distinct. L'équivalent sur Linux est OpenVZ / VServer / LXC mais le système de jails sous FreeBSD est intégré au système et plutôt mature.

La documentation de FreeBSD décrit le processus manuel de création de jails. Je recommande la lecture et le suivi de l’exercice proposé afin d'acquérir les bases. Il est aussi mentionné la possibilité d'utiliser un "squelette" commun à toutes les jails, ces dernières n'ayant que les répertoires susceptibles d'être modifié. Cela évite d'avoir 10 fois la même arborescence alors que beaucoup d'éléments sont communs. ezjail est un outil permettant d'automatiser tout ceci, et nous allons voir que c'est plutôt bien foutu.

Installation de FreeBSD

Depuis la version 9, l'installeur a été simplifié au point qu'il n'est plus nécessaire de le détailler. Le choix des sets importe peu sur le résultat final, mais personnellement j'ajoute les sources car j'estime que cela fait partie de l'OS.

La suite de l'installation ne nécessite pas de paramétrage particulier.

Configuration

Vous pouvez commencer par mettre à jour le système :

# freebsd-update fetch

# freebsd-update install

# reboot

Nous allons maintenant installer ezjail. Il y a deux solutions : le compiler à partir des ports, ou le télécharger sous forme binaire avec pkg_add.

Méthode 1 : ports

Commencez par télécharger l'arbre des ports :

# portsnap fetch extract

Puis compilez et installez sysutils/ezjail :

# cd /usr/ports/sysutils/ezjail

# make install clean

Il faut ensuite autoriser ezjail à se lancer :

echo ezjail_enable="YES" >> /etc/rc.conf

Méthode 2 : pkg_add

Utilisez la commande suivante :

# pkg_add -r ezjail

Il faut ensuite autoriser ezjail à se lancer :

echo ezjail_enable="YES" >> /etc/rc.conf

Création de la jail de base

La commande suivante va préparer la jail de base :

# ezjail-admin install
Note : Si vous souhaitez ajouter les sources dans la jail de base, vous devez rajouter le paramètre s. Pour avoir les ports (récupérés à partir de portsnap) dans la jail de base ajoutez le paramètre p. Si vous avez déjà installé la jail de base et souhaitez rajouter les ports ou les sources, réutilisez la commande ezjail-admin install mais spécifiez le paramètre en majuscule, par exemple ezjail-admin install -P

Création d'une jail

Utilisez la commande suivante :

# ezjail-admin create dns 'em0|192.168.0.2'
Note : "dns" est le nom donné à notre jail, adaptez-le si besoin ! em0 est le nom de la carte réseau, adaptez-le en fonction de votre système. L'adresse IP sera automatiquement ajoutée comme alias par ezjail, pas de paramétrage à faire, à part spécifier celle que vous désirez donner à votre jail !

Démarrer une jail

Voici la commande :

# ezjail-admin start dns
Note : Les jails se lancent automatiquement au démarrage de l'hôte grâce au paramètre ezjail_enable ajouté au rc.conf.

Arrêt d'une jail

ezjail-admin stop dns

Mise à jour des jails

La jail de base va être mise à jour, ce qui va répandre les modifications sur toutes les jails.

# ezjail-admin update -u
Note : Le u (minuscule) applique les mises à jour mineures. Le U (majuscule) applique les mises à jour majeures. A vous de décider. L'option P (majuscule) met à jour les ports (en utilisant portsnap).

Suppression d'une jail

La commande est la suivante :

# ezjail-admin delete -wf dns
Note : Le paramètre w spécifie la suppression de l'arborescence de la jail sur le disque. Le paramètre f demande l'arrêt de la jail avant suppression.

Modifier le "modèle" des jail

Cas concret : vous voulez activer SSH sur toutes les jails créées. C'est faisable ! La jail "modèle" est située ici : /usr/jails/newjail. Donc il faut éditer/créer le fichier /usr/jails/newjail/etc/rc.conf :

# echo sshd_enable="YES" >> /usr/jails/newjail/etc/rc.conf

Et voilà !

Documentation

D'autres usages sont possibles, certains seront intéressés par les possibilités offertes avec l'intégration ZFS.

  • Site officiel ezjail : Très pauvre, mais les bases sont là.
  • Utiliser la commande man ezjail-admin directement sur FreeBSD, c'est très complet.
Installer VMware Workstation sous Fedora
Classé dans : Virtualisation, Astuces | aucun commentaire | publié le 19 février 2013

L'installation de VMware Player/Workstation sous Linux est assez simple puisqu'il suffit de lancer le package fourni en root. Or sous Fedora la compilation des modules ne passe pas, il y a quelques manipulations à faire.

Dépendances

# yum install kernel-devel* make gcc

Installation VMware

# ./VMware-Workstation-Full-9.0.1-894247.x86_64.bundle

Compilation des pilotes

Ci dessous un petit fix sinon la compilation échouera :

# cp /usr/src/kernels/`uname -r`/include/generated/uapi/linux/version.h \
/lib/modules/`uname -r`/build/include/linux

Puis on lance la génération des pilotes :

# /usr/bin/vmware-modconfig --icon="vmware-workstation" --appname="VMware"

La compilation des pilotes (fix + modconfig) est à faire à chaque mise à jour du kernel Fedora.

Serveur LXC : #2
Classé dans : Serveur, Virtualisation, Planet-Libre | 1 commentaire | publié le 26 décembre 2012

Voilà maintenant 4 mois que mon serveur tourne sous Ubuntu 12.04 et propulse des VPS sous LXC. J'aime le côté prêt à l'emploi, en quelques lignes on obtient un container fonctionnant aussi bien qu'un serveur physique. A titre de comparaison je me suis cassé les dents avec les jails de FreeBSD, puisque named (daemon DNS) ne semble pas fonctionner (par défaut il essaie de se lancer en chroot, chose visiblement impossible dans une jail).

Par contre cela a aussi des inconvénients, par exemple l'implémentation LXC de ubuntu fournit un réseau avec du NAT par défaut. Ceci est idéal quand on est pressé, mais pas quand on veut paramétrer proprement son réseau avec un parefeu en amont, cela oblige à modifier la configuration.

J'ai testé jusque là 5 systèmes (disponibles en templates ou par bidouillages) :

  • Ubuntu : OK
  • Debian : OK
  • OpenSuse : OK
  • Fedora : ECHEC (yum n'est pas présent donc le template échoue)
  • Archlinux : ECHEC (malgré une procédure identique à opensuse je n'ai pas réussi à le booter)

Je trouve que LXC est une très bonne solution d'appoint pour créer des VPS et fonctionne aussi bien que la virtualisation KVM, à condition de faire tourner des systèmes Linux. J'ai hâte de voir ce que nous réserve l'avenir, et j'attends beaucoup de l'intégration libvirt et openvswitch ;)

$ sudo lxc-list
RUNNING
  dns
  jabber
  mail
  mx
  web

A bientôt !

Windows 8 sur Linux-KVM et Virt-Manager
Classé dans : Virtualisation, Astuces, Planet-Libre | 4 commentaires | publié le 14 octobre 2012

Si vous essayez d'installer Windows 8 dans Linux-KVM vous allez rencontrer le bug suivant :

Your PC needs to restart.
Please hold down the power button
Error Code: 0x0000005D
Parameters:
0x03060203
0x756E6547
0x49656E69
0x6C64746E

Il s'agit d'une réaction au type de CPU affiché par Linux-KVM (Qemu Processur), la solution consiste à copier la configuration du CPU hôte afin que ce dernier s'y retrouve. Pour cela ouvrez les paramètres de votre VM, allez dans "Processor" puis "Configuration" et cliquez sur "Copier la configuration CPU de l'hôte".

Vous pouvez maintenant virtualiser Windows 8 sous Linux sans devoir installer VirtualBox ou VMware !

Merci à Regardt van de Vyver

openSUSE LXC dans Ubuntu possible ?
Classé dans : Serveur, Virtualisation, Astuces, Planet-Libre | aucun commentaire | publié le 17 août 2012

J'ai regardé si il était possible d'installer un container LXC openSUSE sur un hôte Ubuntu. De manière propre et simple, non ce n'est pas faisable. Aucune documentation à ce sujet, et le template fourni ne fonctionne pas car il requiert zypper, non disponible sur ubuntu.

Par contre en bidouillant c'est possible, voici ce que j'ai fait :

  • S'installer un système openSUSE en physique ou en virtuel
  • Installer LXC dessus et faire un container à partir de cette documentation.
  • Archiver ce container (tar -cvf vps.tar /var/lib/lxc/vps) et le transférer sur le serveur ubuntu (en sftp par exemple).
  • Extraction de l'archive dans le bon dossier (tar -xvf vps.tar -C /var/lib/lxc/)
  • Renommage, ajout de la configuration réseau dans le "config" de ce container
  • Démarrage du container, ça fonctionne
  • Pour configurer le réseau à la main : ifconfig eth0 192.168.0.10 netmask 255.255.255.0
  • Pour la passerelle : route add default gw 192.168.0.254 eth0
  • Pour le DNS : echo "nameserver 8.8.8.8" > /etc/resolv.conf
  • Installation de yast2 et vim (zypper install autoyast2-installation vim)

Et voilà, un système openSUSE fonctionnel tournant dans un container LXC et un hôte Ubuntu !

Serveur LXC : #1
Classé dans : Serveur, Virtualisation, Planet-Libre | 1 commentaire | publié le 13 août 2012

Premier retour après bientôt un mois de migration de mon serveur sous LXC.

Cela fonctionne plutôt bien, les ressources consommées sont faibles, les systèmes invités s'administrent comme des machines physiques, et après un redémarrage de l'hôte rien n'est perdu tout repart correctement. Il y a cependant certains cas un peu pointilleux, par exemple un container refusera de démarrer si il ne peut pas trouver de configuration réseau. Après avoir modifié quelques scripts propres à ubuntu qui ajoutaient une couche NAT et un serveur DHCP pour le réseau lxcbr0, je me suis retrouvé dans l'impossibilité de démarrer des containers nouvellement créés. Après une bonne heure de galère, sans aucun retour d'information (pas de log), j'ai fini par comprendre que je devais éditer leur fichier interfaces et placer une configuration IP statique.

Le template opensuse fourni dans ubuntu 12.04 n'est pas exploitable car il requiert le logiciel zypper et celui-ci ne semble pas disponible dans apt. Fedora demande yum mais ce dernier est en revanche fourni. Jusque là je me suis contenté de faire des containers ubuntu et debian sur lesquels je n'ai pas rencontré de souci.

J'ai une interrogation sur les migrations, peut-on transférer des containers LXC vers un autre serveur et les exécuter correctement, surtout si la distribution hôte n'est pas la même ? C'est une chose que je testerai bientôt.

Mon serveur sous LXC
Classé dans : Serveur, Matériel, Virtualisation, Planet-Libre | 14 commentaires | publié le 21 juillet 2012

Je m'auto-héberge pour beaucoup de choses sauf ce blog, et j'ai très souvent changé l'OS ou le matériel au cours de ces dernières années. En 2010 je débutais avec un Alix équipé d'un processeur AMD à 500Mhz. Il fonctionnait sur Debian. Je suis passé un peu plus tard sous NetBSD puis OpenBSD. Par la suite, ayant décidé de changer mon ordinateur personnel, mon ancien (dell inspiron 9400) fut disponible pour faire office de serveur et m'offrit la possibilité de faire de la virtualisation. Après m'être posé la question du choix de l'OS, j'ai finalement retenu CentOS. La machine étant trop "présente" (bruit+chaleur+consommation) je suis rapidement revenu sur l'Alix avec OpenBSD.

Étant actuellement dans l'optique d'installer une infrastructure réseau propre avec une DMZ, j'ai décidé de remanier une nouvelle fois mon serveur. C'est toujours un mini-PC, Intel D945GSEJT mais cette fois équipé d'un processeur Atom avec 1GB de ram ce qui me laisse un peu plus de marge dans le choix des technologies.

J'ai retenu LXC pour gérer la séparation des rôles, car étant intégré au kernel linux et en pleine expansion. J'ai retenu Ubuntu 12.04 server comme système d'exploitation, car je l'ai trouvé meilleur au niveau de la gestion de LXC :

  • Fedora 17 : n'offre pas de template
  • Debian 7 : les templates ont des bugs
  • Ubuntu 12.04 : les templates sont parfaits, le réseau est créé automatiquement (de type "routed")

J'ai actuellement mis en place 4 systèmes-invités à partir du template ubuntu, ce qui donne ceci :

Le serveur ne fait qu'un léger bruit, celui du HDD 2,5", mais il est largement supportable on peut très bien dormir dans la même pièce. Chaque VPS dispose de sa propre adresse IP et fournit les rôles définis : SMTP, XMPP, HTTP, DNS.

Ce qu'il reste à faire

Je n'ai actuellement pas de dispositif de sauvegarde, ce qui peut m'être fatal en cas de panne matérielle. J'ai prévu d'étudier backupninja et bacula, pour voir quelle solution me permet de gérer le plus facilement et efficacement possible les sauvegardes des données sur mes VPS.

Aperçu de oVirt
Classé dans : Serveur, Virtualisation, Planet-Libre | 3 commentaires | publié le 09 juillet 2012

J'ai souvent parlé de Linux-KVM en citant parfois des défauts qui peuvent lui être préjudiciables. Ils ne se trouvent pas dans la technologie elle-même mais plutôt dans les outils d'administration peu fiables (virt-manager) voir inexistants qui demandent alors beaucoup de bidouilles lorsque l'on veut s'en servir sérieusement et durablement.

Red Hat travaille beaucoup sur l'amélioration de l'écosystème KVM et semble avoir compris les problématiques et les enjeux. En effet pour pouvoir lutter contre les solutions VMware qui sont pour beaucoup des références, ils créent des nouveaux outils dans le but de faire de KVM une solution d'entreprise et non de bidouilleur.

Présentation

oVirt est la branche opensource et gratuite de RHEV (RedHat Enterprise Virtualization). Cette solution offre un système de gestion d'un cluster de virtualisation similaire à VMware vCenter. Il utilise des technologies connues : VirtIO, libvirt, kvm, spice. L'interface utilisateur est une application JBoss (accessible en web) utilisant une base de données postgresql.

oVirt est défini en deux parties : engine qui est l'application elle-même, et node qui est en fait un hyperviseur membre du cluster que nous mettons en place. Schématiquement, voici ce que cela donne :

Les instructions d'installation peuvent être trouvées sur cette page et ce PDF. Le plus simple est d'utiliser Fedora 16 sur la machine où nous allons installer oVirt Engine, tout simplement car un dépôt rpm est proposé et facilite grandement les choses. Concernant oVirt Node, il suffit de récupérer une image ISO et de l'installer sur la machine qui servira d'hyperviseur. Voici un aperçu de l'interface oVirt (cliquez pour agrandir) :

Le stockage se fait sur un serveur NFS ou une baie SAN (connexion iScsi). La documentation détaille tout.

Fonctionalités

Cette page liste les fonctionnalités proposées à l'heure actuelle. Je passe sur les détails techniques comme le nombre de vcpu pour parler plutôt des services fournis.

Datacenter

  • Administrer un cluster d'hyperviseurs
  • Proposer une interface graphique complète
  • Faciliter la mise en place des machines virtuelles et leur migration à chaud
  • Assurer si besoin une haute disponibilité
  • Faciliter la centralisation du stockage des supports
  • Faciliter le p2v

Utilisateur

  • Proposer un portail utilisateur pour se connecter à son bureau (plugin SPICE mozilla)
  • Virtualisation desktop pour clients légers grâce au protocole SPICE (support USB)
  • Technologies d'optimisation du réseau pour limiter les latences dans l'affichage

Ma conclusion

oVirt est clairement de la catégorie artillerie lourde puisqu'il faut pas moins de 3 serveurs physiques au minimum pour mettre en place l'infrastructure. De plus, l'engine (qui propose l'interface web) est très gourmand en mémoire, les spécifications recommandent 4GB. Celui qui a besoin d'un unique hyperviseur se tournera donc vers des solutions plus légères et mieux adaptées comme Proxmox.

Néanmoins, pour une entreprise qui veut virtualiser une dizaine (ou plus) de serveurs, oVirt semble une excellente solution. Il est possible de se tourner vers RHEV pour obtenir la version commerciale avec du support pour plus de pérennité.

J'espère grandement avoir un jour l'occasion de travailler avec oVirt/RHEV en situation réelle.

OpenBSD : p2v
Classé dans : Serveur, Virtualisation, Astuces, OS, Planet-Libre | 3 commentaires | publié le 19 juin 2012

Voici une petite bidouille pour transférer un serveur OpenBSD physique vers une machine virtuelle (VMware dans mon cas, mais cela devrait fonctionner avec tous).

A moins de faire une mauvaise commande, il n'y a aucun risque pour le serveur car on ne modifie rien dessus.

Etape 1 : installation de la VM

Ici, rien de particulier. Récupérez une ISO d'OpenBSD et effectuez l'installation dans une machine virtuelle. Configurez le réseau afin d'avoir un accès SSH.

Etape 2 : lister l'essentiel sur le serveur physique

Si je liste ce que contient mon serveur, voilà ce que j'obtiens :

$ ls /
altroot boot    bsd.mp  dev     home    obsd    sbin    sys     usr
bin     bsd     bsd.rd  etc     mnt     root    stand   tmp     var

Mon serveur fait tourner OpenSMTPD dont la config se trouve dans /etc et les messages dans /home. Vient ensuite dovecot installé à partir des ports, ses fichiers se situent dans /usr (et la config dans /etc). Et pour finir, prosody qui vient lui aussi des ports et exploite une base de données située dans /var. La liste des répertoires à transférer est donc :

  • /etc
  • /home
  • /usr
  • /var

Etape 3 : sauvegarde des répertoires

On utilise un bon vieux tar (vous pouvez utiliser la compression en rajoutant l'argument z) :

# tar -pcvf etc.tar /etc/
# tar -pcvf home.tar /home/
# tar -pcvf usr.tar /usr/
# tar -pcvf var.tar /var/

Attention à ne pas travailler dans le répertoire /home lorsque vous faites la deuxième commande ! Sinon cela ne terminera jamais (il va archiver le fichier d'archive nouvellement créé, etc).

Etape 4 : transfert des archives sur la VM

Le plus simple est d'utiliser le protocole sftp (actif du moment que sshd est actif sur vos systèmes). Cela peut-être fait depuis Filezilla sur une tierce machine (avec les comptes root).

Etape 5 : Rétablissement des utilisateurs

Pour des raisons de sécurité, le fichier contenant les utilisateurs du système et leurs mots de passe est en lecture seule, même pour root (voir cette page). Vous devez utiliser l'outil vipw pour les importer.

Ouvrez vipw sur l'ordinateur hôte, copiez toutes les lignes situées après la ligne "nobody", et collez-là à la suite dans le vipw de la VM (vous pouvez faire cette opération depuis un ordinateur tiers et des connexions SSH).

Etape 6 : installation sur la VM

La procédure est classique, sauf qu'il faut penser à sauvegarder le fichier fstab car le partitionnement peut différer :

# tar -pxvf var.tar -C /
# tar -pxvf usr.tar -C /
# tar -pxvf home.tar -C /
# cp /etc/fstab /root/
# tar -pxvf etc.tar -C /
# cp /root/fstab /etc/
# reboot

Pensez à revoir la configuration du rc.conf, notamment le nom d'hôte et le réseau qui peuvent différer.

Le réseau "bridged" facilement sur KVM depuis Fedora 17
Classé dans : Virtualisation, Planet-Libre | 2 commentaires | publié le 28 mai 2012

Si il y a une chose qui a toujours été compliquée sur la virtualisation KVM, c'est de faire un pont-réseau (Bridge) c'est à dire faire comme si votre machine virtuelle était branchée physiquement au réseau (on peut ainsi mettre une IP sur le même réseau que les autres et se passer de NAT ou routage). Il fallait faire des manipulations sur l'hôte pour mettre en place le pont, cela changeait selon les OS, bref c'était un peu fastidieux.

Depuis Fedora 17, une nouvelle fonctionnalité, "macvtap" qui permet d'automatiser toute cette opération un peu comme sur VirtualBox. Il suffit de sélectionner, en périphérique source, Périphérique hôte p4p1 : macvtap en remplaçant p4p1 par le nom de votre carte réseau.

Une excellente chose qui va faciliter la vie de beaucoup de gens !

Pour la virtualisation, ce sera CentOS
Classé dans : Serveur, Virtualisation | 2 commentaires | publié le 10 avril 2012

Suite à mon article précédent, j'étais parti sur une solution Proxmox pour mon hyperviseur. Cependant je me suis rapidement énervé sur l'applet VNC en Java qui permet d'avoir l'affichage des machines virtuelles. Il est lent (impossible d'attraper le grub d'une VM), rigide, et fait régulièrement planter Firefox. Ragequit.

C'est donc CentOS 6.2 x86_64 qui est venu remplacer Proxmox sur l'ordinateur. La console distante virt-manager est sur mon notebook en archlinux. Les deux semblent plutôt bien se marier puisque je n'ai eu que 3 crashs en un weekend (ce qui est un miracle pour virt-manager).

J'ai actuellement deux VM (je vous laisse deviner d'où viennent les noms) :

  • Shadowbroker : serveur mail (Postfix + dovecot) sur CentOS 6
  • Harbinger : serveur jabber (prosody) sur Debian Squeeze

La mise en place du serveur mail sous CentOS est intéressante à faire, notamment à cause de SELinux que j'ai choisi de ne pas désactiver cette fois. Cela fera l'objet d'un article très prochainement.

Quelle solution KVM choisir ?
Classé dans : Serveur, Virtualisation | 7 commentaires | publié le 04 avril 2012

Mon ancien ordinateur portable Dell Inspiron 9400 va être recyclé en serveur de virtualisation, et j'ai bien entendu choisi une solution Linux-KVM. En effet bien que je ne sois pas contre VMware ESXi, que je considère comme le meilleur produit existant actuellement, je préfère explorer quelque chose de moins connu qui sera donc plus instructif.

Ma problématique est de choisir l'OS qui sera utilisé pour faire fonctionner l'hyperviseur. J'en ai retenu deux :

  • CentOS
  • Proxmox

CentOS s'installe en mode texte avec l'hyperviseur et le daemon libvirt. On peut ensuite y connecter une console Virt-Manager depuis un autre poste. L'inconvénient est que Virt-manager est tout sauf fiable : c'est rigide, bugué, grandement variable selon les versions, et pas disponible sur Windows. L'avantage est qu'en partant d'une solution comme CentOS on a une certaine liberté sur le choix des composants. On sait aussi que les mises à jour offrent des améliorations dans la virtualisation du fait du travail de Red Hat.

Proxmox offre une console en web donc indépendante de l'OS, et en pratique bien plus fiable et complète que Virt-manager. L'inconvénient est qu'une solution tout-en-un offre moins de souplesse dans le choix des composants ou leur modification. On ne sait pas également comment évolue le produit, si les mises à jour se contentent de corriger les bugs, ou si elles apportent des améliorations de performances et l'introduction de nouveautés comme sur CentOS / RedHat.

Je pense retenir Proxmox, les OS invités seront sûrement des debian ce qui permettra d'utiliser les containers OpenVZ et économiser des ressources par rapport à KVM.