Proxmox VE - Tuto

TUTORIEL PROXMOX 5.4 - Gestion des VM et des CT

Proxmox est un hyperviseur. Il permet de faire tourner plusieurs machines virtuelles sur un ou plusieurs serveurs physiques montés en cluster. C’est le pendant open source de VmWare. Proxmox gère 2 types de machines ; les Machines Virtuelles (VM) et les ConTainers (CT). Les VM sont des machines virtuelles à part entière avec leur propre OS alors que les containers partagent en partie le même noyau que l'hyperviseur.

Ce tutoriel décrit les principales opérations pouvant être effectuées sur un Serveur Proxmox indépendant. Une description plus technique (installation, paramètrage, cluster, ...) est disponible sur le lien suivant : Installation PROXMOX 6.1-2.

 

SOMMAIRE

Section 1 - L'interface Proxmox
  Description

Section II - Les machines virtuelles (KVM)
  Téléchargement et transfert des fichiers ISO
  Création d'une VM
  Démarrage/Arrêt d'une VM
  Installation d'un systeme d'exploitation sur la VM
  Création d'un Template
  Création d'un clone à base de Template
  Création d'un Snapshot
  Modification du nom d'une VM
  Modification de l'ID d'une VM
  Suppression d'une VM
  Démarrage automatique d'une VM
  Sauvegarde automatisée des VM
  Gestion des VM en ligne de commande
  Sécurité

Section III - Les containers (LXC)
  Mise en place d'un Container
  Activation d'un Template
  Installation d'un container
  Démarrage d'un container
  Gestion des Snapshots
  Gestion des appliances.

Section IV - VM ou CT
  Comment choisir ?

Section V - Gestion des utilisateurs
Création d'un utilisateur proxmox

 

Section I - L'INTERFACE PROXMOX

L'interface PROXMOX est découpée en plusieurs parties.

Le menu horizontal en haut de la fenêtre dispose de plusieurs boutons permettant de créer des VM ou des CT ou encore d'accéder à l'aide en ligne. Si c'est la machine physique qui est sélectionnée, un deuxième menu horizontal apparait en dessous permettant de relancer le serveur physique, de l'arrêter, d'accéder à son shell, d'exécuter des actions groupées ou de se déloguer proprement de la console d'administration.

La vue serveur dans la fenêtre de gauche affiche le datacenter, le ou les serveurs physiques, les containers suivis des machines virtuelles, les espaces de stockage (local, local-lvm, nfs-pve, ...).

En fonction de l'objet sélectionné dans la vue serveur, on voit apparaître une région qui comporte 2 parties, un menu vertical pour gérer l'objet et un espace qui affiche les différentes caractéristiques de l'objet en fonction du menu de gestion sélectionné.

La vue tâches recense toutes les opérations effectuées sur la machine sélectionnée dans la vue serveur avec le status afférent au résultat de l'opération.

 

Section II – LES MACHINES VIRTUELLES (KVM)

a) Téléchargement et transfert des fichiers ISO

Le plus simple au départ, c'est de créer des machines virtuelles. Pour cela, il faut télécharger sur un PC les fichiers ISO dont on aura besoin. Pour ce tutoriel, je choisi d’installer mes VM en Centos version 7. CentOS est une distribution Linux dérivée de RedHat. A noter qu’il est possible de prendre n’importe quelle distribution Linux, voire même un système Windows ou FreeBSD.

An niveau du Datacenter, en cliquant sur local (pve) du serveur physique, il faut sélectionner ‘Content’ dans le menu de gestion (menu vertical), puis en cliquant sur le bouton ‘Upload’, une fenêtre de transfert s’affiche. Dans cette fenêtre, en cliquant sur ‘Select File...’, on va pouvoir sélectionner le fichier ISO téléchargé sur le PC. Pour le transférer sur PROXMOX. Il suffit pour cela de cliquer sur le bouton ‘Upload’.

Une fois le fichier ISO téléchargé sur PROXMOX, il sera possible de le sélectionner pour installer le système d’exploitation de la VM, ici CentOS-7.

b) Création d’une VM

On va créer une VM qui disposera de 15 Go de DD, 4 Go de RAM et de 4 unités de traitement (cores). Ces paramètres sont choisis pour accélérer l’installation de l’OS sur la VM. Ils pourront être réadaptés à des valeurs plus faibles par la suite. On précisera un n° d’ID=200 afin que la VM s’affiche dans le bas de la liste des VM. L’ID est un numéro unique qui permet de référencer la VM. La numérotation des ID commence à partir de 100 jusqu’à 9999.

Pour créer une VM, il suffit de cliquer sur le bouton ‘Create VM’ sur le menu horizontal à droite en haut de l’écran. Le processus de création comprend un paramétrage en 6 vues : General, OS, Hard Disk, CPU, Memory et Network. Chaque vue représente un onglet dans la fenêtre de création de la VM.

