Virtualisation serveur avec KVM (sur Ubuntu 16.04)

Publié le mar. 27 septembre 2016 dans Informatique

Dans le cadre de mes activités professionnelles, je gère un serveur informatique sur lequel sont hébergées de nombreuses choses, mais je suis amené à mettre en place une machine virtuelle. Pour cela, j'utilise KVM...

De base, ce site héberge mon site web personnel, mon site web personnel, ma solution de supervision avec laquelle je surveille les serveurs de mes clients, le site web de ma boutique Domotego... de nombreuses choses que j'ai choisi d'héberger sur un seul système, permettant de me simplifier la vie : je n'ai à assurer la sécurité que d'une machine, je n'ai pas de réseau à gérer, pas de flux particulier, etc.

Cependant, j'ai un besoin qui risque d'entrer en conflit avec cette approche : je souhaite reprendre la main sur mes e-mails et installer mon propre serveurs de messagerie électronique. Après avoir étudié différentes solutions (dont iRedMail, OpenXchange et Zimbra), j'ai choisi de partir sur Zimbra. Seul inconvénient : il installe de nombreuses choses qui peuvent entrer en conflit avec d'autres outils que j'ai déjà installés sur ma machine. J'ai tenté de limiter ces conflits et de laisser Zimbra "dans son coin", mais la configuration devient très spécifique et je sens que ça risque de casser à la moindre mise à jour.

J'ai donc décidé de mettre en place une virtualisation serveur afin d'isoler Zimbra dans sa propre machine. Pour cela, j'ai choisi KVM.

Parenthèse : les solutions de messagerie

