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.

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.

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 !

Si votre entreprise a besoin d'un outil de discussion par messagerie instantanée, ne cherchez plus. Openfire est un serveur Jabber facile à administrer (en web) permettant d'utiliser des comptes Active Directory, le tout en quelques clics.

Il est facile à mettre en place et à administrer grâce à son interface web complète et intuitive. Les avantages d'une messagerie Jabber sont multiples : les salons, la multitude de clients, le serveur en interne de l'entreprise, etc.

Présentation

Openfire fonctionne en Java, de quoi grimacer à première vue, mais il fonctionne bien et son exploitation est aisée, on peut donc lui pardonner. Pour un serveur sans interface graphique, il faut disposer d'une version de java headless. C'est le cas sur Debian et Ubuntu, mais pas sur CentOS. Heureusement pour nous, l'équipe de Openfire met à disposition un rpm contenant cette version :)

Dans le tutoriel suivant c'est CentOS 6.2 x86_64 qui sera utilisé, mais seule l'étape d'installation change, la configuration et le couplage avec A.D est identique.

Active Directory

Dans l'exemple j'utilise un serveur Windows2008R2 pour l'Active Directory. J'ai créé une OU avec des comptes bidons :

Installation

Nous partons donc d'un système CentOS fraîchement installé et relié au réseau. Commencez par récupérer, sur le site officiel, la version RPM de Openfire. Vous pouvez la transférer sur le serveur en sftp (en utilisant le login root), ou alors la récupérer directement sur internet avec wget :

# yum install -y wget
# wget http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire-3.7.1-1.i386.rpm

Note : pensez bien à remplacer le lien dans cet article par celui pointant vers la toute dernière version distribuée sur le site.

# yum localinstall openfire-3.7.1-1.i386.rpm

Note : vous remarquerez que nous tournons sur CentOS 64 bits, mais que ce package Openfire est 32 bits. Il faut donc installer le paquet glibc 32 bits :

# yum install glibc.i686

Configuration

Attention, par défaut CentOS dispose du parefeu activé, il va falloir ouvrir les différents ports permettant non seulement à Jabber de fonctionner, mais aussi aux administrateurs de se connecter à la console web.

Pour faire la configuration du parefeu on peut utiliser system-config-firewall-tui, la procédure d'installation est décrite ici.

# system-config-firewall-tui

Il faut ouvrir les ports :

• 5222 : Jabber Serveur / Client
• 5269 : Jabber Serveur / Serveur
• 9090 : Port de la console web Openfire

Ensuite prenez garde à bien utiliser le DNS de votre organisation... qui est souvent l'Active Directory lui-même. Ajoutez son IP dans /etc/resolv.conf si ce n'est pas déjà bon.

Pour finir, lancez Openfire :

# /etc/init.d/openfire start

Mise en place

Ouvrez votre navigateur web favori et entrez l'adresse IP de votre serveur Openfire suivi de 9090. Par exemple : http://10.49.1.76:9090.

Language Selection

Langue de l'interface.

Paramètres du Serveur

Laisser par défaut.

Paramètres de base de données

A vous de voir si vous voulez utiliser une base externe ou non. En cas de doutes choisissez la "Base de Données Embarquée".

Paramètres de Profil

Etape 1

Il faut sélectionner "Serveur LDAP" pour pouvoir nous connecter à notre Active Directory.

Type : Active Directory
Hôte : IP de l'Active Directory
Port : 389
Base DN : OU=_XMPP,DC=freeman,DC=lan
DN Administrateur : freeman\administrateur

En bas, le bouton "Tester les paramètres" va vous permettre de savoir si tout est bon.

Etape 2

Tout laisser par défaut. Utilisez une fois de plus le bouton de test en bas, il va charger un utilisateur dans l'A.D et l'afficher.

Etape 3

A voir si vous voulez utiliser les groupes.

Compte Administrateur

Vous allez devoir sélectionner un utilisateur dans l'A.D qui sera administrateur... par exemple j'ai sélectionné adminfreeman.

Terminé !

Console Openfire

Allez dans l'onglet Utilisateurs/Groupes pour visualiser vos utilisateurs importés de l'A.D...

Note sur l'ajout d'utilisateurs : Lorsque vous ajoutez un utilisateur dans l'A.D (dans la bonne OU bien entendu) celui-ci apparait dans la liste des utilisateurs sur Openfire.

Connexion avec un client

Dans l'exemple j'utilise Pidgin. Voici les paramètres à utiliser :

Et voilà !

Hier j'ai installé Movim sur mon serveur mais l'application n'arrivait pas à résoudre le nom de domaine nécessaire pour se connecter au serveur Jabber. Pourtant côté serveur tout était bon, le nom était bien résolu, je n'arrivais pas à comprendre d'où venait l'erreur. Les logs PHP donnaient :

(php_network_getaddresses: getaddrinfo failed: non-recoverable failure in name resolution)

Puis j'ai vu la lumière, le serveur web de OpenBSD, nginx, est chrooté (ainsi que php-fpm probablement). Par conséquent il n'accède pas au /etc/resolv.conf, il faut le copier dans /var/www/etc/resolv.conf.

# mkdir /var/www/etc
# cp /etc/resolv.conf /var/www/etc/

Et voilà !