On sélectionnera la case à cocher ‘Advanced’ en bas à droite de la fenêtre de création de la VM pour afficher le maximum de paramètres.

 

Vue ‘General’

Dans la vue ‘General’, Node correspond au nom donné à la machine physique.

VM ID sera porté à 200 pour s’afficher en fin de liste des VM.

Name représente le nom de la nouvelle VM, ici T-centos

Start at boot permet de démarrer automatiquement la VM lorsque le serveur physique sera relancé.

 

Vue ‘OS’

Dans la vue ‘OS’, c’est ici que nous allons pouvoir utiliser le fichier ISO téléchargé précédemment. Pour cela, il faut cliquer sur la petite flèche à droite du champ ‘ISO image’ pour afficher la liste déroulante des fichiers ISO disponibles et sélectionner le fichier désiré.

 

Vue ‘System’

Dans la vue 'System', on laissera les paramètres par défaut.

 

Vue ‘Hard Disk’

Dans cette vue, on modifiera le Bus et surtout le n° de Device de façon à ce que toutes les VM ne soient pas toutes sur le même Device. J’ai constaté des dysfonctionnements lorsque le même numéro de Device est trop souvent utilisé. On précisera la taille du disque en GiB, ici 15 GiB, sachant que cette taille peut être modifiée ultérieurement au prix néanmoins d’une certaine complexité.

 

Vue ‘CPU’

Dans la vue ‘CPU’, on dotera notre VM de 2 Sockets et 2 cores, soit 4 unités de traitement. Pour une installation, c’est un minimum, sachant que la valeur de ces deux paramètres peut être réduite ou augmentée facilement par la suite.

 

Vue ‘Memory’

Dans cette vue on fixera la taille de la mémoire allouée à la VM à un maxi à 4Go et un minimum de 1,2 Go pour éviter de trop surcharger le ‘swap’. A l’installation, la taille de la partition swap est fixée à un maximum de 8 Go pour l'ensemble des VM et des CT. Au niveau de l’interface graphique, il est possible de voir le niveau d’occupation du swap.

 

Vue 'Network'

Dans cette vue on laissera les paramètres par défaut si la VM doit communiquer avec d’autres sur le réseau. A l’installation, la VM sera dotée d’une seule interface réseau. Si elle doit être dotée de plusieurs interfaces réseaux, il est fortement conseillé d’ajouter les interfaces supplémentaires avant l’installation du système d’exploitation.

 

Vue ‘Confirm’

La vue ‘confirm’ est la dernière étape avant la création de la VM. Elle récapitule les paramétres de la VM qui seront appliqués en cliquant sur le bouton 'Finish'.

Lorsque la VM est créée, elle apparaît au niveau du datacenter, sous la machine physique (pve0) avec un ID et un nom associé.

On peut retrouver le détail de la configuration en sélectionnant la VM et en cliquant sur ‘Hardware’ dans le menu de gestion (menu vertical). C’est à ce niveau qu’il sera possible de réadapter la configuration par exemple en réduisant la taille de la RAM ou le nombre de coeurs. Pour cela, il faudra simplement double-cliquer sur le champ à modifier pour changer la valeur du paramétre.

c) Démarrage/Arrêt d’une VM

Pour démarrer une VM, il suffit de la sélectionner, puis de faire un clic droit sur son nom et choisir l’action ‘start’. Un petit indicateur vert s’affiche alors sur la VM pour indiquer qu’elle est bien démarrée.

Pour arrêter une VM, il suffit de la sélectionner, puis de faire un clic droit sur son nom et choisir l’action ‘shutdown’ ou ‘stop’. 'Shutdown' permet d’arrêter proprement la VM. Cette action est préférable à 'Stop' qui arrête brutalement tous les processus (kill).

A noter que si la console est active au moment de l’arrêt, un message d’erreur apparaît dans l’historique des actions de la VM. Ce message est normal. Il indique simplement que la console était encore active à l'arrêt de la VM. Pour éviter ce message, il faut quitter la console avant d'arrêter la VM.

d) Installation de l’OS

Pour installer l’OS, il faut sélectionner une VM démarrée et dans le menu de gestion cliquer sur ‘Console’. On accède ainsi à l’écran d’affichage de la VM. C’est à partir de cet écran que nous allons procéder à l’installation de CentOS-7 en mode commande, c’est à dire sans interface graphique.

L’installation de CentOS est sensiblement identique à l’installation de Red-Hat à l’exception de la couleur dominante (rouge pour RedHat) et Bleu pour CentOS.

1 - Mise à jour de CentOS

Une fois installée, il conviendra de s’assurer que la version installée est bien à jour des derniers patchs. Pour cela, on utilisera la commande :

yum update -y

2 - Installation des principaux utilitaires

On installera le dépôt epel-release pour disposer des packages un peu plus récents, l’outil wget pour télécharger des fichiers, l’outil yum-utils pour supprimer les anciens noyaux Linux après mise à jour, nano si on le préfère à vi.