Je viens de Google Mail. Par là, je sous-entends que je veux une interface facile à utiliser, qui intègre les outils collaboratifs classiques (agenda et carnet d'adresses), que l'on peut synchroniser avec un smartphone sous Android... Des besoins classiques pour aujourd'hui, mais loin de la "simple" messagerie. Plusieurs approches s'offraient à moi, en voici un rapide aperçu...

Option 1 : installer moi-même les différents éléments, Postfix, Dovecot, SpamPD, etc... Cela aurait été mon approche préférée mais la messagerie est un métier très spécifique, la sécurité des e-mails est très complexe, la lutte contre les spam et les virus demande la mise en place d'outils pas faciles à aborder. J'aurais pu le faire, j'en ai les compétences, mais cela aurait été trop chronophage : j'ai autre chose à faire de mes journées que d'administrer un serveur mail sur lequel je suis le seul utilisateur. De plus, il faut assembler plusieurs logiciels différents pour avoir les fonctionnalités demandées... encore plus de complexité !

Option 2 : OpenXchange est une interface web à mettre en place par-dessus une installation telle que celle décrite ci-dessus. Si ça enlève la complexité liée à l'interface utilisateur, toute la partie technique "bas niveau" reste compliquée à gérer et surtout chronophage.

Option 3 : iRedMail est une solution qui automatise l'installation de différents outils, permettant alors d'offrir les fonctionnalités demandées tout en restant maître de l'infrastructure. C'est très attrayant, j'ai failli opter pour cette solution... Mais malheureusement elle ne permet ni d'avoir plusieurs comptes (plusieurs adresses e-mail) ouverts en même temps, ni de fusionner plusieurs adresses e-mail de domaines différents sur un seul compte.

Option 4 : Zimbra est une solution "tout en un", une espèce de boîte noire (mais basée sur des logiciels libres, donc on peut regarder dedans comment ça fonctionne sans aucun problème) que l'on installe d'un bloc et qui répond aux fonctionnalités demandées. J'aurais préféré ne pas de voir l'utiliser, mais c'est la seule solution qui ne soit pas extrêmement chronophage et qui me permet de consulter mes e-mails de plusieurs adresses et plusieurs domaines en même temps.

Parenthèse : les solutions de virtualisation

Pour la virtualisation, plusieurs solutions auraient pu être utilisées. Voici un rapide aperçu.

QEmu et VirtualBox sont plutôt des solutions pour la virtualisation de bureau, pas pour du serveur "allumé en continu". Bien sûr c'est possible, j'ai d'ailleurs écrit un article à ce propos dans Linux Pratique Hors Série n°20 en 2010. Mais je préfère m'orienter vers des solutions "faites pour ça".

Il y a bien sûr VMware ESX, une solution très connue dans le monde professionel. Mais c'est un logiciel privateur, qui n'offre aucune fonctionnalité particulière qui pourrait me faire basculer.

En dehors de VMware, j'ai commencé la virtualisation serveur il y a de nombreuses années avec Xen. C'est d'ailleurs cette solution qui est utilisée par Amazon pour son offre AWS EC2. L'inconvénient de Xen, dans mon cas, est que c'est une solution d'hypervision, où rien ne tourne sur l'hôte, tout est dans des machines virtuelles. Ce n'est pas ce que je veux.

Enfin, la solution qui tend à s'imposer sous Linux, c'est KVM (Kernel-based Virtual Machine), incluse par défaut dans le noyau.

Installer et utiliser KVM sur un serveur déjà en production

En cherchant sur Internet, je me suis rendu compte qu'il n'y a pas de guide complet expliquant comment utiliser KVM pour faire de la virtualisation serveur sans interface graphique. J'ai pour ma part mis cela en place sur un serveur fonctionnant sous Ubuntu 16.04 LTS, sans écran (serveur dédié Dedibox).

Mon objectif est donc de mettre en place de la virtualisation à côté du système actuel, qui fonctionne parfaitement bien. Cela me permettra de virtualiser une machine indépendante, dans laquelle je vais faire fonctionner Zimbra.

Préparation

Avant de commencer, il faut vérifier si la machine supporte la virtualisation matérielle. Pour cela, on exécute la commande suivante :

egrep -c '(vmx|svm)' /proc/cpuinfo

Si cette commande retourne 0, alors la virtualisation ne sera pas possible. Tout nombre positif (qui devrait correspondre au nombre de cœurs de processeur disponibles sur la machine) indique que la virtualisation matérielle est possible avec ce(s) processeur(s).

On installe alors les outils qui permettront de gérer la virtualisation, QEMU pour la gestion "bas niveau" des machines virtuelles et libvirt pour se faciliter la vie (ce dernier est d'ailleurs capable de gérer de nombreux systèmes de supervision, se substituant à leurs outils spécifiques) :

apt-get --no-install-recommends install qemu-kvm libvirt-bin virtinst

L'option --no-install-recommends permet de ne pas installer l'interface graphique virtviewer, qui est un paquet recommandé par virtinst (mais inutile sur un serveur sans écran).

On a également besoin de bridge-utils pour pouvoir dialoguer par le réseau avec la machine virtuelle, mais ce paquet est normalement déjà présent sur la machine.

On pourrait très bien se passer de libvirt et utiliser directement la commande kvm, mais mon objectif ici est d'utiliser les outils les plus génériques possibles, facilitant la vie de l'administrateur système : moi.

Réseau par défaut

Parmi les choses qui sont facilitées par libvirt, on retrouve un réseau, que l'on peut gérer (comme n'importe quel aspect de la virtualisation) avec la commande virsh. L'hôte est automatiquement connecté à ce réseau, par le biais de l'interface réseau virtuelle virbr0 ; ce réseau héberge par ailleurs automatiquement un serveur DHCP, qui permettra aux machines virtuelles d'obtenir des adresses IP dynamiques.

De plus, des règles de pare-feu sont automatiquement mises en place pour permettre aux machines virtuelles d'accéder à Internet...

Pour ma part, j'ai cependant besoin de pouvoir allouer des adresses IP fixes, c'est pourquoi je modifie la configuration de ce réseau. Pour cela, j'exécute la commande virsh avec les arguments suivants :

virsh net-edit default

Un éditeur de texte s'ouvre alors, permettant de modifier la configuration du réseau sous forme de fichier XML.

Dans celui-ci se trouve une balise range, que je modifie comme suit :

::
<range start='192.168.122.10' end='192.168.122.99'/>

Je peux alors utiliser toutes les adresses à partir de 192.168.122.100 pour de l'adressage statique.

Création d'une VM

Une fois ces outils installés, on peut créer une première machine virtuelle avec la commande virt-install. Celle-ci prend différents arguments décrivant la machine virtuelle à mettre en place.

On va donc commencer par se poser des questions sur la machine. Je donne dès maintenant mes réponses, qui permettront de construire la ligne de commande ci-après :

  • comment va-t-elle s'appeler ? Zimbra
  • combien de mémoire aura-t-elle ? 4 Gio
  • où stocker le disque virtuel, quelle taille ? /dev/mapper/system-zimbradisk, 20 Go
  • à partir d'où l'installer ? http://us.archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/
  • comment configurer son réseau ? connexion au réseau "default"
  • comment accéder à son écran/clavier ? serveur VNC

Pour constituer cette liste, j'ai parcouru la page de manuel de virt-install, n'hésitez pas à la consulter ! Les paramètres un peu particuliers que j'utilise sont :

  • l'emplacement du disque, car habituellement on précise simplement une taille sans spécifier d'endroit où stocker le disque, c'est l'outil qui s'occupe alors de créer un disque virtuel dans un fichier - pour ma part, j'ai choisi d'utiliser un volume logique LVM, dans l'espoir de pouvoir le redimensionner par la suite ;
  • la source pour l'installation, une source en ligne permettant de ne pas utiliser de support d'installation particulier (image CD ou autre).

Je vais donc d'abord créer mon volume logique LVM puis installer la machine :

lvcreate -L20G -n zimbradisk /dev/system
virt-install \
    --name Zimbra \
    --memory 4096 \
    --disk /dev/mapper/system-zimbradisk \
    --network default \
    --graphics vnc,password=toto \
    --location http://us.archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/

L'installation de la machine virtuelle se lance alors. On peut alors se connecter en VNC à la machine, notamment au travers d'un tunnel VNC (car le serveur VNC de KVM n'écoute qu'en local) :

ssh serveur_hote -L 5900:localhost:5900

À partir de là, on peut se connecter en VNC à localhost, on voit alors l'interface de la machine virtuelle, où se déroule une installation classique d'Ubuntu.

Notons que j'aime tout installer à la main, du coup lors du choix des logiciels à installer, je ne coche que le serveur SSH...

Une fois l'installation terminée, la connexion VNC s'arrête et la commande virt-install rend la main.

Parenthèse : suppression d'une VM

Lorsque l'on veut supprimer une machine virtuelle, on peut le faire avec les commandes suivantes :

virsh destroy <nom_de_la_machine>
virsh undefine <nom_de_la_machine>
virsh vol-delete <chemin_du_disque_virtuel>

La première commande arrête la machine virtuelle, la seconde supprime sa configuration et la troisième supprime son disque virtuel. Dans le cas d'un stockage sur un volume que l'on a créé soi-même (dans mon cas, un volume logique LVM), on peut se passer de la troisième commande et supprimer soi-même le volume.

Premier accès SSH

Une fois installée, la machine est accessible via SSH. Pour connaître son adresse IP, on peut par exemple demander quelle adresse IP elle a obtenu par DHCP, avec la commande suivante :

virsh net-dhcp-leases default

Dans mon cas, la réponse a été la suivante :

Expiry Time          MAC address        Protocol  IP address                Hostname
------------------------------------------------------------------------------------
2016-09-27 17:26:14  52:54:00:52:a0:60  ipv4      192.168.122.28/24         mail

Je peux alors me connecter en SSH à partir de l'hôte...

ssh sebastien@192.168.122.28

Configuration réseau de la VM

Grâce au réseau "default", la machine virtuelle a déjà une adresse IP, assignée automatiquement. Cependant, je veux lui assigner une adresse IP fixe. Il suffit pour cela d'éditer le fichier /etc/network/interfaces, comme pour n'importe quelle configuration réseau sous Ubuntu ou Debian :

auto ens3
iface ens3 inet static
    address 192.168.122.100
    netmask 255.255.255.0
    gateway 192.168.122.1
    dns-nameservers 8.8.8.8

Afin de valider que cela fonctionne bien avant de faire quoi que ce soit d'autre, un redémarrage est alors une bonne idée ; après ce redémarrage, on peut se connecter à l'adresse 192.168.122.100.

Accès SSH direct

Devoir se connecter en SSH sur l'hôte pour pouvoir accéder à la machine virtuelle, ça va rapidement devenir pénible. C'est pour cela que l'on va faire une connexion SSH par rebond, pour cela on ajoute les lignes suivantes dans le fichier ~/.ssh/config :

Host zimbra
    User sebastien
    ProxyCommand ssh -W 192.168.122.100:22 <nom_de_lhote_kvm>

Pour m'y connecter à partir de mon PC, je n'ai alors plus qu'à exécuter :

ssh zimbra

Services sur Internet

Une fois tout cela en place, la machine virtuelle peut être simplement vue comme une machine dans un réseau privé, derrière un pare-feu sous Ubuntu (ou sous Debian). On peut alors gérer les redirections de port ou les proxies comme on préfère.

Pour ma part, j'affectionne notamment NginX dans le rôle de reverse proxy pour les services web, ainsi que la simple redirection de port (DNAT) pour les services qui sont suffisamment sécurisés sur la machine elle-même ; en l'occurrence, le serveur de messagerie Zimbra lui-même est suffisamment sécurisé, si on ne laisse pas passer des flux sur n'importe quel port et que l'on se limite aux services réellement utilisés...

Commentaires
Il n'y a aucun commentaire sur cet article.

Écrire un commentaire