yum install epel-release wget yum-utils nano -y

Pour changer le mot de passe du compte courant (root en l’occurrence), c'est la commande

passwd <nouveau mot de passe>

A ce stade, nous disposons d’une VM opérationnelle. Et comme PROXMOX permet de gérer plusieurs VM, l’étape suivante consistera à créer un template à partir de cette première VM pour automatiser et simplifier la création des autres VM.

 

e) Création d’un Template

Le template, c'est la première expression de la puissance de Proxmox. Il nous a fallu pratiquement 1 heure pour mettre en place la première VM. En utilisant le template, les VM suivantes prendront au plus 5 minutes.

Avec le template, on va figer la première VM pour en faire un modèle généraliste qui pourra être cloné pour créer de nouvelles VM. La VM ainsi figée ne pourra plus être utilisée en tant que machine virtuelle.

Avec le clonage, on obtiendra des machines conformes en tous points au modèle (même nom, même uuid au niveau de la carte réseau, même @IP si nous avons choisi un adressage fixe). Il nous faudra donc un petit script qu’on va implanter sur la VM qui destinée à devenir template pour pouvoir modifier simplement ces éléments sur les clones.

Préparation du template

On vérifie l’adresse IP

ip addr

On affiche le fichier de configuration réseau

cat /etc/sysconfig/network-scripts/ifcfg-eth0

Et on s’assure que l’interface réseau est correctement activée au démarrage

Directive : ONBOOT=yes

Pour éditer le fichier :

'vi /etc/sysconfig/network-scripts/ifcfg-eth0'

Pour ceux qui ne sont pas à l’aise avec les commandes vi,

  • il faut taper la touche 'i' pour passer en mode édition
    • Effectuer les modifications éventuelles
  • taper la touche 'Esc' pour repasser en mode commande
  • puis les touches ':wq' pour sauvegarder et quitter l'éditeur.

Enfin, il faut

soit redémarrer la VM

    shutdown -r now

soit relancer le réseau

    systemctl restart network

On vérifie que ça a bien marché avec 'ip a ou ip addr' et que le réseau est bien opérationnel avec

ping centos.org.

Les VM créées étant identiques en tout point, il faut à minima modifier le nom de la VM et l'UUID de la carte réseau au risque d'avoir un fonctionnement erratique.

On va donc implanter dans le dossier root, sur la VM initiale un petit script (uuid.sh) qu'on pourra exécuter sur chacun des clones qu'on créera par la suite.

Le script uuid.sh

#!/bin/bash
# -------------------------
# Modifie l'UUID et le nom du serveur
# Commande : ./uuid.sh <Nom-du-nouveau-serveur>
# exemple : ./uuid.sh server0
# -------------------------

sed -i "/^UUID/d" /etc/sysconfig/network-scripts/ifcfg-eth0
echo "UUID=\""`uuidgen`"\"" >> /etc/sysconfig/network-scripts/ifcfg-eth0
cat /etc/sysconfig/network-scripts/ifcfg-eth0
echo
hostnamectl set-hostname $1.localdomain
hostnamectl
read -p "Appuyez sur une touche pour redémarrer le serveur ..."
Shutdown -r now

Dans le fichier ifcfg-eth0, le script supprime la ligne ou est déclaré l’UUID puis il crée un nouvel UUID unique qu’il ajoute en fin de fichier. Il modifie ensuite le nom du serveur avec celui passé en argument de la ligne de commande et lorsque les changements ont été appliqués, il redémarre le serveur.

Ce script ci-dessus est à copier/coller dans le fichier /root/uuid.sh. On modifie ensuite les droits du fichier pour qu'il puisse être exécuté :

chmod u=rwx,o= /root/uuid.sh

Une fois fait, il ne reste plus qu'à convertir la VM en Template. C'est très simple à faire : -> Sélection de la VM, clic droit et sélection de l'option 'Convert to template'.

Le template apparaît alors dans la liste des VM avec une icône sensiblement différente des VM sans l’indicateur d’activation vert.

h) Utilisation du template, création d'un clone

Maintenant que le template est prêt, on va pouvoir cloner de nouvelles VM. Pour cela, on sélectionne le template puis clic droit sur le template et on sélectionne 'clone' dans le menu déroulant.

Dans la fenêtre qui s'affiche,

  • On peut préciser sur quel serveur Proxmox (node) on peut déployer le clone - ici, on n'a pas le choix - c'est celui qu'on utilise.
  • Il faut donner un numéro unique à la VM >= 100
  • Idem pour le nom qui peut être identique à d'autres VM mais ce n’est pas conseillé si on veut s’y retrouver.
  • Idéalement on prendra le mode 'Full clone' qui permet de rendre indépendante la VM du Template. Ça prend un peu plus d'espace disque mais c'est plus souple d'utilisation notamment au niveau des mises à jour systèmes.
  • Pour la dernière option, on choisir d'implanter la VM au même endroit que le template.

Il ne reste plus qu'à cloner le template. Ça prend 2 à 3 minutes. Une fois terminé, on peut démarrer la VM. On peut ainsi créer autant de VM que l’on veut et ça prend 3 à 4 mn par VM, par rapport à une installation classique qui prend environ 30 à 40 mn, il n’y a pas photo...
Sur cette base, on va créer 2 VM. Lorsque les 2 VM sont créées, il faut les démarrer et exécuter le script uuid.sh.

En étant en compte root, dans le répertoire root, la commande est :

./uuid.sh sweb

<sweb> étant le nom du serveur donné en argument du script
Sur la base de cet exemple, la VM devrait être dotée d'un nouveau UUID et son nom devrait être sweb.localdomain
Il faut faire la même chose avec la seconde VM en lui donnant comme nom 'sdb'.
On aura ainsi 2 VM, qui seront affectées respectivement à la fonction de serveur web et de serveur de base de données, selon le principe de la séparation des fonctions. On va pouvoir maintenant installer Apache sur le serveur sweb et MariaDB sur le serveur sdb. L’étape suivante va consister à utiliser et mettre en évidence l’intérêt du Snapschot.

i) Le snapschot

Proxmox permet de prendre une image instantanée d'un serveur. On ne va pas s'en priver.

Avant de faire quoi que ce soit de plus, on va figer la configuration du serveur web par un snapchot. Le snapchot, c’est une photo instantanée du serveur, contexte inclus (mémoire, processus…), sur laquelle on pourra revenir si l’installation se passe mal.

Effectivement en cas de soucis, si on n’a pas pris la précaution de prendre un snapshot, il faudra repartir du template pour reconstruire la VM. C’est donc une excellente pratique que de faire un snapchot d’une VM avant n’importe quelle intervention.

Pour ce faire, on sélectionne sweb et on clique sur ‘snapshots’ dans le menu vertical de gestion de la VM.
Dans la fenêtre qui apparait, on donne un nom au snapshot ex : snapsweb puis on clique sur le bouton 'Take Snapschot'.
Ça prend quelques minutes histoire de sauvegarder la VM et son contexte

1) Installation du module web sur la VM sweb

Pour le serveur web, on va installer Apache et son module de sécurité.

yum install httpd mod_ssl -y

Ouvrir les flux http et https sur le parefeu

firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

Démarrer Apache et activer le démarrage automatique du service.

systemctl start httpd
systemctl enable httpd

Vérifier que le service httpd a bien démarré

systemctl status httpd

Pour tester le fonctionnement d’Apache à partir d’Internet, il faudra tenir compte de la présence ou non d’un serveur DNS et/ou d’un reverse proxy, ce qui nécessitera des paramétrages supplémentaires au niveau de ces deux machines, (entrée DNS, VirtualHost, redirection).

Le test en local affiche la page mire d’apache sous centOS. En saisissant dans la barre de navigation l’adresse IP du serveur.
Sur le serveur web, on va maintenant installer PHP et pour cela, on ne va pas utiliser le dépôt CentOS mais celui de webtatic.com. Par sécurité, on va au préalable effectuer un nouveau snapshot de la VM sweb.

Pour installer le repos webtatic, la commande c'est :

rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm

puis pour installer php 7.2

yum install php72w php72w-opcache php72w-gd php72w-mbstring php72w-pdo php72w-mysql php72w-cli php72w-xml -y

On vérifie la version PHP installée avec la commande

php –v

2) Installation d’un moteur de base de données sur la VM sdb

Sur le serveur de base de données, on va commencer par créer un snapshot, des fois que…

Puis une fois fait, on va installer MariaDB via le repo standard de CentOS.

Commandes :

yum install mariadb-server mariadb -y
systemctl start mariadb
systemctl enable mariadb

On sécurise le moteur de base de données

Commande :

mysql_secure_installation
->Mot de passe courant : <return>
-> Modifier le password root ? [Y/n] : Y
-> Nouveau Mot de passe ? !Andre-ani
-> Supprimer les utilisateurs anonymes ? [Y/n] : Y
-> Bloquer les connections root distantes ? [Y/n] : n
-> Supprimer la base de tests et les droits d'accès ? [Y/n] : Y
->Recharger les privilèges des tables ? [Y/n] : Y
Thank for using MariaDB!

On vérifie la connexion à la base de données.

Commande :

mysql -u root -p
-> Password: **********
-> Bienvenue ....
Mariadb [(none)] > quit;

Réinstallation de MariaDB

Si on regarde de plus près sur le serveur de base de données, la version MariaDB installée est plutôt ancienne. Cela est dû au fait que CentOS dans ses dépôts privilégie la stabilité au détriment des nouveautés. Ceci étant ça marche.

Pour afficher la version de mariaDB la commande c'est :

mysql --version

On va donc annuler notre installation en utilisant le snapshot de la VM sdb et installer la dernière version stable de mariaDB.

 

1°) Revenir à la plateforme vierge avec le snapshot

Sélectionner la VM sdb0, cliquer sur Snapshot, puis sur le fichier 'snapshot_sdb0' et lancer la réinitialisation via le bouton 'Rollback'.

2°) Installer le repos MariaDB en version 10.3

Il faut créer un fichier MariaDB.repo dans le répertoire /etc/yum.repo.d/ et y insérer les lignes ci-dessous.

nano /etc/yum.repo.d/MariaDB.repo
# MariaDB 10.3 CentOS repository list - created 2019-05-06
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.3/centos6-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

3°) Installer MariaDB 10.3

yum install MariaDB-server MariaDB-client -y

4°) Sécuriser le moteur de base de données comme précédemment.

mysql_secure_installation

5°) tester la connexion

mysql -u root -p

A ce stade, on dispose d’un serveur web capable de servir des pages html uniquement et d’un serveur de base de données opérationnels sur 2 VM.

j) Modifier le libellé d’une VM

La modification du libellé (nom) d’une VM est simple.

Il suffit de sélectionner la VM, dans le menu de gestion sélectionner 'Option', cliquer sur le champ 'Name', cliquer sur le bouton Edit et une fenêtre s'affiche qui permet de modifier le nom de la VM.

k) Modifier l’ID d’une VM

Il n'est pas possible via l'interface d’administration Proxmox de modifier l'ID d'une VM. Toutefois, via la sauvegarde/restauration de la VM, on va pouvoir lui affecter un autre ID.
Pour ce faire, on sélectionne la VM qui doit changer d’ID exemple : la VM n°101 et dans le menu de gestion, on clique sur 'Backup' puis sur le bouton 'Backup now'. Dans la fenêtre de sauvegarde on sélectionne le mode 'Stop'. La VM sera alors arrêtée, sauvegardée puis redémarrée. Lorsque la sauvegarde est terminée (statuts TASK OK), on lance la restauration de la VM.

Dans le processus de restauration, il est possible de spécifier un n° de VM différent du numéro actuel.
Pour restaurer une VM, on sélectionne le disque 'local(pve2)' puis on affiche le contenu en sélectionnant 'content' dans le menu de gestion. Le fichier sauvegardé commence par vzdump-quemu-101 suivi de la date de sauvegarde. Le numéro 101 correspond à l'ID initial de la machine sauvegardée.

On clique sur le fichier vzdup-qemu-101... et clique sur le bouton 'Restore'. Une fenêtre s'affiche pour proposer de restaurer la VM sous l'ID 101. A ce niveau, on peut modifier l'ID pour restaurer la la VM 101 sous l'ID 110 par exemple puis on clique sur le bouton 'Restore' pour lancer la restauration.

Il ne reste plus qu'à redémarrer la VM n°110 en vérifiant que tout fonctionne correctement.
Si tout s’est bien passé, on peut maintenant supprimer la sauvegarde de la VM n° 101 ainsi que la VM 101.

l) Suppression d’une VM

Pour supprimer une VM, la commande 'Remove' est cachée. La suppression n'est réalisable que si la VM est arrêtée.
Pour supprimer une VM, il faut :

  • sélectionner la VM à supprimer
  • cliquer sur le bouton 'More' qui est en haut à droite, sous le menu de création des VM
  • sélectionner 'Remove' dans le menu déroulant qui s'affiche
  • dans la fenêtre de suppression, indiquer le n° de la VM à supprimer.
  • et couik

On remarquera que la suppression d’une VM supprime aussi les Snapshots qui s’y rapportent.

m) Démarrage des VM au boot du serveur physique.

On va paramétrer les VM pour qu'elles démarrent au boot de la machine physique et dans un ordre qui nous convient.

Pour cela, on sélectionne la VM sdb0 puis 'Options' dans le menu de gestion. On double-clic sur 'Start at boot' et on coche la case à cocher dans la fenêtre qui s'affiche.
Sur la ligne en dessous 'Start/Shutdown order', en double-cliquant, on peut indiquer dans quel ordre on souhaite voir la VM démarrer.
On va indiquer que sdb0 démarrera en premier -> 1 suivi de sweb0 en deuxième -> 2 avec un délai de 0 secondes pour sdb0 et de 30 secondes pour swb0 et inversement pour l'arrêt des VM.
De fait au démarrage de la machine physique sdb0 démarrera de suite. 30 secondes après la VM sweb0 sera lancée à son tour et pour l'arrêt c'est l'inverse.
On teste le fonctionnement en redémarrant la machine physique. (Attention à ne pas l'arrêter parce que pour appuyer sur le bouton à distance, il faut avoir le bras long..

Pour se faire, on sélectionne la machine physique (pve2) puis on clique sur le bouton 'Reboot' du menu horizontal et on vérifie que les machines démarrent bien dans l’ordre indiqué.

Il reste 2 points à voir qui concernent les sauvegardes automatiques journalières des VM et l'interface en ligne de commandes.

m) Sauvegarde automatisée des VM

Cette fonctionnalité consiste à lancer la sauvegarde automatique des VM – on peut sélectionner celles qu’on souhaite sauvegarder - sur une périodicité et une heure données. Cette fonction est légèrement différente de la sauvegarde/restauration d’une VM dans le sens où ce que nous avons vu précédemment était une opération ponctuelle qui n’impacte qu’une VM. Ici, il s’agit d’automatiser la sauvegarde des VM par lot.

Pour programmer la sauvegarde automatique des VM, c'est simple.
Il faut sélectionner le Datacenter et dans le menu de gestion, sélectionner 'Backup', puis cliquer sur le bouton 'Add'.

Il ne reste plus alors qu'à sélectionner les VM qu'on veut sauvegarder (sweb0 et sdb0), l'heure de début de la sauvegarde : par exemple 2h00 du matin, tous les jours, en utilisant le mode 'Stop' - je préfère même si les machines ne seront plus accessibles durant le temps de la sauvegarde. C'est un choix purement personnel.

Le nombre de sauvegardes conservées peut se définir sur les espaces partagés au moment de leur création (partage NFS, …). Il faut donc être particulièrement vigilant pour ne pas rater ce paramétrage si on souhaite conserver les sauvegardes des VM sur plusieurs jours. Sinon, par défaut, sur l’espace local, la sauvegarde écrase celle de la veille.

Il faudra surveiller l'espace disque pour s'assurer de ne pas déborder la capacité disponible.

Interface en ligne de commandes

c'est aussi simple.

Il faut lancer le shell en sélectionnant au préalable le serveur physique (pve) ou en se connectant dessus en ssh.

La commande qui fait tout pour les VM, c'est 'qm'.

Exemple :

qm list -> liste les VM installées et leur état.
qm start 101 -> démarre la VM 101
...

En cas de difficulté avec l'interface graphique, il faut passer par la ligne de commande. Si une VM ne veut pas s'arrêter en mode graphique, le qm stop <id_vm> arrêtera la VM.

A ce stade, on a maintenant tous les outils pour travailler sur les VM en toute sérénité.

Un peu de sécurité

Si on regarde ce qui se passe sur la connexion ssh du serveur Proxmox, on constate avec effroi que bon nombres d’inconnus trouvent un intérêt particulier à vouloir pénétrer le système.

Clic sur pve2, et dans le menu de gestion, section 'system', clic sur 'Syslog'.

On voit alors apparaître en directe toutes les tentatives de connexion sur l'interface SSH du serveur physique. D'ici à ce que les pirates en herbe trouvent le mot de passe, on peut conserver une certaine sérénité. Néanmoins, les loulous accèdent directement à l'interface du Proxmox, ce qui est plutôt gênant, d'autant qu'au rythme où ils y vont, ils risquent de saturer les logs inutilement. On va donc masquer l'interface ssh.

Pour cela, on va créer une troisième machine virtuelle qu'on nommera 'scon' (serveur de connexion) via le template et on modifiera l'uuid avec le script.

Une fois fait, on redémarre la machine et on capte son adresse IP (commande 'ip a').
Puis on va y installer fail2ban

yum install fail2ban -y
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

On va paramétrer fail2ban via le fichier /etc/fail2ban/jail.local en modifiant les paramètres ci-après

nano /etc/fail2ban/jail.local
Ignoreip = 127.0.0.1/8 192.168.1.0/24
bantime = 2592000
findtime = 18000
maxretry = 3

[sshd]
enabled = true
port = ssh

[sshd-ddos]
enabled = true
port    = ssh

[selinux-ssh]
enabled = true
port     = ssh

[pam-generic]
enabled = true

Au-delà de 3 tentatives de connexion, sur une durée de 5h00, l'@IP est bannie pour une durée d'1 mois. Ça suffira bien.

On démarre fail2ban

systemctl start fail2ban

On active le démarrage au boot

systemctl enable fail2ban

On vérifie que tout roule

systemctl status fail2ban

On désactive le compte root pour la connexion SSH. La connexion SSH s'effectuera sur la VM scon et non plus sur le Proxmox. On pourra parfaire la sécurité en autorisant uniquement le compte de connexion, ici zorro pour l'exemple.

nano /etc/ssh/sshd_config
PermitRootLogin no     # Désactiver la connection ssh via le compte root
AllowUsers zorro

Ainsi, pour se connecter au serveur Proxmox, on se connectera sur la VM scon, à partir de laquelle on pourra accéder tranquillement au serveur physique (pve) ou aux autres VM.

Il faudra penser à modifier le NAT au niveau de la box Internet pour que le port 22 pointe sur l’adresse IP de la VM scon. Le serveur Proxmox se retrouve donc maintenant protégé sur son interface SSH. Si une tentative d’intrusion venait à réussir, seule la VM scon serait compromise.

Une fois le NAT mis en place, on pourra vérifier le fichier log de fail2ban

nano /var/log/fail2ban.log.

 

Section III – LES CONTAINERS (LXC)

 

Mise en place d’un container

C'est relativement simple ... mais pas forcément très intuitif et ça se passe là aussi en 2 phases comme pour les VM.
Proxmox est livré avec plusieurs Templates de container. On va commencer par en activer un ou deux en fonction du système qu'on voudrait installer.

a°) Activation d'un template

On sélectionne 'local (pve2)' au niveau du datacenter, puis 'content' pour afficher le contenu, puis on clique sur le bouton 'Template'. Tous les Templates disponibles sur Proxmox s'affichent pour les principaux OS disponibles sur le marché.

Si on a activé la mise à jour des Templates juste après l’installation avec la commande

pveam update

La commande suivante affiche tes les Templates mis à jour.

pveam available

Ils sont répartis en 2 catégories ; les systèmes d'exploitation et les applications préinstallées sur débian9.

On va sélectionner une centos7 dans la liste des OS et on va cliquer sur le bouton 'télécharger'. Ce faisant, le fichier container qui est au format (tar.gz) va s'installer sur 'local (pve2)' dans la section 'Container Template'. Ca prend un peu de temps... histoire d’absorber la charge.

b) installation du container

Maintenant, ce n'est plus qu'un jeu d'enfant. Enfin presque

On va cliquer sur 'pve2' au niveau du datacenter, puis on va cliquer sur le bouton 'create CT'.
Dans la fenêtre de création, vue 'General', on va choisir un ID unique, un nom pour le container et un mot de passe root.
Dans la vue Template, on va sélectionner le template qu'on a installé sur local (pve2).
Dans la vue Root-Disk, on va monter à 15Go la taille du disque.
Dans la vue CPU, on va pousser à 2 cores.
Dans la vue Memory, on va monter à 4Go avec un swap de 0,5 Go.
Dans la vue Network, on va sélectionner DHCP pour éviter les embrouilles.
Dans la vue DNS, on laisse tel quel
Dans la vue Confirm, on valide nos choix en cliquant sur le bouton 'Finish'.

Y a plus qu'à attendre que l'installation se fasse.

De façon générale, toutes les actions sur les VM fonctionnent elles aussi sur les Containeur. Il y a cependant quelques exceptions ou différences comme la connexion sur le port 22 d’un container qui est beaucoup plus sécurisée que les VM. Sans clé SSH, la connexion n’est pas autorisée.

On peut néanmoins se connecter en SSH sur le serveur Proxmox puis accéder à la console via la ligne de commande.

Pct console <id-ct>

Pour accéder à la console, il faut taper deux fois ‘CTRL+a’ et pour quitter le mode console ‘CTRL+a +q’.

c) Démarrage du Container

Clic sur le nouveau serveur puis clic droit et sélectionner 'start'.
Se connecter en root

d) Mise à niveau de l’OS du container

yum update -y

On remarquera que l’exécution est un peu plus rapide que sur une VM. La machine répond plus vite. C'est la caractéristique secondaire qui fait qu'on choisira plutôt un container plutôt qu'une VM ; la caractéristique essentielle étant la sécurité.

Le reste après, ça se gère tout comme une VM à l'exception de la ligne de commandes qui est beaucoup plus utilisée avec les containers. L’outil pour gérer les CT en ligne de commande, c’est ‘pct’ pour (Proxmox Container Toolkit).

Exemples :

pct list → affichera les CT et leur état
pct start <ctid> → démarrera le container possédant le numéro d’ID spécifié.
pct set <ctid> -onboot 1 → active le démarage automatique du CT au lancement de Proxmox.

e) Gestion des ‘Snapshots’

La gestion des Snapschot est identique à celle des VM si le CT est monté en local. Sur un espace partagé de type NFS, le Snapshot n’est pas autorisé. Néanmoins, il est possible de déplacer le CT d’un espace partagé NFS sur un espace local où le Snapshot peut être réalisé.

f) Les appliances

Il est possible d'installer des containers sur lesquels des applications sont préinstallées. Pour cela, il faut procéder de la même façon que ci-dessus mais en choisissant le container sur la base de l'application qu'on souhaite installer.

Une fois démarré, le paramétrage de l'application s'effectue automatiquement sous interface pseudo graphique.

On aime ou on n’aime pas. Moi je suis partisan de la seconde solution. Je préfère maîtriser mes installations plutôt que de les utiliser et puis une application pour un serveur, c'est un peu du gâchis d'autan que sur ces containers, tout y est installé (OS, application, serveur web, base de données, ...). Je suis pour la séparation des fonctions et donc je suis contre l'utilisation de ces appliances.

Je préfère gérer un serveur web qui alimente une centaines de sites internet et gérer un autre serveur qui va héberger les bases de données des sites du serveur web. Ça marche très bien et pour automatiser les sauvegardes ou les procédures de gestion, c'est beaucoup plus rapide et plus homogène. Après, c'est un choix personnel... évidemment.

Avec les CT, on dispose de fonctionnalités supplémentaires

Les quotas utilisateurs, les ACL qui sont des droits sur les fichiers en complément des droits traditionnels basés sur l’utilisateur, le groupe et les autres.

 

Section IV - VM ou CT

Comment choisir ?

Proxmox permet de gérer des machines virtuelles (VM) et des containeurs (CT). Si les VM sont moins performantes (perte de 15 à 20%), elles offrent une sécurité accrue du fait de l’étanchéité des VM par rapport à l’hyperviseur (Proxmox). Autre avantage des VM, elles sont indépendantes du noyau Proxmox, ce qui permet de pouvoir installer la distribution de son choix.

Les CT utilisent des primitives de l’hyperviseur. Elles sont donc plus performantes que les VM (de 15 à 20%), elles occupent moins d’espace disque mais sur le plan de la sécurité, elles sont beaucoup moins étanches que les VM. Si un CT est compromis, c’est l’ensemble de l’architecture Proxmox qui risque d’être lui aussi compromis. Ces considérations sont importantes lorsqu’on met en place une architecture basée sur la virtualisation. Ainsi, pour les serveurs à risque, ceux qui sont en interface utilisateurs (frontend), on préfèrera les VM et on déploiera les CT sur les machines en background.

Néanmoins concernant les CT, un autre paramètre est à prendre en compte. Il s'agit du lien très fort des CT avec le noyau Proxmox. De fait, en cas d'évolution du noyau PROXMOX, les choses se compliquent. Passer d'un PROXMOX sous Strech (ex : 5.4) à un PROXMOX sous Buster (6.x) nécessitera de réinstaller tous les CT sous Buster. Même si la fréquence des mises à jour reste faible, l'opération est loin d'être anodine.

 

Section V - GESTION DES UTILISATEURS

Sous Proxmox, la gestion des utilisateurs s'effectue au niveau du DataCenter. Cette opération se déroule en deux temps.

Il faut d'abord créer le compte utilisateur au niveau du serveur. Pour cela on sélectionne le serveur physique (pve) puis sur le menu horizontal, on ouvre une console en cliquant sur le bouton 'Shell'. Dans la console, on va créer l'utilisateur pbr18 avec la commande :

useradd pbr18
passwd pbr18
-> Enter password: **********
-> Retype password: **********

Lorsque le compte a été créé sur le serveur physique, il faut revenir sur l'interface d'administration Proxmox. Là, on sélectionne le Datacenter puis dans le menu de gestion, il faut cliquer sur 'Permissions' pour activer un sous menu déroulant.

Dans ce sous-menu, on va successivement :

  • Créer un groupe d'utilisateurs en cliquant sur 'Groups' puis sur le bouton 'Create'. Une fenêtre s'affiche vous invitant à saisir le nom du groupe à créer ainsi qu'un commentaire. Comme Nom, on choisira 'Admin' pour constituer un groupe d'administrateurs.
  • Créer un utilisateur en cliquant sur 'Users', puis sur le bouton 'Create'. Une fenêtre s'affiche vous invitant à saisir le Nom de l'utilisateur, enfin sélectionner la méthode de connexion (pam, pve), puis saisir la date d'expiration du compte, le prénom, le nom et l'email de l'utilisateur. En cliquant sur le bouton 'Add', le compte créé s'affiche dans l'interface Proxmox au dessus ou en dessous du compte root.
  • Affecter certains droits à l'utilisateur en sélectionnant 'Permissions' puis en cliquant sur le bouton 'Add'. De préférence, on attribuera les droits plutôt à des groupes qu'à des utilisateurs. Pour cela, on choisira 'Group permission' plutôt que 'User permission'. Dans la fenêtre qui s'affiche, on indiquera comme chemin la racine du serveur physique ('/'), on sélectionnera le groupe qu'on vient de créer ('Admin'), puis on attribuera le rôle 'Administrator' à tous les utilisateurs du groupe Admin. Il ne reste plus qu'à cliquer sur le bouton 'Add' pour finaliser la création de l'utilisateur.
    A noter que les privilèges associés au rôle 'Administrator' sont visibles en sélectionnant le sous-menu 'Rôles' du menu 'Permissions'.

A ce stade, le compte reste encore inopérant. Il faut encore accorder synchroniser le mot de passe de l'interface Proxmox avec le mot de passe déclarer sur le serveur.

Lorsque le mot de passe a été synchronisé, il suffit de se déconnecter puis de se connecter avec le nouveau compte.