PROXMOX

Virtualisation de vos serveurs ou datacenter

Chrtophe

Proxmox est un environnement complet de gestion centralisée de datacenter, s'appuyant sur l'hyperviseur KVM et le gestionnaire de conteneurs LXC.

Dans ce tutoriel, vous allez découvrir comment mettre en place Proxmox pour gérer votre parc de machines virtuelles.

Commentez

- Titre : PROXMOX

- Auteur : Chrtophe

- Parution : 27 juillet 2019

- Mise à jour : 18 octobre 2024

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2019 Chrtophe. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- 1. Description

- 1-1. Nomenclatures utilisées

- 2. Installation

- 2-1. Installation depuis l'ISO

- 2-1-1. Port par défaut

- 2-2. Installation sur un système existant

- 3. Fonctionnalité de datacenter

- 3-1. Préambule : le cloud

- 3-2. Datacenter proprement dit

- 3-3. Datacenter virtuel

- 4. Découverte de l’interface d’administration

- 5. Présentation rapide des menus

- 5-1. Centre de données

- 5-2. Serveur

- 5-3. Local network

- 5-4. local

- 5-5. Local-lvm

- 6. Le stockage dans Proxmox

- 7. Le réseau dans Proxmox

- 8. Création d'une VM

- 8-1. Les prérequis

- 8-2. Création de la VM proprement dite

- 8-2-1. Nom et emplacement de la VM

- 8-2-2. Choix du système d’exploitation

- 8-2-3. Onglet système

- 8-2-4. Disque

- 8-2-5. Processeur

- 8-2-6. Mémoire

- 8-2-7. Réseau

- 8-2-8. Confirmation

- 8-3. Démarrage de la VM créée

- 8-4. Additions invitées

- 9. Utilisation d’une VM

- 9-1. Montage d’un CD-ROM

- 9-2. Insertion d’une clef USB connectée à l’hôte

- 9-3. Accès au réseau

- 9-4. Accès au BIOS de la VM

- 9-5. Machine en UEFI

- 10. Modification des réglages d'une VM

- 10-1. Réglage/ajout de carte réseau

- 10-2. Ajout d'un disque à la VM

- 10-3. Agrandissement d’un disque

- 10-4. Carte son

- 10-5. Mappage de périphérique PCI

- 11. Gestion avancée de VM

- 11-1. Clichés

- 11-1-1. Création d’un cliché

- 11-1-2. Restauration cliché

- 11-1-3. Suppression de cliché

- 11-2. Cloner une VM

- 11-3. Créer un template

- 12. Création d’un conteneur

- 12-1. Prérequis : un modèle de conteneurs

- 12-2. Création d’un conteneur

- 12-2-1. 1er écran

- 12-2-2. Modèle

- 12-2-3. Disque

- 12-2-4. Processeur

- 12-2-5. Mémoire

- 12-2-6. Réseau

- 12-2-7. Finalisation

- 13. Sauvegarde

- 13-1. Sauvegarde sur support externe

- 13-2. Planification des sauvegardes

- 13-3. Sauvegardes incrémentales

- 13-4. Restauration

- 13-5. Proxmox Backup Server

- 13-5-1. Installation depuis ISO

- 13-5-2. Installation sur système existant

- 13-5-3. Ajout d’un datastore sur le serveur de sauvegarde ProxMox

- 13-5-4. Ajout d’un datastore de sauvegarde aux serveurs à sauvegarder

- 13-5-5. Visualisation des sauvegardes

- 13-5-6. Visualisation depuis Proxmox Backup Server

- 14. Import/export de VM

- 14-1. Import d'une VM au format OVA

- 14-2. Import depuis VMWare

- 14-3. Alternative

- 14-4. Export

- 15. Gestion d'un datacenter

- 15-1. Création d'un cluster

- 15-1-1. Contourner l'impossibilité de joindre à un cluster un hyperviseur avec des VM

- 15-1-1-1. Changement de VMID et renommage des disques

- 15-1-1-2. Rendre les VM « invisibles »

- 15-2. Migration d’une VM

- 15-2-1. Migration d’une VM de LVM vers ZFS

- 16. Haute disponibilité

- 16-1. Réplication

- 16-2. Activation de la haute disponibilité pour une VM

- 16-3. Gestion globale de la haute disponibilité

- 16-4. Perte d’un nœud

- 16-4-1. Suppression définitive d’un nœud perdu

- 16-5. Groupe de haute disponibilité

- 16-6. Fencing

- 17. Pool de ressources

- 17-1. Création utilisateur

- 18. Stockages distribués

- 18-1. Stockage ZFS

- 18-2. Stockage Ceph

- 18-3. Stockage GlusterFS

- 18-3-1. Création d’un volume GlusterFS

- 19. SDN : Software Defined Networking

- 20. Supervision

- 20-1. Zabbix

- 20-1-1. Installation serveur de Zabbix

- 20-1-2. Installation du client Zabbix sous Linux

- 20-1-3. Installation du client Zabbix sous Windows

- 20-2. InfluxDB Grafana

- 20-2-1. Installation InfluxDB

- 20-2-2. Paramétrage du serveur de métrique dans proxmox

- 20-2-3. Installation Grafana

- 21. Maintenance

- 21-1. Perte d'un nœud

- 21-2. Nœud intégrant Ceph

- 22. Les outils en ligne de commande

- 23. Options avancées

- 23-1. Montage offline d'images disque

- 23-1-1. Image disque contenue dans un volume LVM

- 23-1-2. Montage d’une image disque au format KVM qcow2

- 23-1-3. Montage d'une image VMDK

- 23-1-4. Montage hors ligne du disque d'un conteneur

- 23-2. Gestion de certificats

- 23-3. Authentification via LDAP ou Active Directory

- 23-4. Sécuriser l'accès à votre interface d'administration

- 23-4-1. Authentification à deux facteurs

- 23-4-1-1. Authentification OTP

- 23-4-1-2. Authentification Webauthn

- 23-4-1-3. Authentification Yubico

- 23-4-1-4. Clefs de récupération

- 23-4-1-5. Dépannage de l’authentification à deux facteurs

- 23-5. Suppression message de licence

- 24. Conclusion

- 24-1. Remerciements

1 - Description

Proxmox ou plus précisément Proxmox Virtual Environnement est un environnement de virtualisation open source (sous licence aGPL) pouvant être accompagné d’un service de support payant. L’environnement repose sur l’utilisation de l'hyperviseur Linux KVM et sur LXC pour les conteneurs.

Proxmox propose ainsi un système de gestion centralisée de machines virtuelles et de conteneurs. Cet environnement est conceptuellement équivalent à celui fourni par VMWare (vSphere Web Client) ou Hyper-V.

Avec Proxmox, la gestion de l’ensemble de vos ressources : vos hyperviseurs, vos machines virtuelles, vos conteneurs, vos espaces de stockage c’est-à-dire votre centre de données est centralisée.

Ce tutoriel est basé sur la version 8.2 de Proxmox, version disponible au moment de la publication de cet article.

Au moment de cette publication, la version 8.2 repose sur les briques suivantes :

- Debian 12 BookWorm ;

- noyau Linux 6.8.4-2 ;

- Ceph 17.2 ou 18.2.

1-1 - Nomenclatures utilisées

Le terme datacenter signifie centre de données.

L’abréviation « VM » (pour Virtual Machine) signifie machine virtuelle.

Le terme datastore est traduisible par espace de stockage

Les différents termes ci-dessus seront utilisés tant en français qu’en anglais, l’usage de la version anglophone étant répandu aussi bien dans les produits utilisés qu’entre informaticiens.

Dans Proxmox, le terme « machine virtuelle » peut désigner des machines virtuelles comme des conteneurs.

Un nœud, au sens réseau, va être une machine connectée. Au sens centre de données, un nœud va être un ordinateur faisant partie du centre.

2 - Installation

Proxmox peut être installé soit à partir d’un fichier ISO, soit à travers le gestionnaire de paquets.

Le support de la virtualisation doit être activé dans le BIOS de la machine sur laquelle sera installé Proxmox. Ce sera normalement le cas si votre machine est un serveur physique, pas forcément sur un poste standard.

En cas de support non activé, vous aurez une boite de dialogue d’avertissement lors de l’installation depuis l’ISO.

2-1 - Installation depuis l'ISO

Au moment de l'écriture de ce tutoriel, l'ISO permettant l'installation de Proxmox est téléchargeable ici. Celui-ci est basé sur Debian BookWorm.

Voici l'écran de démarrage :

Après avoir démarré, nous aurons l’écran d’acceptation de licence :

Puis l’écran de sélection des options de disque de destination :

Proxmox effacera d'éventuelles données présentes sur le disque.

Si vous avez plusieurs disques durs, vous pourrez sélectionner celui où installer Proxmox

Si vous sélectionnez le bouton « options », vous pourrez personnaliser les partitions :

Les types de partitions disponibles étant :

- ext4 ;

- xfs ;

- ZFS (voir chapitre sur ZFS pour plus d’informations) ;

- BTRFS (avec éventuellement RAID 1, RAID 10).

En cas de passage en ZFS, notamment dans le choix d’une utilisation en disque unique (RAID 0), prenez garde à ne pas modifier un second disque si vous ne le souhaitez pas ou si votre clef USB sert à l’installation :

L'écran suivant permettra de sélectionner votre pays, le choix du pays remplissant automatiquement les champs « timezone » et la disposition des touches du clavier (que vous pouvez aussi personnaliser à votre guise). Il suffit de taper le début du nom du pays.

Il faudra ensuite renseigner le mot de passe (minimum 8 caractères) et l'adresse mail de l'administrateur (adresse mail obligatoire pour passer à l’écran suivant) :

Vous pourrez ensuite personnaliser le nom de machine (FQDN obligatoire ) ainsi que les réglages réseau :

En cas de présence de plusieurs cartes réseau, seule celle sélectionnée est paramétrable à ce stade. Elle servira d’interface de gestion pour Proxmox. Les autres cartes réseau devront être paramétrées après l’installation.

Le nom d’hôte doit correspondre à un nom de domaine pleinement qualifié, vous pouvez mettre .local pour un serveur non connecté à Internet.

Vous aurez enfin un résumé des préréglages. L’installation démarrera une fois le bouton « install » cliqué.

Si vous ne souhaitez pas de redémarrage automatique en fin d’installation, décochez l’option en bas d’écran.

L’installation s’effectue ensuite automatiquement :

Vous aurez l'écran suivant vous rappelant l'URL d'accès à l'interface d'administration (https://adresse_ip:8006), suivi d’un redémarrage après quelques secondes si vous n’avez pas décoché l’option redémarrage automatique.

Vous aurez enfin l’écran GRUB standard avant le démarrage automatique :

Une fois le démarrage effectué, vous aurez une demande de login standard dans la console :

Le message affiché redonne l’URL d’accès à l’interface d’administration Web.

Un accès SSH est disponible.

2-1-1 - Port par défaut

L'interface Web de Promox écoute par défaut en HTTPS sur le port 8006. Il n'y a pas de réglage pour changer ce port.

Vous pourrez contourner ce comportement depuis un reverse proxy ou une redirection avec iptables.

2-2 - Installation sur un système existant

En prérequis pour l’installation, vous devrez avoir les fichiers /etc/hosts et /etc/hostname positionnés correctement.

Si le fichier hosts n’est pas correctement paramétré, l’installation échouera.

Proxmox propose à ce jour des dépôts pour Debian Wheezy (version 7, pour les anciennes versions de Proxmox) jusqu’à Debian BookWorm (version 12).

Il faudra commencer par récupérer la clef de sécurité du dépôt pour BookWorm :

wget http://download.proxmox.com/debian/proxmox-release-bookworm.gpg

Il faudra adapter le nom du fichier pour les anciennes ou les futures versions. La liste des fichiers disponibles est consultable à l’adresse : http://download.proxmox.com/debian/

Nous intégrons la clef :

apt-key add proxmox-release-bookworm.gpg

Nous ajoutons le dépôt dans /etc/apt/sources.list :

deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

Il est possible d'utiliser le dépôt de test pour avoir les versions les plus à jour ainsi que les fonctionnalités expérimentales :

deb http://download.proxmox.com/debian/pve bookworm pvetest

Nous installons les paquets Proxmox ainsi que Postfix pour les mails :

apt-get install proxmox-ve postfix open-iscsi

Après le téléchargement des paquets, vous aurez en premier les écrans de configuration de postfix. Pour une installation standard, laissez sur « Internet ». Comme Proxmox installe un nouveau noyau (pour le support de la virtualisation), un redémarrage est donc nécessaire.

Une fois le redémarrage effectué, vous pourrez supprimer votre ancien noyau.

Après démarrage, vous aurez l’URL de connexion à l’interface web de Proxmox dans le prompt de la console :

L'installation sur un système existant n'écrase pas celui-ci. Il change le fichier /etc/issue, installe un noyau avec support de KVM, les outils Proxmox et son interface Web.

3 - Fonctionnalité de datacenter

3-1 - Préambule : le cloud

Ce que l’on nomme le « Cloud » est un regroupement de services accessibles à distance. Ces services sont mis à disposition par un ensemble d’équipements hébergés dans des centres de données (datacenters).

Les principaux services utilisables proposés sur le cloud vont être du plus bas vers le plus haut niveau :

- Infrastructure as a Service (IaaS) : l’utilisateur gère son infrastructure, la gestion et la maintenance des équipements physique sont à la charge du fournisseur de service, la gestion des ressources fournies est à la charge de l’utilisateur du service. Les ressources disponibles (nombre de machines physiques pour supporter l’infrastructure, l’espace disque, la configuration des machines en matière de CPU et RAM) vont dépendre de l’offre et de la tarification ;

- Platform as a Service (PaaS) : le fournisseur met à disposition et maintient un environnement d’exécution (machine et système d‘exploitation). L’utilisateur gère et maintient les applications dans cet environnement. Cette solution est peu courante, en général on utilisera soit du IaaS, soit du SaaS. Hors gestion d’infrastructure, si vous prenez un serveur chez un hébergeur, celui-ci vous fournira une installation de base, à votre charge d’effectuer la configuration. En cas de problème, vous pourrez automatiquement repartir sur une installation de base en écrasant la machine d’origine. Le fournisseur de service n’interviendra pas sur votre instance (sauf contrat spécifique), il fera en sorte de la maintenir en conditions opérationnelles sur son infrastructure ;

- Software as a Service (SaaS) : le fournisseur fournit et maintient un logiciel au sens large et donc tout ce qui en découle (machine, contrôle d’accès à celle-ci, système d’exploitation, éventuellement la base de données utilisée par le logiciel). Un exemple de cette configuration est la mise en service d’un logiciel de comptabilité, d’un CRM/ERP, ou encore, d’un CMS.

À cela vont se rajouter d’autres dénominations « as a service » qui sont des sous-ensembles des dénominations ci-dessus telles que :

- Storage as a Service (STaaS) : concerne de l’espace de stockage normalement redondant et extensible, et en général accessible via une API et éventuellement une interface Web, qui comprend trois sous-ensembles :

- File Storage : l’espace de stockage est accessible comme n’importe quel système de fichiers,

- Bloc Storage : accès par blocs comme le fait un système de fichiers sur un disque dur. L’analogie la plus proche étant l’utilisation d’un SAN,

- Object Storage ou stockage objet : un ensemble de clefs/valeurs, par exemple, le service Amazon S3 (un fichier dans ce cas peut être un objet) ;

- Desktop as a Service (DaaS) : l’utilisateur se connecte à un bureau à distance. Ces fonctionnalités existaient avant le cloud avec par exemple RDS de Microsoft ou les produits Citrix.

- Database as a Service(DBaaS) : le fournisseur met à disposition et maintient un système de base de données. Ces bases de données peuvent être SQL (MySQL, PostGRESQL, SQL-Server) ou NoSQL (MongoDB, Cassandra) ;

Les sauvegardes ne sont pas forcément à la charge du fournisseur.

- Backup as a service (BaaS) : comme le nom l’indique, il s’agit ici d’une solution de sauvegarde managée. La solution proposée va répondre de ce qui doit être sauvegardé (simples fichiers, base de données, machine virtuelle complète). La rétention des données va dépendre de la solution et de la tarification proposées.
Cette liste n’est pas exhaustive.

La gestion de ces différents services peut s’effectuer :

- par l’intermédiaire d’une interface Web ;

- par l’intermédiaire d’API ;

- depuis des commandes en terminal.

Selon le prestataire et l’offre choisi(e), vous aurez accès à ces trois possibilités ou au moins une et avec un accès partiel ou complet.

Au niveau des interfaces de gestion, l’interaction avec l’infrastructure s’effectue en différentes parties standardisées :

- Compute : regroupe la création et la gestion des VM ou conteneurs ;

- Storage : regroupe la gestion du stockage. Il peut être séparé ou non de la partie compute, du stockage peut également être utilisé en cloud sans Compute ;

- Network : regroupe tout ce qui est gestion réseau de la solution utilisée avec souvent une partie publique et une partie privée (exemple pour la partie privée : réseau interne accessible uniquement aux machines gérées dans la partie compute) ;

- Identity : que l’ont peut maintenant trouver sous la dénomination IAM (Identity and Access Management). Cela concerne la gestion des droits d’accès : comptes utilisateurs, clefs API, etc. ;

- Data ou database : partie dédiée à la gestion de base de données.

Cette liste peut varier selon la solution proposée.

3-2 - Datacenter proprement dit

Un datacenter, ou centre de données, est une infrastructure industrielle regroupant dans un ou plusieurs bâtiments des ressources informatiques composées de serveurs, d’équipements réseau, d’un groupe électrogène et de dispositifs de sécurité (incendie, intrusion).

Un datacenter peut appartenir à une grosse entreprise, il sera alors privatif ; ou il peut appartenir à un hébergeur/fournisseur de services Cloud.

3-3 - Datacenter virtuel

Du point de vue de Proxmox, vous allez gérer un datacenter virtuel, avec un seul ou plusieurs serveurs et avec un point unique d’accès aux réglages.

Les ressources gérées seront :

- un ou plusieurs serveurs ;

- des espaces de stockage : répartis ou non sur plusieurs machines, partagé ou non entre les différentes ressources, des NAS externes, des systèmes de fichiers distribués, etc. ;

- des modèles de création de VM ou de conteneurs ;

- des ressources réseau (switch virtuel ou vswitch) ;

- des pools de ressources (regroupement de différentes ressources sous une même entité, comme une vue) ;

- des machines virtuelles ;

- des conteneurs.

Même avec un seul serveur, vous verrez le terme « datacenter » dans l'interface d'administration

4 - Découverte de l’interface d’administration

Nous nous connectons sur l’interface web d’administration via le port 8006, comme indiqué dans le message de bienvenue.

Vous aurez une alerte de sécurité dans votre navigateur indiquant un risque de sécurité, sauf si vous utilisez un nom d’hôte accessible sur Internet avec un nom de domaine possédant un certificat SSL pour ledit nom d’hôte.

Pour des raisons de sécurité, je ne recommanderais pas de rendre disponible un hyperviseur sur Internet.

Il faudra vous authentifier en utilisant le mot de passe root avec « Linux PAM standard authentification » (sélectionné par défaut).

Vous aurez ensuite un message « Aucune clef d’enregistrement valide », spécifique à la version gratuite de Proxmox :

Il suffira de cliquer OK.

Si vous avez une clef de suscription, vous pourrez la télécharger en sélectionnant la machine concernée dans le centre de données, puis l’option « abonnement » tout en bas de la liste.

Une fois connecté, vous aurez l’écran principal de gestion de votre Datacenter :

Celui se subdivise en trois parties :

- la partie gauche regroupant l’accès aux ressources (en dessous de « centre de données » ;

- la partie à droite donnant l’accès aux différentes options des ressources présélectionnées à gauche ;

- la partie en bas listant les tâches exécutées.

Ci-dessous une image de la partie gauche :

Vous pouvez voir dans la machine srv1 :

- 101 (CT101) : un conteneur avec l’id 101 qui donne accès aux réglages du dit conteneur ;

- 100 (VM 100) : une machine virtuelle avec l’id 100 qui donne accès aux réglages de ladite machine virtuelle ;

- localnetwork (srv1) : accès aux ressources réseau disponibles sur srv1 ;

- local (srv1) : accès aux ressources disque locales de srv1 dédiées aux images ISO et sauvegardes ;

- local-lvm (srv1) : accès aux disques de machines virtuelles (volumes logiques LVM contenant les disques des VM).

D’autres présentations sont possibles, accessibles en cliquant sur le menu déroulant « vue serveur ». Ci-dessous la liste des présentations :

- la vue serveur : vue par défaut ;

- la vue dossiers

- la vue pool.

Ci-dessous les différentes vues :

Aucun pool n’est créé pour le moment. Cette notion sera vue ultérieurement.

5 - Présentation rapide des menus

Vous sont présentées ici rapidement les fonctionnalités disponibles en partant du menu de gauche, fonctionnalités qui seront présentées de façon plus complète par la suite. Cette liste est présentée en partant de l’affichage en vue serveur.

Certaines fonctionnalités sont accessibles dans plusieurs menus, car liées au contexte de ceux-ci.

5-1 - Centre de données

Il s’agit ici du point d’entrée principal pour la gestion du datacenter virtuel.

- Résumé : va afficher le nombre de nœuds, de VM, de conteneurs, va donner également un état de la charge du matériel :

- Notes : zone où vous pouvez enregistrer le texte de votre choix.

- Grappe de serveurs : permet de créer/rejoindre un cluster.

- Ceph : accès à la partie gestion d’un espace de stockage Ceph.

- Options : réglages tels que la disposition du clavier ou l'adresse mail de l'administrateur.

- Stockage : permet d'ajouter, supprimer, éditer les stockages disponibles (ce point sera étudié au chapitre suivant).

- Sauvegarde : sera vu en détail au chapitre sauvegarde.

- Réplication : sera vu au chapitre réplication.

- Permissions : ceci permet de gérer les autorisations d’accès à des ressources pour des utilisateurs ou par des API. Cet aspect sera étudié ultérieurement.

- HA : pour le contrôle de la haute disponibilité (fonction avancée et nécessitant plusieurs serveurs).

- SDN : acronyme de Sofware Defined Networking, nouveau modèle d’architecture réseau gérant l’abstraction de fonctionnalités.

- ACME : pour la gestion de certificat SSL avec Let’s Encrypt.

- Pare-feu : permet l'ajout de règles IPTables (un champ commentaire est également présent).

- Serveur de métrique : permet l’installation de Graphite, ou InfluxDB, permettant un suivi de l’utilisation des ressources.

- Correspondance de ressource : permet l’accès au PCI ou à l’USB Passthrough. Pour le PCI Passthrough, votre processeur doit gérer l’IOMMU, la fonctionnalité Intel VT-d ou IOMMU doit être activée au niveau du BIOS.

- Support : disponible uniquement dans la version payante.

5-2 - Serveur

L’accès dans notre cas de figure se fera par un clic sur srv1, le nom de notre unique serveur. En cas de présence de plusieurs serveurs, ils auront chacun le même menu.

- Résumé : détail sur le serveur proprement dit, plus précis que le résumé général du datastore et filtrant au niveau serveur dans le cas où il y en a plusieurs.

- Notes : un espace dédié à ce serveur où vous pouvez inscrire ce que vous souhaitez.

- Shell : ouvre une console sur ce serveur :

- Système : le clic sur système affiche les différents services qu’il est possible de stopper ou redémarrer. Ci-dessous le détail du sous-menu de système :

- réseau : permet la gestion des cartes réseau en interface graphique,

- certificats : le chargement de vos propres certificats via l’icône « upload » vous permettra de ne plus avoir l'avertissement « connexion non sécurisée » dans votre navigateur,

- DNS : les serveurs DNS pour l'accès externe,

- hôtes : permet la visualisation et la modification du fichier /etc/hosts,

- options : accès au décalage du démarrage automatique et à l’adresse MAC pour le wake-on-lan. Vous ne devriez pas avoir besoin de modifier ces réglages,

- heure : permet le réglage du fuseau horaire,

- system log: accès au contenu de syslog avec possibilité de filtrage par date ;

- Mise à jour : permet la mise à jour des paquets de l'OS.

- Pare-feu : accès à l’ajout de règles iptables.

- Disques : affiche les différents disques et partitions physiques du serveur (accès aux registres S.M.A.R.T.) :

- LVM : accès à la gestion des Volume Group LVM (si LVM présent) ;

- LVM-Thin : Accès aux Thinpools ;

- répertoire : va permettre de créer un répertoire à l’usage du stockage d’images disque pour les VM ;

- ZFS : partie gestion d’un espace de stockage ZFS.

- Ceph : accès à la gestion d’un espace de stockage CEPH.

- Réplication : accès au service de réplication en cas de présence de plusieurs serveurs.

- Historique des tâches : l’historique des opérations effectuées sur le serveur.

- Abonnement : endroit ou entrer la clef d’enregistrement en cas de souscription à un abonnement auprès de Proxmox.

5-3 - Local network

Dans cette partie, vous aurez accès aux différents VMNets et à leurs permissions :

5-4 - local

Cette partie contiendra les images ISO ou modèles de conteneurs dont vous aurez besoin pour créer vos VM/conteneurs. La zone va également contenir les sauvegardes de machines générées :

5-5 - Local-lvm

Cette partie vous donne accès aux images disques des VM et conteneurs :

Vous ne pourrez pas supprimer une image disque utilisée par une machine virtuelle ou un conteneur. La suppression d’une VM ou conteneur n’implique pas forcément la suppression de son image disque.

6 - Le stockage dans Proxmox

Pour le stockage, Proxmox gère des magasins de données. Cette notion est aussi présente dans d’autres hyperviseurs. On trouve en général les magasins de données sous la dénomination de datastore.

Dans Proxmox, ces magasins de données vont contenir par défaut :

- des VM/conteneurs (datastore de conteneurs LVM) ;

- des ISO ou modèles de conteneurs (datastore dans un dossier du serveur).

Les magasins par défaut contiennent soit l’un soit l’autre, mais il est possible de modifier ce réglage.

Ce que peut contenir un magasin de données peut être modifié dans le menu datacenter → stockage → éditer. Il est possible d'ajouter ou retirer certains éléments d'un type de stockage.

Vous pouvez voir ci-dessus que le datastore « local » ne gère ni les images disques (ceci sous-entendant les images disques des VM), ni les conteneurs.

Les différents magasins de données pouvant être créés dans Proxmox sont aux formats suivants :

- les dossiers standards ;

- LVM ;

- BTRFS ;

- les points de montage SMB, NFS ;

- GlusterFS (un système de fichiers distribué) ;

- iSCSI ;

- CephFS ;

- ZFS ;

- ESXi : nouveau, permet le montage d’un datastore VMWare ESX.

Exemple d'ajout d'un dossier/point de montage :

Il faudra alors renseigner :

- l'id : il s'agit du nom de l'espace de stockage ;

- le répertoire : le point de montage ;

- le contenu : le type d’éléments contenus par l’espace de stockage (images, sauvegardes, templates, etc.) ;

- le nœud : uniquement nécessaire en cas de présence de plusieurs hyperviseurs.

Exemple pour l’ajout d’un datastore pointant sur un répertoire :

Selon le type d'espace de stockage, les champs présents seront adaptés à la situation. Exemples :

- export pour un point de montage NFS ;

- point de partage pour un point de montage CIFS ;

- choix du Volume Group pour LVM ;

- Volume Name pour GlusterFS ;

- etc.

Les réglages des stockages sont contenus dans le fichier /etc/pve/storage.cfg.

Il est possible d’effectuer un montage d'espace de stockage depuis la ligne de commande :

pvesm add dir nom_espace_stockage --path /point_de_montage --content backup

Pour sa suppression :

pvesm remove nom_espace_stockage

Combiné à la commande usbmount, qui monte automatiquement tout périphérique USB dans /media/usbX (si vous ne souhaitez pas effectuer de montage manuel), ceci permettra un usage en ligne autonome sans passer par l’interface de Proxmox.

N’hésitez pas à lire la documentation officielle de Proxmox sur les stockages ainsi que sur la commande pvesm (Proxmox VE Storage Manager) .

7 - Le réseau dans Proxmox

La gestion des cartes réseau s’effectue depuis [nom du serveur] → système → réseau :

Dans notre cas de figure, vous pouvez voir la carte réseau enp1s0, un pont vmbr0 crée par défaut et connecté à la carte réseau enps1s0, et une seconde carte réseau wlp2s0 correspondant à la carte Wifi interne (non utilisée par Proxmox) de mon hôte de test.

Le Bridge est une carte virtuelle permettant la création d'un pont entre une carte virtuelle, utilisée par une ou plusieurs VM et une carte réelle. En cas de présence de plusieurs cartes réseau physiques (classique sur un serveur), certaines VM pourront utiliser une carte précise pendant que d'autres VM utiliseront une autre carte.

La présence d’un Bridge est indispensable pour utiliser le réseau avec une VM ou un conteneur.

Si vous avez installé Proxmox depuis l’ISO, l’installation aura automatiquement créé un bridge. Si vous n’avez pas installé Proxmox depuis le CD, il vous faudra créer un Linux Bridge (ou un bond). Vous pouvez affecter une IP ou non au bridge.

Création du Linux Bridge :

Pour créer le bridge, il faudra cliquer sur « créer » et sélectionner « Linux Bridge » dans le menu serveur → système → réseau.

Le bridge sera connecté sur la première interface réseau. Vous pourrez manuellement affiner les réglages dans le fichier /etc/network/interfaces.

Création d'un Linux bond :

Un Linux Bond  va permettre de faire du bonding (combinaison de plusieurs cartes réseau en une seule carte virtuelle) avec plusieurs cartes réseau. Ceci va agréger plusieurs cartes entre elles pour être vues comme un seul adaptateur réseau. Vous pourrez utiliser les modes suivants :

- balance-rr : transmission des paquets séquentiellement sur chaque carte. Ce mode permet la répartition de charge (load-balancing) et la tolérance de panne ;

- active-backup : un seul des liens est utilisé en même temps. En cas de panne, l'autre lien prend le relais. Ce mode permet la tolérance de pannes ;

- balance-xor : les paquets sont transmis par une des cartes selon un calcul XOR sur les adresses MAC. Ce mode permet la répartition de charge (et la tolérance de pannes) ;

- broadcast : les paquets sont transmis sur toutes les interfaces. Ce mode permet la tolérance de pannes ;

- LACP : le protocole LACP (Link Aggregation Control Protocol) permet d’agréger 16 ports, dont 8 actifs. Ce mode permet la répartition de charge et la tolérance de pannes ;

- balance-tlb : le trafic sortant est réparti sur les différents liens, le trafic entrant sur l’un des liens (le lien de sortie qui a généré la liaison). En cas de panne, un autre lien récupère l’adresse MAC du lien HS ;

- balance-alb : inclut les fonctionnalités du mode balance-tlb, avec du load-balancing pour la réception en plus.

8 - Création d'une VM

8-1 - Les prérequis

La lecture des chapitres précédents sur le stockage et le réseau sont des prérequis pour pouvoir créer votre première VM, ne brûlez pas les étapes.

Avant de créer une VM, nous allons commencer par télécharger un fichier ISO qui nous permettra de procéder à l’installation de notre OS virtualisé depuis un média d'installation.

Pour pouvoir télécharger un ISO, il faut se rendre depuis le menu de gauche dans datacenter → srv1 → le stockage concerné, puis contenu, et enfin cliquer sur «téléverser» :

Une boite de dialogue vous demandera de sélectionner le fichier (soit un fichier ISO, soit un fichier de conteneur).

Il est également possible de télécharger le fichier depuis une URL.

Si vous allez dans le stockage local-lvm, les boutons upload et templates seront grisés, car vous ne pouvez pas stocker d'ISO ni de templates de conteneurs dans un volume LVM.

L'ISO sera alors disponible et visible.

Si le téléchargement échoue depuis la GUI ou si vous souhaitez le faire sans passer par celle-ci, il est possible de transférer l'ISO en SSH. Il faudra alors stocker celui-ci dans le dossier template/iso à partir de la racine du stockage.

Plus d'informations sur le stockage Proxmox ici.

Les données sont stockées dans /var/lib/vz/template/iso pour les fichiers ISO et dans /var/lib/vz/template/cache pour les templates de conteneurs ou dans les dossiers équivalents du magasin de données.

Les fichiers de définitions des VM sont dans /etc/pve/qemu-server/[id].conf.

8-2 - Création de la VM proprement dite

Nous pouvons passer ensuite à la création de notre VM proprement dite en cliquant sur « Créer VM » dans la barre en haut ou grâce au bouton droit sur le nom de votre serveur à gauche.

8-2-1 - Nom et emplacement de la VM

Depuis la fenêtre de création de VM, sur le premier écran, vous pourrez choisir le serveur s’il y en a plusieurs, dans notre cas srv1. Nous n’avons pas de pool (nous verrons les pools plus tard). L’identifiant par défaut de la VM conviendra, libre à vous de le modifier tant qu’il reste unique. Il restera à renseigner le nom de la VM :

Cocher la case « avancé » en bas à droite permet l’affichage d’options supplémentaires telles que « démarrer à l’amorçage » (et des options notamment de délai) qui démarrera automatiquement la VM lors du démarrage de la machine hôte de Proxmox.

Le redémarrage automatique d’une VM est une option qui peut avoir une importance. En cas de panne de courant ou redémarrage de l’hôte, les VM ne seront disponibles qu’après redémarrage manuel si l’option n’est pas cochée, ce qui pourra poser problème. À contrario, une machine de test ou clone de VM peut poser des problèmes et mettre la pagaille dans votre infrastructure si elle n’est pas censée être démarrée.

8-2-2 - Choix du système d’exploitation

Le second écran, « Système d’exploitation », va permettre de positionner des réglages par défaut tels que la quantité de mémoire (par exemple : Windows 7 requiert moins de mémoire que Windows 10). Ceci va optimiser les réglages pour l’OS souhaité (réglages que vous pourrez changer).

Ce second écran va vous demander :

- une image disque : il faudra sélectionner l’ISO et au besoin changer le datastore de l'espace de stockage (local ou autre) ;

- le type d'OS : choix entre Linux/Microsoft Windows/Solaris Kernel/Other., ainsi que la version.

Il est possible d’utiliser le lecteur CD de l’hôte plutôt qu’un ISO en cochant « utiliser le lecteur CD/DVD de l’hôte ».

L’option « ajouter un périphérique contenant les pilotes VirtIO » permet l’ajout de pilotes VirtIO dans l’OS de la VM. Ceci sera explicité ultérieurement.

8-2-3 - Onglet système

Vous aurez ensuite un écran nommé « Système ». Dans celui-ci, vous pourrez sélectionner :

- la carte vidéo (exemple VGA Standard, SPICE, VirtIO-GPU) ;

- un chipset émulé (I440fx, q35) ;

- un BIOS (SeaBIOS BIOS x86 opensource, OVMF(UEFI) ;

- un contrôleur SCSI.

Les options par défaut conviendront. Ne les modifiez pas à moins de savoir ce que vous faites.

Vous pourrez cocher la case agent TPM et surtout la case agent Qemu pour les additions invitées.

8-2-4 - Disque

Sur l‘écran suivant, nous allons créer un disque virtuel.

Vous verrez que par défaut, un bus IDE nommé ide0 est mis à disposition. Il est possible d’ajouter un autre BUS en cliquant sur « ajouter » en bas à gauche. Vous pouvez sélectionner le numéro de périphérique sur le bus. Le menu déroulant « stockage » permet de changer le datastore où sera stockée l’image disque. Vous pourrez ensuite allouer la taille de votre choix.

Une case émulation de SSD est présente, à cocher en cas d’utilisation de disques physiques SSD.

VirtIO va permettre d’améliorer les performances si vous utilisez un pilote VirtIO dans la VM. Il s’agit d’une option pour la paravirtualisation.

Si vous utilisez un stockage local, vous pourrez choisir le format de l’image disque : qcow2, le format Qemu (le format de l'hyperviseur KVM), RAW ou VMDK (le format utilisé par VMWare).

Vous pourrez aussi activer ou non le cache avec les avantages/inconvénients inhérents.

8-2-5 - Processeur

Nous avons ensuite accès aux réglages CPU (nombre de cœurs, socket, type). Vous pourrez sélectionner le nombre de cœurs à affecter à la VM, le type de CPU (si vous ne savez pas, utilisez « host »). Ne modifiez les flags CPU que si vous savez ce que vous faites.

L’option d’émulation NUMA permet l’ajout à chaud de CPU et de RAM si votre système est compatible.

8-2-6 - Mémoire

L’écran suivant permettra de choisir la taille mémoire :

Le « memory ballooning », nommé élasticité mémoire dans l’interface, permet la modification à chaud de la RAM allouée d’une VM. Quand une VM n’utilise pas l’intégralité de la RAM à sa disposition, la partie non utilisée peut être affectée à d’autres VM grâce à cette option. Le pilote VirtIO Ballon Driver doit être installé dans la VM par le biais des additions invitées.

8-2-7 - Réseau

L’écran suivant concernera les réglages réseau. Vous pourrez paramétrer la première carte réseau ou cocher « aucun périphérique réseau ». Vous pourrez choisir parmi les modèles :

- Intel E1000 : compatibilité maximale ;

- VirtIO (paravirtualisé) ;

- Realtek RTL8139 (carte réseau faisant référence) ;

- VMWare vmxnet3.

En cas d’utilisation de VLAN, vous pouvez positionner un tag.

La case « déconnecter » simule une carte réseau déconnectée.

Vous pourrez ajouter d’autres cartes réseau post-installation.

Seul le mode pont est disponible. Pas de mode NAT ou de mode réseau interne comme sur VirtualBox ou VMWare Workstation. Mais cela est logique, Proxmox étant censé être utilisé en Bare Metal.

Rappel : il est nécessaire d'avoir au moins un bridge ou un périphérique bond comme vu précédemment pour pouvoir faire du réseau avec les VM.

8-2-8 - Confirmation

Vous aurez ensuite l’écran de confirmation donnant un récapitulatif de la configuration de la VM :

Vous pourrez alors modifier ceux-ci en retournant sur les différents écrans en cliquant sur les onglets (la configuration sera modifiable également après création de la VM).

Vous pouvez démarrer la VM immédiatement après création en cochant « Démarrer après création ».

Une fois la VM créée, elle apparaîtra après quelques secondes dans la partie gauche de l’interface d’administration. Vous verrez son tableau de bord dans la partie droite en la sélectionnant :

De ce tableau de bord, vous pourrez démarrer ou arrêter la VM depuis les icônes en haut à droite (la supprimer en entrant dans le sous-menu plus), modifier ses paramètres dans le menu matériel, gérer les snapshots, les réplications et les sauvegardes. Ces fonctionnalités seront détaillées plus tard).

L’onglet « options » permettra notamment de :

- démarrer la VM au démarrage de l’hyperviseur ;

- changer l’ordre des périphériques de boot ;

- gérer la prise en compte de l’heure de l’hyperviseur.

La liste est non exhaustive, consultez les différentes options disponibles. La plupart du temps, il n’y aura rien à modifier.

Pour un stockage local, la ou les images disques de la VM (donc plusieurs disques virtuels dans la VM) se trouveront dans /var/lib/vz/images/[id VM]/*.qcow2, .raw ou .vmdk si vous avez choisi de créer un disque au format VMWare.

Si vous avez installé Proxmox depuis l'ISO ou si vous utilisez un stockage LVM, chaque image disque sera un volume LVM. Les différents volumes seront visibles dans /dev/mapper (exemple pour ma VM de test ayant pour id 100 : /dev/mapper/pve-vm--100--disk--0) ou dans le menu des disques.

Le fichier de définition (au format XML) de la VM se trouvera dans /etc/pve/qemu-server/[id VM].conf.

8-3 - Démarrage de la VM créée

Il n’y a pas de réel écran sur une machine virtuelle. Le contenu de l’écran virtuel est affiché au travers d’un serveur VNC. Promox propose par défaut un client VNC écrit en JavaScript et donc à utiliser dans un navigateur et nommé noVNC. Proxmox propose en alternative SPICE et Xterm.js, qui sont un terminal dans un navigateur. La suite présente l’usage de noVNC.

Pour la démarrer, il suffit de se placer sur la VM apparaissant à gauche et de cliquer bouton de droite « démarrer » :

Vous pourrez aussi la démarrer en cliquant « démarrer » en haut à gauche une fois la VM sélectionnée :

Une fois celle-ci démarrée, vous pourrez voir son contenu, sa console, en cliquant « console » et lançant noVNC.

Ceci va ouvrir la console de la VM dans une fenêtre secondaire du navigateur :

En cliquant sur la flèche grise à gauche, vous aurez les options VNC :

Ci-dessous les options proposées :

- Touches supplémentaires

- touche Contrôle,

- touche Alt,

- touche Windows,

- touche tabulation,

- touche échap,

- envoi du combo Contrôle – Alt – Suppr ;

- mode plein écran ;

- paramètres, va ouvrir la fenêtre ci-dessous :

- Le mode mise à l’échelle permet d’adapter l’image lors de l’agrandissement de la fenêtre.
L’option « Afficher uniquement » bloque les interactions clavier-souris et ne fait qu’afficher l’écran de la VM ;

- commandes :

- Start : démarrage de la VM si elle est éteinte,

- Arrêter : arrêt ACPI de la VM, équivalent à une extinction par le menu démarrer sous Windows,

- Hard stop : équivalent à un arrêt de l’alimentation sur une machine physique,

- Hard reset : même effet que l’appui sur la touche reset d’une tour,

- Suspend : mise en pause, la VM est figée

Si le serveur est éteint ou redémarré, une VM suspendue est éteinte.

- Resume : reprise après pause,

- Reload VNC : recharge VNC.

Ces options sont également partiellement disponibles dans le menu Arrêter en haut juste à côté de démarrer dans la fenêtre NoVNC.

8-4 - Additions invitées

Les additions invitées sont des pilotes de périphériques à installer dans la VM concernée de façon à optimiser leur fonctionnement. Les additions invitées vont également apporter des fonctionnalités telles que le glisser-déplacer ou la fonction de dossier partagé entre l’hôte et la VM. Ce sont des fonctions présentes dans les hyperviseurs de type 2. Il s’agit donc de paravirtualisation. Les autres hyperviseurs ont en général ces fonctionnalités.

Pour installer les additions invitées, sous Windows, il vous faudra télécharger l’ISO « Windows VirtIO Driver» et l’installer dans la VM.

La version des pilotes VirtIO fournie dans le lien ne prend pas en charge Windows 7, obsolète, il faudra pour ce cas de figure rechercher une version plus ancienne.

Sous une VM Linux, il vous faudra installer le paquet qemu-guest-agent.

Pour les bases Debian :

apt install qemu-guest-agent

Pour les bases Fedora :

yum install qemu-guest-agent
# urpmi install devrait fonctionner également

Je vais présenter ci-dessous l’installation dans une VM Windows 8.

Comme déjà vu aux chapitres précédents, il vous faudra tout d’abord charger l’ISO dans un datastore disponible.

Il faudra ensuite lier cet ISO au CD-ROM virtuel de la VM. Nous allons à cet effet aller dans le menu de la VM, onglet « Matériel » :

Puis en cliquant dessus, sélectionner l’ISO à monter :

Une fois l’option enregistrée, le CD virtuel sera immédiatement disponible dans la VM. Les additions invitées s’installent comme n’importe quelle application en lançant le setup :

9 - Utilisation d’une VM

Nous avons vu dans le chapitre précédent comment créer une VM et la démarrer. Ce chapitre va concerner les manipulations de contrôle de la VM pendant sa durée de vie.

Je vais commencer par évoquer l’utilisation d’un CD-Rom ou d’une clef USB.

9-1 - Montage d’un CD-ROM

Nous avons déjà vu cette opération lors de la création de la VM. Pour rappel, il est possible de monter un ISO ou de directement utiliser le lecteur CD de l’hôte. Il est possible également d’ajouter un lecteur CD virtuel supplémentaire depuis l’onglet matériel.

9-2 - Insertion d’une clef USB connectée à l’hôte

Pour utiliser une clef ou un disque USB installé dans l’hôte, il faudra aller dans les options « matériel » de la VM et sélectionner « Ajouter un périphérique USB » :

Il faudra ensuite sélectionner le périphérique USB après avoir coché « Utiliser le port USB » :

La clef apparaîtra automatiquement dans la VM.

Après avoir éjecté la clef dans la VM, il faudra la retirer des réglages de celle-ci sauf si vous souhaitez la remonter prochainement.

Dans le cas où vous la laissez, lors de la prochaine insertion du périphérique sur l’hôte, celui-ci sera remonté dans la VM.

Si vous connectez ensuite le périphérique sur un autre port USB de l’hôte, celui-ci ne montera pas dans la VM même si le lien a été laissé, vu que la connexion est liée au numéro sur le BUS USB, 2-1 dans l’exemple ci-dessus.

9-3 - Accès au réseau

Avec la configuration par défaut, si la VM comporte une carte réseau avec l’option « déconnecter » décochée, la VM aura accès au réseau comme n’importe quelle machine du réseau.

En cas de configuration réseau personnalisée (comme l’utilisation de VLAN par exemple), l’accès aux autres machines du réseau sera possible en conséquence des réglages présents.

9-4 - Accès au BIOS de la VM

Proxmox est fourni avec un BIOS SeaBIOS, une implémentation de BIOS x86 opensource.

Il ne vous est cependant pas possible d’accéder au menu de celui-ci comme avec VirtualBox par exemple.

Au démarrage d’une VM, vous pourrez sélectionner le média de démarrage en appuyant sur la touche « echap » :

9-5 - Machine en UEFI

Pour utiliser l’UEFI, il faut utiliser le BIOS « OVMF » (UEFI) au lieu de SeaBIOS :

Vous aurez un message d’avertissement demandant l’ajout d’un disque UEFI :

L’ajout de ce disque UEFI se fera dans l’onglet matériel.

Contrairement à SeaBIOS, en UEFI, vous pourrez accéder au menu du BIOS UEFI :

Les options se limitent cependant à la gestion du volume de démarrage et aux options de Secureboot, qui ne seront pas traitées ici : le secureboot ayant été désactivé sur l’hôte.

10 - Modification des réglages d'une VM

Il s’agit ici de modifier les réglages tels que le démarrage automatique, le disque de démarrage en cas de présence de plusieurs disques virtuels, mais aussi des réglages du matériel virtuel (ajout ou suppression de composants, taille de la RAM, type de CPU et nombre de cœurs).

Pour changer les réglages d’une VM, il vous faudra cliquer dessus dans la partie gauche, puis sélectionner « matériel » à droite ; comme nous l’avons vu pour insérer un CD-ROM :

Un double-clic sur l’élément à modifier vous donnera accès aux réglages de celui-ci.

Vous pouvez ajouter un composant. Les composants disponibles sont :

- disque dur : permet d’ajouter des disques virtuels à une VM ;

- lecteur CD : permet de monter un fichier ISO ou utiliser le lecteur de l’hôte (déjà utilisé pour l’installation de VM et l’installation des additions invitées) ;

- carte réseau : permet d’ajouter des cartes réseaux ;

- disque EFI : utilisé pour le secureboot ;

- état TPM : pour ajouter un TPM virtuel (version 1.2 et 2.00 disponible) ;

- périphérique PCI : pour lier un périphérique PCI de l’hôte à la VM ;

- port série : pour l’ajout d’un port COM virtuel comme utilisé dans le passé ;

- lecteur cloud-init : pour installer une image cloud-init, standard d'initialisation de machines virtuelles que l'on retrouve chez les fournisseurs de cloud publics ;

- périphérique audio : pour ajouter une carte son (pas de carte son par défaut) ;

- GNA VirtIO : un générateur de nombres aléatoires.

Certains réglages peuvent être modifiés à chaud, d’autres nécessiteront un redémarrage de la VM.

10-1 - Réglage/ajout de carte réseau

Dialogue permettant le réglage d’une carte réseau :

Pour ajouter ou retirer un élément, cela se passe dans la ligne au-dessus des éléments de la VM :

Rappel : certains réglages seront modifiables à chaud, mais d'autres nécessiteront l'arrêt de la VM. Exemple : la suppression d’un lecteur CD-ROM affichera celui-ci barré et sera complètement supprimé après redémarrage de la VM.

10-2 - Ajout d'un disque à la VM

Pour ajouter un disque à la VM, il faudra aller dans le menu de la machine → « matériel » :

Vous aurez alors l'écran de création de disques comme déjà vu dans la partie création d'une VM :

Vous pourrez alors voir le disque supplémentaire dans l'onglet « local-lvm » du serveur :

En cas de stockage dans l'espace de stockage local au lieu de LVM, il faudra regarder dans l'onglet « local ».

10-3 - Agrandissement d’un disque

Pour agrandir un disque, il faudra aller dans les options « Matériel » de la VM concernée, sélectionner le disque concerné, puis dans le menu en haut « action disque », cliquer sur redimensionner :

Il vous sera ensuite demandé le nombre de Giga-octets à ajouter :

Pour un conteneur, le principe sera le même, en allant dans le menu « ressource », choix « disque racine » :

Pour les VM, une fois le disque dur agrandi, il faudra agrandir la partition et le système de fichiers à l’intérieur de celle-ci. La possibilité de le faire à chaud dépendra du système d’exploitation et du système de fichiers utilisé.

Il est uniquement possible d’agrandir un disque, pas de le réduire.

10-4 - Carte son

Proxmox étant un hyperviseur de type 1, il n’a pas pour but que ses VM utilisent du son.

Les VM n’auront pas de carte son par défaut, mais il est possible d’en ajouter une. Cependant, noVNC ne permet pas d’obtenir le son émis depuis une VM (le son ne fait pas partie du protocole VNC).

Le son fonctionnera par contre avec RDP ou un logiciel de contrôle à distance tel qu’Anydesk ou noMachine.

10-5 - Mappage de périphérique PCI

Cette fonctionnalité, également appelée « PCI passthrough » permet d’affecter un périphérique de l’hôte à une VM. Ce périphérique est alors indisponible pour l’hôte, il n’est pas partagé.

Pour cela, dans les options « matériel » de la VM concernée, il faudra ajouter un périphérique PCI, vous aurez alors la liste des périphériques disponibles sur le bus PCI :

Cette fonctionnalité requiert le support et l’activation de l’IOMMU ou Intel VT-d dans votre BIOS.

11 - Gestion avancée de VM

11-1 - Clichés

Un cliché ou snapshot est une photographie à un instant T d'une VM. Après la création d'un snapshot, le ou les disque(s) de la VM est/sont figé(s) et un disque secondaire par disque présent est créé. Ce disque secondaire correspondra au delta des modifications disque effectuées après cliché par rapport au disque d’origine.

Un snapshot est dépendant des fichiers d’origine et donc inexploitable sans ceux-ci.

Le snapshot d’une VM va également intégrer une sauvegarde de l’état mémoire au moment de celui-ci. Les réglages de la VM sont également sauvegardés.

11-1-1 - Création d’un cliché

Pour faire un snapshot sous Proxmox, il faut cliquer sur la VM à gauche, puis « instantané » à droite :

Il n’y a pour le moment aucun snapshot.

La valeur « MAINTENANT » correspond à la position actuelle de la VM par rapport aux différents snapshots. Cela prendra son sens quand des snapshots seront présents.

Cliquer sur « Créer un instantané » va vous afficher la fenêtre suivante :

Vous pourrez donner un titre à votre snapshot et mettre un commentaire. « Inclure la mémoire vive » va permettre d'enregistrer en plus du disque l'état système (coché par défaut). Il est entendu par état système, l'état de la machine en cours (mémoire, état CPU). Sans celui-ci, le snapshot correspondra à l'état actuel des disques durs de la machine, comme si elle avait été arrêtée brutalement.

Pendant la prise du cliché, la VM reste fonctionnelle.

Une fois le cliché effectué, celui-ci apparaîtra dans la liste des clichés :

Les snapshots disques sont enregistrés dans des volumes logiques sous le nom snap_nom_disque_titre_snapshot, visible avec la commande lvs depuis le shell de l’hôte.

Si vous cliquez sur « éditer », vous pourrez changer le commentaire, mais surtout, vous aurez le détail des paramètres de la VM indus dans le snapshot.

Vous pourrez ensuite restaurer un état antérieur depuis un snapshot ou supprimer le snapshot de votre choix.

Annuler un snapshot va supprimer la copie des blocs modifiés depuis sa création et donc fusionner les modifications effectuées lors de la prise du snapshot avec le disque principal

Revenir à un état antérieur va annuler les modifications faites depuis le snapshot, le snapshot étant alors utilisé pour restaurer les blocs disque d'origine.

Un snapshot représentant le delta par rapport à un état initial, celui-ci va grossir au fur et à mesure des modifications effectuées dans la VM. Garder des snapshots inutiles peut saturer l'espace disque.

Après création d'un snapshot, vous pourrez voir son entrée dans le fichier de configuration .conf de la VM. Vous verrez une copie de la configuration avec quelques modifications.

11-1-2 - Restauration cliché

Cette opération consiste à revenir à l’état de la VM lors de la prise du cliché. Pour restaurer un cliché, il faudra cliquer « retour en arrière » une fois celui-ci sélectionné :

Vous aurez une demande de confirmation :

Pendant la restauration, vous perdrez la connexion VNC. Une fois la restauration effectuée, vous pourrez vous reconnecter et constater que la VM se retrouve dans l’état dans laquelle elle était lors de la prise du cliché. Si l’état matériel avait été modifié, vous retrouverez celui-ci à l’état d’origine.

Cette opération fera perdre toutes les modifications effectuées depuis la prise du cliché.

11-1-3 - Suppression de cliché

La suppression d’un cliché va fusionner ce qu’il contient dans les fichiers d’origine de la VM.

Cela se fera en cliquant sur « supprimer » à côté de « éditer ». Vous aurez également une demande de confirmation.

11-2 - Cloner une VM

Cloner une VM permet d'en faire une copie. Cette copie sera alors autonome par rapport à sa source. Celle-ci aura sa propre vie et les mêmes réglages, les mêmes données que la VM source, du moins tant qu’aucune des VM n’est modifiée.

Pour cloner une VM, il faudra cliquer sur le bouton droit sur le nom de la VM :

Vous aurez ensuite l'écran suivant :

Il vous faudra choisir le stockage cible, le nom de la VM et éventuellement le nœud si vous avez plusieurs hyperviseurs en cluster et que souhaitez effectuer la copie sur un autre nœud.

Le numéro d’id sera incrémenté.

Pendant la création du clone, la VM source reste opérationnelle et utilisable.

Ci-dessous, une copie d’écran du tableau de bord lors d’un clonage :

Le cadenas indique que la VM n’est pas utilisable, le clonage n’étant pas terminé. Le cadenas disparaîtra une fois le clonage terminé.

Attention à ne pas démarrer le clone en même temps que la VM d’origine si celle-ci héberge des services, au risque de créer des problèmes (par exemple : avec deux instances d’un contrôleur de domaine Windows).

11-3 - Créer un template

Qu'est-ce qu'un template et à quoi cela va vous servir ? Un template, aussi appelé appliance, est une VM qui servira de modèle. Cela peut être utile pour préparer un modèle de VM qui sera ensuite dupliqué.

Si vous souhaitez transformer une VM (ou un conteneur) en template, il faudra cliquer dessus avec le bouton droit et sélectionner « convertir en modèle » :

Vous aurez une demande de confirmation.

La conversion d'une VM va changer son icône en icône .

La conversion d'un conteneur va changer son icône en icône .

Quand vous accéderez à « cloner » sur cet icône, vous aurez une option différente :

Vous pourrez sélectionner deux modes :

- clonage lié : un snapshot est créé sur la VM source (le template). La VM destination utilisera son propre snapshot dépendant du disque d'origine de la VM source. Les deux VM vont avoir leur propre existence, mais la VM destination est dépendante de la VM source du fait que son disque est un snapshot de celui de la VM source ;

- clonage intégral : la VM est clonée intégralement.

On ne peut pas démarrer un template.

Vous ne pourrez pas transformer une VM en template si celle-ci contient des clichés et si elle est démarrée.

Vous ne pourrez pas désactiver la fonction template d'une VM depuis l'interface graphique. Cela reste possible en positionnant manuellement la valeur template à zéro dans le fichier de configuration de la VM. Cela sera ensuite visible dans l’interface graphique après rafraîchissement.

Bien que la sortie du mode template ne devrait pas poser de problème avec les machines clonées en mode clone lié, ceci n'a pas été testé, donc prudence.

12 - Création d’un conteneur

La gestion des conteneurs avec Proxmox s’appuie sur LXC.

Il aurait été pertinent d’intégrer la gestion de Docker, qui est devenu la référence en matière de conteneurisation. Mais rien ne vous empêche d’utiliser Docker à partir d’une VM plutôt que LXC. Vous ne pourrez par contre pas les piloter depuis l’interface Proxmox.

Docker s’appuie sur LXC et a des fonctionnalités plus poussées, LXC reste une solution utilisable.

12-1 - Prérequis : un modèle de conteneurs

Avant de pouvoir créer un conteneur, il vous faut un modèle, appelé template, qui servira de modèle.

L’accès aux templates mis à disposition se fait par le clic sur le datastore les contenant, local(srv1) dans notre cas de figure-→ modèle de conteneurs :

Vous pourrez en récupérer en cliquant sur « modèles ».

Les templates proposés sont divisés en trois sections :

- la section mail ;

- la section system ;

- la section turnkeylinux.

Les templates « turnkeylinux » ne sont pas visibles sur l’écran ci-dessus, sauf à cliquer sur le « – » à côté de « section: system » pour réduire l’arborescence system.

La section « mail » va contenir deux versions du conteneur Proxmox mail gateway, autre produit proposé par Proxmox.

La section « system » va contenir des images pour la plupart des distributions Linux principales (Ubuntu, Debian, Fedora, Archlinux, ainsi que Alpine Linux, distribution très légère servant souvent de base aux conteneurs Docker).

La section « turnkeylinux » va contenir des images telles que Owncloud, Prestashop, NodeJS, c'est-à-dire des templates avec des services prêts à être utilisés. TurnKey Linuxdésigne une bibliothèque d’appliances

Les templates téléchargés seront stockés dans /var/lib/vz/template/cache ou dans le dossier template/cache de l'espace de stockage.

Si vous avez votre propre template au format tar.xz, celui-ci sera téléversable en cliquant sur « Téléversez », vous pouvez également télécharger un template depuis une URL en cliquant sur « Télécharger depuis l’URL ».

Une fois le template téléchargé, vous pourrez le voir et éventuellement le supprimer depuis l'espace de stockage local → contenu, dans la section « Templates de conteneurs » :

Si vous n’avez pas de section « turnKeyLinux », lancez la commande suivante dans un shell du serveur Proxmox :

pveam update

12-2 - Création d’un conteneur

La création du conteneur se fera par le clic en haut à droite à côté de créer VM.

12-2-1 - 1er écran

Dans le premier écran, il vous faudra sélectionner :

- le nœud de destination s’il y a plusieurs serveurs ;

- le nom du conteneur ;

- son mot de passe ;

- éventuellement une clef SSH.

Laisser coché « Conteneur non privilégié » est recommandé en matière de sécurité. Avec cette option, l’UUID 0 dans le conteneur est mappé à un UUID user hors du conteneur et n’a donc pas les privilèges root au niveau hôte.

L’option « imbriqué » monte les pseudo dossiers /proc et /sys en lecture/écriture plutôt qu’en lecture seule dans le conteneur.

12-2-2 - Modèle

Sur le second écran, vous pourrez sectionner le datastore où stocker votre conteneur, et vous devrez sélectionner le modèle qu’il vous aura fallu charger auparavant comme vu précédemment.

Le menu déroulant permet de sélectionner le datastore (un seul dans notre cas de figure) :

12-2-3 - Disque

Vous pourrez ensuite gérer les disques du conteneur :

12-2-4 - Processeur

Vous sélectionnerez enfin le nombre de cœurs affectés au conteneur :

Modifier les options en dessous du nombre de cœurs permettra de limiter l’utilisation CPU du conteneur. Les cœurs sélectionnés pourront être utilisés par d’autres processus, VM et/ou conteneurs.

12-2-5 - Mémoire

L’écran suivant permettra de déterminer la mémoire dédiée au conteneur ainsi que son swap :

12-2-6 - Réseau

L’écran suivant concernera le réseau :

Le champ « nom » détermine le nom de l’interface vue depuis le conteneur. Les autres réglages réseau sont semblables à ceux applicables à une VM.

Les DNS sont à régler dans l’écran suivant, positionné par défaut sur les valeurs de l’hôte :

12-2-7 - Finalisation

Vous aurez ensuite l’écran de résumé, avec une case permettant le démarrage du conteneur juste après sa création :

Si un élément n’est pas correct, il suffit de cliquer sur l’onglet concerné afin d‘effectuer la modification.

Voici un exemple des logs produites lors de la création d’un conteneur :

Une fois le conteneur créé, il apparaît et il est manipulable comme une VM.

Le disque du conteneur se trouvera dans l'espace de stockage dans le dossier images/[id conteneur]/vm-disk-[id].raw.

Le fichier de configuration se trouvera dans /etc/pve/lxc/[id].conf.

Une fois le conteneur démarré, il faudra y accéder soit en SSH, soit avec « XtermJS » ou « NoVNC » depuis le menu console, comme pour les VM.

13 - Sauvegarde

Pour sauvegarder une VM ou un conteneur, il faut cliquer sur celui-ci/celle-ci, puis sélectionner « Sauvegarder » dans le menu de droite :

Tout à droite, vous pourrez sélectionner le datastore ou stocker votre sauvegarde.

« Sauvegarder maintenant » déclenchera une sauvegarde immédiate.

Ceci peut se faire à chaud ou à froid. Une fois la sauvegarde effectuée, celle-ci apparaîtra dans le menu. Le clic sur « Restaurer » permettra la restauration de la sauvegarde.

Vous aurez accès aux options suivantes :

Vous pourrez sélectionner le datastore, le type de compression ou encore, ajouter une note.

Cocher « protégé » empêchera la suppression de la sauvegarde. Ceci étant réversible, je vous conseille de le cocher systématiquement.

Le déclenchement d’une sauvegarde n’interrompt pas le fonctionnement de la VM.

Vous serez notifié par mail de l’aboutissement de la sauvegarde si vous avez indiqué une adresse.

Une fois la sauvegarde effectuée, elle apparaîtra dans la liste :

Le bouclier juste avant la date indique le verrou de la sauvegarde, empêchant sa suppression.

Cliquer sur « modifier la protection » au-dessus, désactivera le verrou et permettra l’accès à la suppression.

Les sauvegardes sont stockées dans le dossier dump de l'espace de stockage sélectionné sous forme de fichiers .tar.lzo pour les conteneurs et .vma.zst (ou .vma.lzo par exemple) pour les VM (le format vma est un format propriétaire de Proxmox).

Le format du nom de fichier est vzdump-[lxc/qemu]-[id VM/conteneur]-[date],[vma/tar].lzt.

Gardez à l'esprit qu'il vous reste possible de faire une sauvegarde directement depuis la VM comme vous le feriez avec une machine réelle.

Cumuler les deux vous assurera une protection supplémentaire. Vous pouvez aussi alterner par exemple jours pairs : sauvegarde depuis la VM, jours impairs : sauvegarde par Proxmox.

Il faut également bien penser à stocker les sauvegardes hors du serveur, ou en faire sur le serveur et hors de celui-ci.

13-1 - Sauvegarde sur support externe

Pour faire une sauvegarde sur un support externe, il va falloir que le volume soit monté dans un point de montage.

Ce point de montage devra être mis à disposition dans les stockages Proxmox en créant un espace de stockage dans le dossier correspondant au point de montage, comme vu dans le chapitre sur les espaces de stockage.

Le fait que le support soit externe n'aura, à ce stade, pas d'importance.

Dans le cas de sauvegardes planifiées sur point de montage pointant sur un support externe, il faut avoir à l'esprit qu'en cas de non-montage de celui-ci, la sauvegarde se fera dans le dossier supportant le point de montage, pouvant ainsi saturer le disque contenant ce dossier.

13-2 - Planification des sauvegardes

La sauvegarde que nous avons vue ci-dessus concerne le déclenchement d’une sauvegarde ponctuelle. Pour planifier des sauvegardes, il faudra se rendre dans « datacenter » → « sauvegardes » :

Vous créerez alors un job de sauvegarde en cliquant sur « ajouter ».

Vous aurez alors un écran avec les réglages semblables à ceux d’une sauvegarde ponctuelle.

Il vous faudra alors cocher les VM ou conteneurs à sauvegarder, ainsi que la fréquence de sauvegarde :

Avant de valider la tâche, vous pourrez passer sur l’écran « rétention » vous permettant de gérer les sauvegardes conservées :

Ci-dessous l’écran avec la tâche créée :

Vous pourrez lancer la tâche au moment de votre choix en cliquant « lancer maintenant », et modifier les réglages de rétention en cliquant sur « Editer ».

Les sauvegardes effectuées seront disponibles dans le datastore concerné :

13-3 - Sauvegardes incrémentales

Les sauvegardes incrémentales ne sont pas gérées au sein de Proxmox. Les sauvegardes sont donc toujours complètes. Toutefois, il existe une solution pour répondre à cet usage, disponible sous la forme d’un produit annexe ; Proxmox Backup Server, produit que nous étudierons ultérieurement..

13-4 - Restauration

Pour restaurer une sauvegarde antérieure d’une VM, il faudra cliquer sur « Restaurer » depuis le menu de celle-ci :

Vous ne pourrez changer aucun réglage :

Pour restaurer une machine non présente, il faudra aller dans le datastore contenant la sauvegarde, onglet « sauvegarde », puis restaurer. Exemple ci-dessous avec le conteneur numéro 101 :

13-5 - Proxmox Backup Server

Proxmox fournit en plus de Proxmox Virtual Environnement (Proxmox VE) un produit nommé Proxmox Backup Server.

La version disponible et utilisée au moment de la rédaction de ce tutoriel est la version 3.2.

Proxmox Backup Server permet de faire des sauvegardes incrémentales et gère la déduplication (technique permettant de stocker les blocs de fichiers non modifiés une seule fois dans une sauvegarde incrémentale).

13-5-1 - Installation depuis ISO

L’installation du produit est semblable à l’installation de Proxmox VE :

Proxmox requiert un datastore sur un disque autonome pour les sauvegardes, je vous recommande donc d’installer le système sur un support tel qu’une carte SD ou sur un tout petit disque, et de réserver un disque pour les sauvegardes.

Créer juste une partition pour le système ne suffira pas, le reste du disque ne sera pas visible pour Proxmox Backup.

Une fois l’installation effectuée, l’accès se fera via le port 8007 :

13-5-2 - Installation sur système existant

Comme pour Proxmox VE, il faudra commencer par fixer un nom d’hôte dans les fichiers hosts et hostname.

Il faudra ensuite récupérer la clef du dépôt :

wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg

Puis l’installer :

apt-key add proxmox-release-bookworm.gpg
mv proxmox-release-bookworm.gpg /etc/apt/trusted.gpg.d

Et enfin ajouter le dépôt dans le fichier /etc/apt/sources.list :

deb http://download.proxmox.com/debian/pbs bookworm pbs-no-subscription

Nous installons ensuite les paquets nécessaires :

apt update
apt install proxmox-backup

13-5-3 - Ajout d’un datastore sur le serveur de sauvegarde ProxMox

Nous commençons par créer le datastore sur le serveur de sauvegarde en allant dans le menu « Administration » → « stockages et disque » :

Nous allons créer notre datastore dans un répertoire sur un point de montage sur le disque disponible /dev/sdb.

Après clic sur répertoire → « Créer : Directory », nous aurons la boite de dialogue suivante.

Je choisis un formatage en ext4 avec le nom backup. La case cochée déclenchera la création automatique du datastore (même principe qu’avec Proxmox Virtual Environnement) :

Comme nous pouvons le voir sur l’écran ci-dessous, le datastore est monté dans /mnt/datastore/backup :

Nous pourrons ensuite voir notre nouveau datastore dans la partie « entrepôt de données » :

Vous aurez besoin de récupérer l’empreinte du datastore pour le connecter aux hyperviseurs. L’empreinte sera disponible en cliquant sur « show connection information » (sous résumé) :

13-5-4 - Ajout d’un datastore de sauvegarde aux serveurs à sauvegarder

La prochaine étape nécessaire sera d’intégrer le datastore des sauvegardes aux hyperviseurs Proxmox.

Il faudra pour cela, depuis un hyperviseur, aller dans « centre de données » → « stockage » → « ajouter » et sélectionner « Proxmox Backup Server » :

Il vous sera demandé :

- un identifiant ;

- une adresse IP ou un nom d’hôte ;

- un nom d’utilisateur et un mot de passe ;

- le nom du datastore ;

- l’empreinte de celui-ci.

Le nouveau datastore sera ensuite visible sur tous les nœuds du cluster (notion que nous verrons au chapitre 15).

Une fois le datastore de Proxmox Backup Server paramétré, les sauvegardes se feront depuis le menu « Sauvegarde » tout comme sans serveur de sauvegarde.

13-5-5 - Visualisation des sauvegardes

Les sauvegardes seront ensuite visibles soit de la même façon que vu précédemment depuis le nom de la machine, puis « sauvegarde » :

Soit depuis le datastore du serveur de sauvegarde où vous aurez une option de plus : la restauration de fichiers :

En cliquant dessus, vous pourrez sélectionner un fichier ou un dossier à télécharger depuis l’arborescence (valide pour les machines Linux et Windows) :

Les dossiers 1 et 2 correspondent aux différentes partitions.

En cas de sélection d’un dossier, son contenu sera téléchargé en .zip ou .tar.zst, selon votre choix.

Les fichiers .zst, peuvent être ouvert sous Linux avec la commande unzstd incluse dans le paquet zstd et sous Windows avec https://github.com/facebook/zstd/releases/download/v1.5.5/zstd-v1.5.5-win32.zip

13-5-6 - Visualisation depuis Proxmox Backup Server

Les sauvegardes seront visibles dans le datastore sur l’interface de Proxmox Backup Server :

Vous pouvez voir les différentes versions de sauvegardes incrémentielles.

Pour les systèmes Linux, il est possible d’accéder au contenu de celle-ci en cliquant sur le symbole dossier à côté (au niveau du fichier root.pxar.didx dans l’exemple) :

Contrairement à l’accès depuis l’un des hyperviseurs, il ne sera pas possible de télécharger le contenu des machines virtuelles. Vous pourrez télécharger l’image disque complète dans un fichier .img.

Pour les conteneurs, vous pourrez sauvegarder un dossier complet de celui-ci en plus de télécharger son image disque.

14 - Import/export de VM

Dans le domaine de la virtualisation, il existe un format standard d’import/export, le format .ova pour Open Virtualisation Alliance.

Les fichiers .ova peuvent aussi servir pour déployer une machine virtuelle toute prête appelée également Appliance. Ce format permet en théorie de faire des imports/exports entre hyperviseurs différents supportant ce format.

Un fichier .ova est en fait un fichier au format tar, contenant :

- un fichier .ovf (Open Virtualisation Format), un fichier XML décrivant l'aspect matériel de la VM (on y retrouvera les noms et UUID des disques virtuels, la taille de RAM, le nombre de CPU, toute la définition de la machine virtuelle) ;

- un fichier image disque au format vmdk par disque virtuel ;

- un fichier manifeste .mf contenant les hash des différents fichiers.

L'opération d'import/export ne fonctionnera pas tout le temps, notamment en cas d'hyperviseur différent. Il n'y a rien d'étonnant à cela, en cas d'import sur un hyperviseur différent de l'original, vous pourrez vous retrouver sur une machine ne possédant pas le même nombre de cœurs, la même quantité de mémoire, les mêmes extensions de virtualisation (extensions IOMMU, PCI passthough possibilité assez récente et peu utilisée pour le moment, etc.), voire la même architecture de CPU.

Il est possible de lire le fichier .ovf et de comprendre ces valeurs (celui-ci étant en format XML), après désarchivage du fichier .ova, afin de créer une machine virtuelle au plus proche de la configuration d'origine. Il pourra être nécessaire de convertir les fichiers images disque dans un format connu par l'hyperviseur, puis de lier les images à la machine virtuelle.

Il faut garder à l'esprit que la VM verra une « carte mère » différente (sauf en cas d'hyperviseur identique). Des réglages dans l'OS virtualisé pourront être nécessaires et notamment les réglages réseau, d'autant plus en cas d'utilisation de vSwitch.

Les activations de logiciels basés sur le matériel pourront être invalidées.

Dans la machine virtuelle, il faudra également désinstaller les additions invitées de l'hyperviseur d'origine et installer celles de l'hyperviseur en cours.

14-1 - Import d'une VM au format OVA

Vous ne pourrez pas importer directement une appliance au format .ova depuis l’interface de Proxmox.

Il vous faudra commencer par télécharger le fichier .ova sur le serveur et décompacter l'archive tar (ou télécharger directement le contenu de celle-ci).

~# tar -xvf fichier.ova

Il existe une commande permettant l'import d'un fichier .ovf :

~# qm importovf <vmid> <fichier ovf> <datastore>

Exemple avec une appliance Alpine Linux exportée depuis VirtualBox, fichier .ova préalablement désarchivé :

~# qm importovf 110 alpine.ovf local-lvm
warning: unable to parse the VM name in this OVF manifest, generating a default value

transferred 1.5 GiB of 50.0 GiB (3.00%)
transferred 2.0 GiB of 50.0 GiB (4.00%)
transferred 2.5 GiB of 50.0 GiB (5.00%)

...

root@proxmox:~#

Une autre commande qm permet l'importation de disques :

~# qm importdisk <vmid> <source> <datastore> <option>

L'import dans un datastore LVM créera automatiquement le volume logique LVM contenant les données du disque virtuel.

qm ne gère que les formats raw, vmdk et qcow2. En cas de format différent, il faudra passer par qemu-img que nous verrons dans la partie export, ou passer par un produit tiers.

Les réglages de carte réseau seront à revoir (sélection de la carte ou du bridge intégré à votre hôte).

Une fois l'opération effectuée, la machine virtuelle démarre sans difficulté.

14-2 - Import depuis VMWare

Proxmox vient de récemment intégrer un assistant pour importer des VM depuis VMWare ESXi.

Pour cela, il vous faudra intégrer le datastore de l’ESXi dans Proxmox depuis le menu :

Il vous faudra entrer les informations de connexion (IP, nom d’utilisateur, mot de passe) :

Une fois connecté au datastore VMWare, vous pourrez voir les VM présentes et les importer :

14-3 - Alternative

Il existe une commande nommée virt-v2v contenue dans le paquet libguestfs qui permet de faciliter l'import de VM vers l'hyperviseur KVM. virvt-v2v s’appuie sur l'API libvirt qui permet de contrôler en ligne de commande les hyperviseurs les plus répandus.

14-4 - Export

La commande qm que nous avons utilisée pour importer un fichier .ovf ne permet pas l'export.

De façon à pouvoir exporter une VM, il va falloir :

- exporter les disques ;

- récupérer la définition de la VM.

L'export des disques pourra être fait avec la commande qemu qemu-img sous la forme :

qemu-img convert -f qcow2 -O vmdk source.qcow2 destination.vmdk

qemu-img gère les formats raw, vmdk, vdi, vhd.

Le format vmdk de VMWare sera le plus supporté.

Vous pouvez récupérer le fichier de définition de la VM dans /etc/pve/qemu-server/[id_vm].conf, qui contient les différents réglages de celle-ci et qui vous servira à créer la définition d'une nouvelle VM dans un autre hyperviseur que KVM.

15 - Gestion d'un datacenter

Proxmox utilise la notion de datacenter, dans lequel vous avez un ou plusieurs hyperviseurs.

Dans le cas de présence d'au moins deux hyperviseurs, pour avoir une interface commune de gestion, il va falloir créer un cluster depuis l’un des nœuds, puis intégrer les autres nœuds à celui-ci.

La configuration sera alors partagée entre tous les nœuds. Les hyperviseurs restant autonomes pour leurs VM/conteneurs et leurs espaces de stockage locaux.

Il sera possible depuis n'importe quelle interface Web des hyperviseurs de gérer les VM et les conteneurs (démarrage, arrêt, modification, suppression, etc.), des espaces de stockage du datacenter, quel que soit leur emplacement dans le cluster.

Lors de création de VM, de conteneurs ou d'espace de stockage, le nœud sera à choisir.

15-1 - Création d'un cluster

Un cluster est un groupement de machines dédié à une tache. Cet ensemble peut être consacré au calcul, à la fourniture d’un système de fichiers distribué ou à la fourniture d’une base de données distribuée. Dans le cadre d’un datacenter, il s’agira de l’ensemble des machines participant à celui-ci.

Comme un cluster est un ensemble de machines ; nous allons préparer un hyperviseur supplémentaire.

S’il y a un décalage entre l’heure des deux serveurs, vous aurez des problèmes d’accès interserveur. Assurez-vous d’avoir les serveurs de temps (NTP) activés sur les différents hyperviseurs.

Une fois le second serveur préparé, il vous faudra aller sur « centre de données » → « Grappe de serveurs » puis « créer une grappe de serveurs » sur le premier nœud :

Il vous sera demandé le nom du cluster :

Ce sera la seule information nécessaire à la création du cluster.

Après rafraîchissement de la page, le nom de votre cluster apparaîtra entre parenthèses à côté de datacenter :

Intégrons maintenant notre second serveur après sa préparation depuis son menu centre de données → Grappe de serveurs, en cliquant sur « rejoindre la grappe de serveur »  :

Il vous sera demandé les informations d’identification que vous trouverez sur le premier nœud en cliquant sur informations de jonction (juste à droite de « créer une grappe de serveurs ») :

Il faudra copier le champ information obtenu depuis le premier serveur dans la fenêtre de demande de jonction :

Une fois le copier-coller effectué, le détail des informations s’affichera, et il vous faudra entrer le mot de passe du serveur qui va être joint :

Jonction en cours :

Nous voyons ensuite les deux serveurs dans le cluster depuis n'importe lequel des hyperviseurs (dans la liste des nœuds du menu « cluster » et dans la partie gauche) :

L’ouverture d’une console de la VM de srv1 depuis srv2 ne pose pas de problème. La fenêtre de console comportant l’adresse IP de srv2 dans l’URL démontrant que l’ouverture se fait bien depuis celui-ci. Il sera également possible de modifier les réglages d’une VM présente sur srv1 depuis srv2 et vice-versa.

Pour gérer le cluster, Proxmox utilise Corosync. Les fichiers de configuration seront partagés entre les nœuds du cluster grâce au Proxmox Cluster File System (pmxcfs).

Dans un cluster, les fichiers de configuration sont répliqués entre les nœuds de celui-ci. En cas de défaillance d'un nœud ou de perte d'accès entre nœuds, les fichiers de configuration passeront en lecture seule si le quorum (nombre de nœuds minimal de fonctionnement) n'est pas atteint pour éviter une situation de split-brain.

Vous ne pourrez pas joindre dans un cluster existant un hyperviseur contenant des machines virtuelles.

15-1-1 - Contourner l'impossibilité de joindre à un cluster un hyperviseur avec des VM

Nous allons voir dans ce chapitre comment contourner l'impossibilité d'ajouter à un cluster un hyperviseur contenant des machines virtuelles ou conteneurs. Pour cela il faudra :

- changer la numérotation des instances de façon à avoir un numéro unique d’identifiant sur le cluster, chaque hyperviseur commençant la numérotation par défaut à 100 ;

- rendre les VM ou conteneurs « invisibles » à l'hyperviseur le temps de l'intégration de celui-ci au cluster.

Il faudra vous assurer d’avoir des sauvegardes fiables avant d’effectuer les modifications présentées ci-dessous.

15-1-1-1 - Changement de VMID et renommage des disques

Chaque VM a un VMID correspondant au nom de son fichier de configuration présent dans /etc/pve/qemu-server (par exemple : le fichier 100.conf pour un VMID de 100).

Le disque dur de la VM sera nommé pour le VMID 100 vm-100-disk-0, (vm-100-disk-1 pour le second disque, etc.), suivi de l'extension .qcow (ou .raw pour les conteneurs n’utilisant pas LVM).

Nous commencerons par renommer les disques en respectant la nomenclature d'origine. Nous modifierons le fichier .conf en conséquence, puis renommerons celui-ci avec un identifiant unique. Tout ceci devra être fait VM arrêtée.

Vous trouverez le nom et le chemin des disques d'une VM en affichant son fichier de configuration. Le nom sera de la forme nom_datastore:nom_image,size=.…

La manipulation sera la même pour les conteneurs, leur configuration se trouvant dans /etc/pve/lxc.

Rappel :

La configuration des datastores et donc le chemin des images disques où le nom du Volume Group LVM se trouve dans le fichier /etc/pve/storage.cfg.

Pour renommer un volume logique, nous utiliserons la commande lvrename qui attend en paramètres le nom du Volume Group, l'ancien nom, puis le nouveau nom. Exemple  :

lvrename pve vm-100-disk-0 vm-200-disk-0

Nous renommons ici le disque vm-100-disk-0 en vm-200-disk-0 dans le but de changer l'identifiant de la VM en 200.

pve correspond au nom du Volume Group créé lors de l'installation de Proxmox depuis l'ISO. À adapter à votre cas si vous avez personnalisé l’installation.

Dans le cas de disques au format .qcow2 (ou autre), il faudra juste renommer le fichier.

Une fois les disques renommés, je change leur nom dans le fichier de configuration de la VM.

La même opération devra être faite pour les conteneurs.

15-1-1-2 - Rendre les VM « invisibles »

Pour rendre les VM invisibles à Proxmox, nous allons tout simplement déplacer les fichiers .conf de /etc/pve/qemu-server vers un autre dossier. Cela fera quasi instantanément disparaître les VM de l'interface graphique de Proxmox. Les machines virtuelles continueront de fonctionner.

Chaque machine virtuelle en cours de fonctionnement est vue comme un processus de l'hôte. Vous pouvez les voir grâce à la commande suivante :

ps -ef | grep qemu

Vous verrez tous les éléments de la configuration de la VM passés en paramètres à la commande qemu.

Une fois qu'il n'y a plus de VM visibles sur l'hyperviseur depuis l'interface Proxmox, l'ajout de celui-ci à un cluster existant se fera sans difficulté. Il suffira ensuite de replacer les fichiers de configuration des VM dans /etc/pve/qemu-server pour les voir réapparaître dans l'interface Proxmox, et les voir apparaître également sur les autres nœuds du cluster.

15-2 - Migration d’une VM

Un autre intérêt d'avoir une gestion centralisée de plusieurs hyperviseurs est la possibilité de migrer une VM ou un conteneur d'un hyperviseur à un autre, que ce soit pour des questions de maintenance ou d'équilibrage de charge.

Migrer une VM (ou un conteneur) consistera à cloner celle-ci vers un autre nœud (un autre hyperviseur du datacenter) en activant celui-ci et supprimant la VM du nœud source. Ceci peut se faire à chaud c'est-à-dire avec la VM en activité.

Proxmox refusera de migrer une VM utilisant des disques locaux attachés. Vous pourrez faire la migration en ligne de commande avec la commande :

qm migrate [id VM][destination] --online --with-local-disks

Une migration ne sera pas possible non plus si des périphériques PCI de l’hôte sont mappés sur la VM.

Pour migrer une VM, il faudra faire un clic droit sur celle-ci, puis choisir « Migrer » :

Il vous restera à sélectionner le nœud de destination :

Au bout d’un certain temps, le message « VM 100 - Migration » apparaît dans la liste des tâches, suivi d’un affichage dans le terminal :

Il est également possible d’effectuer une migration en ligne de commande avec la commande qm :

qm migrate 100 srv2 --online --with-local-disks

Les paramètres fournis dans l'exemple ci-dessus :

- 100 : identifiant de la VM ;

- srv2 : serveur de destination ;

- --online : permet la migration d'une VM active ;

- --with local-disks : permet de migrer également les disques locaux.

Exemple d’état d'une migration depuis la console :

root@srv1:~# qm migrate 100 srv2 --online --with-local-disks
2019-03-16 20:49:34 starting migration of VM 100 to node 'srv2' (192.168.1.201)
2019-03-16 20:49:36 found local disk 'local-lvm:vm-100-disk-0' (in current VM config)
2019-03-16 20:49:36 copying disk images
2019-03-16 20:49:36 starting VM 100 on remote node 'srv2'
2019-03-16 20:50:24 start remote tunnel
2019-03-16 20:50:32 ssh tunnel ver 1
2019-03-16 20:50:32 starting storage migration
2019-03-16 20:50:32 scsi0: start migration to nbd:192.168.1.201:60000:exportname=drive-scsi0
drive mirror is starting for drive-scsi0
drive-scsi0: transferred: 0 bytes remaining: 4294967296 bytes total: 4294967296 bytes progression: 0.00 % busy: 1 ready: 0
drive-scsi0: transferred: 33554432 bytes remaining: 4261412864 bytes total: 4294967296 bytes progression: 0.78 % busy: 1 ready: 0
…
drive-scsi0: transferred: 4243587072 bytes remaining: 51380224 bytes total: 4294967296 bytes progression: 98.80 % busy: 1 ready: 0
drive-scsi0: transferred: 4294967296 bytes remaining: 0 bytes total: 4294967296 bytes progression: 100.00 % busy: 1 ready: 0
all mirroring jobs are ready
2019-03-16 20:58:09 starting online/live migration on unix:/run/qemu-server/100.migrate
2019-03-16 20:58:09 migrate_set_speed: 8589934592
2019-03-16 20:58:09 migrate_set_downtime: 0.1
2019-03-16 20:58:09 set migration_caps
2019-03-16 20:58:09 set cachesize: 33554432
2019-03-16 20:58:09 start migrate command to unix:/run/qemu-server/100.migrate
2019-03-16 20:58:11 migration status: active (transferred 1178472, remaining 284626944), total 286072832)
2019-03-16 20:58:11 migration xbzrle cachesize: 33554432 transferred 0 pages 0 cachemiss 0 overflow 0
...

2019-03-16 21:00:37 migration xbzrle cachesize: 33554432 transferred 0 pages 0 cachemiss 1043 overflow 0
2019-03-16 21:00:38 migration status: active (transferred 255186967, remaining 163840), total 286072832)
2019-03-16 21:00:38 migration xbzrle cachesize: 33554432 transferred 408212 pages 438 cachemiss 1754 overflow 6
2019-03-16 21:00:41 migration speed: 0.42 MB/s - downtime 2817 ms
2019-03-16 21:00:41 migration status: completed
drive-scsi0: transferred: 4294967296 bytes remaining: 0 bytes total: 4294967296 bytes progression: 100.00 % busy: 0 ready: 1
all mirroring jobs are ready
drive-scsi0: Completing block job...
drive-scsi0: Completed successfully.
drive-scsi0: transferred: 4294967296 bytes remaining: 0 bytes total: 4294967296 bytes progression: 100.00 % busy: 1 ready: 1
all mirroring jobs are ready
drive-scsi0: Completing block job...
drive-scsi0: Block job cannot be completed, try again.
drive-scsi0: transferred: 4294967296 bytes remaining: 0 bytes total: 4294967296 bytes progression: 100.00 % busy: 1 ready: 1
all mirroring jobs are ready
drive-scsi0: Completing block job...
drive-scsi0: Block job cannot be completed, try again.
drive-scsi0: transferred: 4294967296 bytes remaining: 0 bytes total: 4294967296 bytes progression: 100.00 % busy: 1 ready: 1
all mirroring jobs are ready
drive-scsi0: Completing block job...
drive-scsi0: Block job cannot be completed, try again.
drive-scsi0 : finished

2019-03-16 21:03:07 ERROR: command '/usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=srv2' root@192.168.1.201 qm nbdstop 100' failed: exit code 255
Logical volume "vm-100-disk-0" successfully removed

Pour plus d'informations sur la commande qm, cliquez ici.

15-2-1 - Migration d’une VM de LVM vers ZFS

Migrer une machine virtuelle d’un datastore LVM vers un datastore ZFS vous donnera un message d’erreur.

Pour pallier cela, il est possible de passer par une conversion intermédiaire du ou des disques en fichier image.

Avant cela, il faudra modifier le datastore local qui par défaut ne permet que le stockage d’ISO et de modèles de conteneurs :

Pour la conversion en fichier image, il faudra aller sur l’onglet « matériel » de la VM, ou « ressource » pour un conteneur, et une fois le disque sélectionné, cliquer sur « Actions sur le volume » :

Il faudra ensuite cliquer sur « Déplacer le stockage », vous pourrez alors choisir le datastore local pour créer une image disque dans un fichier :

Si vous ne cochez pas la case « supprimer la source », celle-ci sera désactivée dans le conteneur au profit de la nouvelle image, mais non effacée. (doublon).

Le datastore doit avoir suffisamment d’espace pour stocker la taille totale de l’image disque que l’espace soit occupé par des données ou non.

Il reste possible de réduire la taille du disque logique d’origine avant intervention (non traité ici). Le temps de traitement sera proportionnel à la taille du disque.

Une fois cette opération terminée, la migration pourra être effectuée vers le second serveur, dans son datastore local.

Il restera à basculer les disques dans le datastore ZFS, de la même façon que pour la bascule LVM-→ local. Ce transfert apparaîtra quasi immédiatement.

16 - Haute disponibilité

La haute disponibilité est une notion signifiant qu'un système d'information a un taux de disponibilité proche de 100 %. Le taux de disponibilité se calcule en divisant le temps pendant lequel le système est opérationnel (la durée de disponibilité) par la durée totale durant laquelle on aurait souhaité qu'il le soit. Il est à noter qu’un temps de disponibilité de 99 % représente une immobilisation annuelle d’un peu plus de 3 jours. Ces 3 jours peuvent sembler très peu sur une année, mais peuvent être significatifs s’ils sont contigus ou partiellement contigus avec une durée significative.

Pour avoir de la haute disponibilité, il faut avoir un système redondant sans point de défaillance, un point de défaillance étant un élément non redondé mais paralysant complètement l’infrastructure.

Il faut commencer par la redondance matérielle. Au niveau des serveurs, il est possible d'avoir la redondance matérielle par :

- un onduleur ;

- une double alimentation électrique (serveur à double alimentation électrique, mais aussi deux sources d’alimentation électrique différentes) ;

- de la mémoire ECC (à correction d'erreur) ;

- un système de disques en RAID ;

- plusieurs cartes réseau montées en agrégation de liens, avec switchs redondés ;

- deux accès Internet différents en cas de présence en ligne ;

- des machines répliquées dans deux datacenters dans deux régions différentes.

Monter une redondance entre hyperviseurs va compléter ou pallier le manque de redondance matérielle. Le système de gestion de la haute disponibilité de Proxmox va permettre de gérer la perte d'un nœud sans perte d'accès aux VM ou avec une perte d'accès la plus réduite possible.

Il faut garder à l’esprit que si les hyperviseurs sont sur le même site, une simple perte de connexion réseau rendra toute l’infrastructure indisponible, et pire en cas d’incident industriel plus grave tel que la destruction du site

Le système devra être capable de détecter la perte d'un nœud hébergeant une VM ou un conteneur devant être en haute disponibilité et de passer automatiquement le relais à un autre nœud.

Le contenu des VM devra être stocké sur un espace de stockage partagé entre les hyperviseurs (NAS, SAN, FS distribué comme Ceph ou ZFS). Proxmox recommande trois nœuds minimum pour assurer le quorum.

Pour assurer la haute disponibilité, l’espace de stockage devra lui-même être hautement disponible.

En cas de perte d'un hyperviseur, un autre prendra le relais. Un système empêchera l'activation depuis deux nœuds différents ce qui pourrait être catastrophique et détruire les données par un accès concurrentiel inapproprié.

Pour utiliser la haute disponibilité, Proxmox utilise Corosync.

16-1 - Réplication

La réplication sera la base pour pouvoir faire de la haute disponibilité.

La réplication permet d'avoir une copie d'une VM (ou d’un conteneur) prête à remplacer celle en cours d’exécution en cas de problème.

L’accès à la réplication sera possible soit dans les options de la VM ou du conteneur concerné :

Soit depuis le menu du datacenter :

La différence étant qu’avec accès depuis une VM ou un conteneur, elle ou il sera présélectionné dans le menu de création du job. Restera à sélectionner un serveur de destination et la fréquence de réplication depuis la sélection possible dans le menu déroulant :

Il n’est pas possible de sélectionner n’importe quel datastore, celui-ci devant être commun entre les deux serveurs (c’est-à-dire accessible depuis les deux serveurs).

Un job de réplication sera alors créé, accessible depuis « centre de données » → « réplication », depuis l’un des serveurs → « réplication », ou depuis le menu « réplication » de la machine concernée.

Il faudra créer un job de réplication par machine à répliquer.

Vous sectionnerez :

- la VM à répliquer ;

- la destination de la réplique (target) ;

- la fréquence (toutes les 15 min, 30 min, toutes les 2 heures, chaque jour à 02:30, 22:30, les options sont en dur).

Il est possible de faire la réplication d'une VM sur plusieurs autres nœuds (une réplique par nœud, un job par réplication)

Le message suivant apparaît si votre espace de stockage n’est pas compatible avec la réplication :

Vous pourrez déclencher une réplication immédiate depuis la liste des réplications de la machine. L’option ne sera logiquement pas disponible depuis la liste des réplications niveau datacenter.

Il ne sera pas possible de migrer à chaud une VM où une réplication est activée.

Le temps de la première réplication dépendra du volume des disques à répliquer et du débit réseau disponible pour le transfert. Les réplications suivantes seront plus rapides, car elles ne prendront que le delta depuis la réplication précédente.

Il est possible de gérer les réplications en ligne de commande avec la commande pvesr.

16-2 - Activation de la haute disponibilité pour une VM

Pour activer la haute disponibilité pour une VM, il vous faudra, depuis celle-ci, cliquer sur le menu « Plus », puis « Gérer la haute disponibilité » :

Vous aurez l'écran suivant :

Éléments à renseigner :

- nombre maximal de redémarrages : nombre maximal d'essais de redémarrages après échec ;

- nombre max de déménagements : nombre maximal d'essais de déplacements après échec de démarrage ;

- groupe : sera vu dans la section suivante ;

- état de la demande : état attendu, déclenchement de traitement si l'état n'est pas adéquat :

- started : le système va tenter de garder la VM à l'état démarré,

- stopped : le système va tenter de garder la VM à l'état stoppé,

- disabled :le système va tenter de garder la VM à l'état stoppé sans tenter de déplacement,

- ignored : le système va ignorer la VM pour le traitement de la haute disponibilité.

Pour pouvoir gérer la haute disponibilité, une réplication entre deux serveurs, les volumes ZFS des nœuds concernés doivent avoir le même nom.

Si vous avez effectué une installation standard avec l’ISO, celui-ci crée par défaut un datastore nommé local-zfs et un pool ZFS nommé rpool. Cela fonctionnera avec ce nom par défaut.

Il reste possible de renommer un dataset ZFS, mais ce point ne sera pas abordé ici.

Pour que la réplication fonctionne, le quorum doit être atteint. Ce n’est pas le cas avec seulement deux nœuds, un minimum de trois nœuds est requis.

16-3 - Gestion globale de la haute disponibilité

La gestion globale de la haute disponibilité s'effectuera dans « datacenter » → « HA » (il faut descendre dans le menu) :

Dans l'écran ci-dessus, nous voyons qu'il y a un quorum (Quorum OK), que le serveur maître (master) est srv2, que le LRM (Local Ressource Manager) est actif sur srv2 et idle (en attente) sur srv2 et srv3.

La partie « Ressource » présente les VM intégrées à la gestion de la haute disponibilité. L’état du conteneur et le nœud où il se trouve sont visibles ici.

16-4 - Perte d’un nœud

J’ai simulé la perte d’un nœud en débranchant le réseau sur srv1. Après quelques instants, celui-ci a redémarré et les informations de haute disponibilité ont changé (visibles depuis srv2 et srv3) :

À ce stade, srv1 apparaît déconnecté. L’état LRM a changé pour srv1.

Au bout de quelques instants, le conteneur apparaît disponible sur srv2 :

srv2 est passé en actif et srv3 en idle au niveau du LRM.

Une fois le srv1 reconnecté, il réapparaît visible, le conteneur restant sur srv2, son LRM rebascule en idle à la place de « dead ».

Il reste possible de migrer le conteneur vers srv1 pour le remettre à son emplacement d’origine (mais vous pouvez très bien le laisser sur srv2) :

Une fois la fenêtre fermée, le conteneur réapparaît sur srv1 :

16-4-1 - Suppression définitive d’un nœud perdu

Cette opération pourra être réalisée depuis n’importe quel membre opérationnel du cluster.

Il faudra commencer par vérifier que le nœud n’est plus présent dans le cluster :

pvecm nodes

Si le nœud est présent, supprimez-le :

pvecm delnode <nom du noeud>

Il faudra ensuite supprimer le dossier nommé au nom du nœud dans /etc/pve/nodes :

rm -rf /etc/pve/nodes/<nom du noeud>

Le dossier /etc/pve étant partagé par tous les nœuds via le Proxmox Cluster Filesystem (pmxcfs), ce dossier sera supprimé sur tous les nœuds du cluster.

16-5 - Groupe de haute disponibilité

La notion de groupe va faciliter l'administration. La gestion de groupe se fera en allant dans le menu sous HA :

Ces réglages vous permettront par exemple de restreindre des VM à pouvoir se trouver sur deux serveurs parmi trois, de gérer prioritairement sur quel serveur elles doivent se trouver, de gérer les accès.

Restricted : cette option va justement servir à restreindre la présence de VM dans les nœuds sélectionnés. L'option devient une contrainte.

Nofailback : va empêcher la migration automatique vers le nœud à plus haute priorité.

Ces fonctions permettent d'affiner les réglages et d'ajouter la répartition de charge à la disponibilité garantie.

16-6 - Fencing

Le Fencing est le mécanisme permettant de s'assurer qu'une VM ne puisse pas être démarrée sur deux nœuds.

Ceci peut se présenter sous forme d'un dispositif matériel nommé watchdog. Si vous n'en avez pas, Proxmox utilisera par défaut le linux kernel softdog, un watchdog logiciel disponible en userland. Vous n’aurez dans ce cas aucune option dans le menu.

En général, un watchdog fonctionne de la façon suivante : si un compteur n'est pas mis à jour, le watchdog va déclencher une réinitialisation de la machine, ceci afin de détecter un éventuel blocage.

17 - Pool de ressources

Un pool de ressources est un regroupement logique de ressources qui va faciliter l’administration.

La création d’un pool se fera depuis le menu « centre de données » → « permissions » → « pools » :

Le pool va ensuite apparaître dans la partie gauche :

Une fois le pool créé, il sera possible d’y insérer des VM ou des datastores (dans la partie membres) :

Pour les datastores, ne seront sélectionnables que ceux du serveur sur lequel la création du pool est faite. Un datastore à base de stockage distribué, qui sera visible depuis plusieurs nœuds réglera ce problème.

Nous voyons ci-dessus que le datastore local est celui de srv2, celui de srv1 et srv3 n’apparaissant pas dans les sélections possibles.

Pour les VM ou conteneurs, vous pourrez intégrer n’importe quelle machine de n’importe quel nœud.

Vous pouvez voir ci-dessus deux conteneurs et une VM, répartis sur les trois nœuds.

17-1 - Création utilisateur

Les options de permissions peuvent être intéressantes. Vous pourrez donner des rôles prédéfinis sur des objets du pool à des utilisateurs précis pour leur déléguer l'administration de celui-ci.

Il va falloir créer l’utilisateur dans Proxmox. Pour cela il faudra aller dans « centre de données » → « Permissions » → « Utilisateurs » :

Le mot de passe devra ensuite être fixé en cliquant sur « mot de passe » :

Une fois l’utilisateur créé, il va falloir lui attribuer les droits dans le pool concerné :

Je lui attribue ici le droit PVEVMUser :

Je donne le rôle PVEVMUser à l’utilisateur « gestion ».

Dans le menu déroulant, la liste des rôles est accessible et explicitée.

Après connexion avec l’utilisateur « gestion » nouvellement créé, je peux voir qu’il n’a accès qu’au conteneur « WordPress », unique conteneur du pool dont « gestion » est membre.

Je peux arrêter le conteneur, mais je ne peux pas le supprimer ni modifier les réglages de sauvegarde ou de réplication, mon niveau de droits ne le permettant pas. Le rôle PVEVMUser permet de faire des sauvegardes sous réserve que vous ayez les droits sur les datastores concernés.

J’ai pu accéder au déclenchement d’une sauvegarde en donnant la permission d’accès sur le datastore (serveur → nom du datastore → permissions).

18 - Stockages distribués

Les stockages distribués que vous utiliserez pourront aussi bien être gérés sur les hyperviseurs (exemple : disques durs physiques utilisés en stockage distribué) qu’à l’extérieur (connexion à une baie de disques, partage NFS, etc.).

18-1 - Stockage ZFS

ZFS et un système de fichiers intégrant toutes les fonctionnalités attendues pour un FS moderne et puissant :

- intégrité des données forte ;

- gestion de volume intégré ;

- gestion de snapshots ;

- intégration de RAID logiciel ;

- ZFS over ISCSI ;

- système de copy-on-write permettant un rollback sur les données.

C’est un système de fichiers encore peu répandu par rapport à la famille ext, mais avec de puissantes fonctionnalités.

Pour créer un volume ZFS, il faudra aller dans « serveur » → « disques » → « ZFS » :

Le pool ZFS rpool visible est le pool créé par l’installation standard depuis l’ISO Proxmox.

Vous pourrez créer un volume ZFS multidisque avec support RAID ou à disque unique (RAID-0).

Choix des niveaux de RAID :

- disque unique (RAID0) ;

- mirror : RAID-1 deux disques en miroir ;

- RAID-10 : RAID 1 encapsulé dans un RAID-0 ;

- RAIDZ : RAID non standard équivalent au RAID-5 (un disque de parité) résistant à la perte d’un disque : deux disques minimum ;

- RAIDZ2 : RAID non standard équivalent au RAID-6 (deux disques de parité)  : quatre disques minimum ;

- RAIDZ3 : RAID non standard équivalent avec trois disques de parité. Cinq disques minimum ;

- dRAID : variante de ZRAID distribuant différemment les données de parité.

Les RAIDZ sont très compliqués à récupérer en cas d’incident.

La documentation officielle donne plus de précision sur ZFS.

Pour pouvoir utiliser le volume ZFS pour la réplication, il faudra lui donner le rôle de « backup » au niveau de l'espace de stockage.

Il est possible de supprimer un pool ZFS en cliquant sur le menu plus à droite après sélection du pool.

18-2 - Stockage Ceph

Ceph est une solution de stockage distribué ayant l’avantage de fonctionner sur du matériel standard. Ceph est notamment utilisé par OpenStack.

Ceph vous permettra d’avoir un espace de stockage distribué et répliqué.

Il s’agit d’un stockage en mode bloc ou objet compatible S3. CephFS est une surcouche permettant de gérer un système de fichiers par dessus Ceph.

Ceph est une architecture lourde et complexe, recommandée pour les très gros datacenters.

La présentation dans ce tutoriel sera succincte.

Pour l’exploiter, il vous faudra trois nœuds (l’espace de stockage Ceph pouvant être hors machines Proxmox) pour garantir son quorum avec au minimum un disque dur libre par nœud pour y créer des OSD (Object Storage Device dans la terminologie Ceph).

Ceph est composé de plusieurs démons, répartis sur plusieurs machines. Il est possible d'avoir plusieurs types de démons sur la même machine, mais cela n'a pas d’intérêt, car ne fournit pas de redondance et c’est même contre-productif sur un cluster important.

- Mon : monitor. Ce sont les chefs d’orchestre du cluster Ceph. S’il n'y a pas de moniteur disponible, il n'y a pas d’accès au cluster Ceph. Pour assurer la pérennité du cluster, les moniteurs doivent être sur des machines indépendantes et en nombre impair. Un minimum de trois moniteurs est recommandé.

- OSD : démon OSD (Object Storage Device). Il y a un démon OSD par volume OSD. Ce démon est en charge du stockage, de la réplication et de la redistribution des données en cas de défaillance. Il fournit les informations de monitoring aux monitors. Un serveur peut contenir plusieurs OSD, mais n’est pas recommandable sur le plan de la redondance.

- MDS : Meta Data Service. Nécessaire à l’utilisation de CephFS. Va stocker les métadonnées de tous les fichiers et permettre le support de POSIX.

- Cephfs : filesystem POSIX fourni avec Ceph et s’appuyant sur le stockage Ceph (objet ou bloc). C’est la couche de plus haut niveau.

Les paquets Ceph ne sont pas installés par défaut. Si vous cliquez sur « serveur- »→ « Ceph », leur installation vous sera proposée :

Deux versions de Ceph vous seront proposées, la 18.2 Reef et la 17.2 Quincy. Si vous n’avez pas de licence Proxmox, il faudra choisir le dépôt « sans abonnement » :

Un écran de terminal va s’ouvrir et lancer la commande apt :

Dans l’écran suivant, vous devrez sélectionner l’adresse publique (Public Network) et l’adresse privée (Cluster Network) du cluster Ceph (mis à l’identique dans l’exemple).

Le réseau public est le réseau par lequel le client Ceph va dialoguer avec le cluster, l’adresse privée est l’adresse interne de communication entre les différents démons.

Message d’installation terminée :

L’écran Ceph indique l’état du cluster, en alerte ici vu qu’il n’y a aucun OSD.

L’installation a initialisé un premier moniteur, visible dans l’onglet Moniteur :

Nous allons ensuite procéder à la création d’un OSD dans ceph → osd :

Ceph utilise une partition pour son journal qui peut être sur un autre disque (à sélectionner dans le menu déroulant disque de BDD). Il est conseillé d'utiliser des disques SSD pour les journaux pour des questions de performances.

Une option permet de chiffrer l’OSD.

Ci-dessous l’écran présentant l’OSD nouvellement créé :

À ce stade, le cluster Ceph est toujours en alerte, vu qu’il nécessite trois OSD au minimum :

Il n’est donc pas possible de créer de CephFS.

Après installation de Ceph sur le second serveur srv2, celui-ci repère bien le moniteur sur srv1 :

J’ai ensuite ajouté des OSD sur trois nœuds différents.Ci-dessous : écran avec quatre OSD présents (un sur srv1, deux sur srv2, un sur srv3) :

Le cluster est maintenant opérationnel :

Nous allons ensuite pouvoir créer le CephFS, en commençant par créer un serveur de métadonnées (MDS) :

Une fois le MDS créé, vous pourrez créer le CephFS.

L’option Placement Group (PG) permettra l’optimisation de l’autoscaling et ne sera pas abordée ici.

Nous pouvons ensuite voir la présence du CephFS  sur tous les nœuds.

Nous ajoutons un MDS et un moniteur sur srv2 pour la redondance.

18-3 - Stockage GlusterFS

GlusterFS est un système de fichiers qui permet d'être distribué, répliqué ou distribué et répliqué. Il est plus facile à gérer que Ceph , qui lui est plutôt adapté à de grosses infrastructures. GlusterFS vient se greffer dans un point de montage sur le système de fichiers local existant. Il permet de facilement « concaténer » plusieurs volumes locaux de plusieurs machines en un seul volume.

Mode distribué :

Dans ce mode, les fichiers sont répartis entre les différentes machines du volume. Il n'y a pas de redondance. Vous devez donc vous assurer de la sauvegarde des données.

Mode répliqué :

Ce mode de fonctionnement réplique les fichiers sur les différents nœuds du volume. Il s'agit là uniquement de l'aspect redondance, les fichiers ne sont pas répartis sur les différentes machines, ils sont répliqués.

Mode distribué-répliqué :

Ce mode cumule la répartition et la redondance. Chaque nœud du volume distribué est redondé sur une autre machine. Il vous faut donc au minimum X machines multiplié par deux pour un volume consistant, X représentant le nombre de nœuds répartis.

18-3-1 - Création d’un volume GlusterFS

Proxmox ne comporte pas d’interface graphique pour créer ou gérer un volume Gluster. Il vous faudra donc le créer manuellement.

Voici un exemple de création d’un GlusterFS entre srv1 et srv2.

Il faudra commencer par activer le démon glusterd sur les deux serveurs :

systemctl enable glusterd
systemctl start glusterd

Nous effectuons ensuite l’appairage depuis srv1 :

gluster peer probe srv2

peer probe: success

Création du volume :

gluster volume create mygluster srv1:/glusterfs_srv1 srv2:/glusterfs_srv2 force

volume create: mygluster: success: please start the volume to access data

Nous avons ici créé un volume nommé « mygluster » qui est composé du dossier glusterfs_srv1 sur srv1 et glusterfs_srv2 sur srv2. L’option force permet d’utiliser des dossiers à la racine.

Les métadonnées du volume sont accessibles par la commande :

gluster volume info

Qui retournera :

Volume Name: mygluster
Type: Distribute
Volume ID: f1a0859d-4835-4987-bd1c-57b1645144f3
Status: Created
Snapshot Count: 0
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: srv1:/glusterfs_srv1
Brick2: srv2:/glusterfs_srv2
Options Reconfigured:
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on

Il faudra ensuite démarrer le volume :

gluster volume start mygluster

volume start: mygluster: success

Une fois le volume démarré, nous allons pouvoir le configurer dans Proxmox depuis le menu « centre de données » → « stockage » → « ajouter » :

Il faudra ensuite renseigner les informations du cluster GlusterFS :

Celui-ci va ensuite apparaître sur tous les nœuds :

En cas de perte de nœud ou d'une brique du GlusterFS, tout le volume est resynchronisé, ce qui peut prendre beaucoup de temps sur de gros fichiers. GlusterFS n’est donc pas un datastore optimal pour gérer des VM.

En mode distribué (sans réplication), la perte d’un nœud va engendrer une perte partielle de données, celles stockées sur le nœud manquant.

Pour plus d’informations sur GlusterFS, veuillez consulter la documentation.

19 - SDN : Software Defined Networking

Le Software Defined Networking (SDN) est un système d’abstraction de la gestion du réseau.

Il permet :

- la virtualisation des ressources physiques réseau ;

- un contrôle et une gestion centralisés du réseau.

Concrètement, SDN va permettre une gestion des accès centralisée pour tous les nœuds.

Prérequis pour utiliser SDN :

Pour pouvoir utiliser SDN, chaque nœud devra contenir la ligne suivante en début de fichier /etc/network/interfaces :

source /etc/network/interfaces.d/*

Vous pourrez modifier le fichier sur chaque nœud depuis leur shell respectif disponible dans l’interface graphique de Proxmox.

Ne pas oublier de redémarrer le service réseau :

service networking restart

J’ai ensuite modifié le bridge sur chaque nœud pour qu’il puisse gérer les VLAN :

La gestion de SDN s’effectuera au niveau du datacenter :

Les parties principales vont être les zones et les V-nets.

Une zone est un conteneur qui va contenir un ou plusieurs V-nets. Les droits d’une zone vont s’appliquer à tous ses V-nets.

Une zone peut être de type :

- simple : zone limitée à un hôte

- VLAN : zone supportant les VLAN

- QinQ: ou VLAN stacking est une surcouche au VLAN permettant la gestion d’un tag réseau privé et d’un tag réseau public.

- VXLAN : Virtual Extensible LAN, permet l’encapsulation de trames de la couche 2 dans des datagrammes UDP de couche 4 sur le port 4789. Le VXLAN est un protocole remplaçant les VLAN dans le cloud computing, avec des switchs VXLAN matériels ou virtuels

- EVPN : pour Ethernet VPN, permet le transport du trafic Ethernet via MPLS ou VXLAN.

Sur des parcs standards, VLAN sera je pense le plus souvent utilisé, QinQ, VXLAN, EVPN étant utilisés dans de grosses infrastructures.

Par défaut, chaque nœud va avoir sa « localzone » :

La création d’une zone présentera le même masque quel que soit le choix de son type, je vais créer une zone VLAN :

Nous pourrons ensuite créer un V-net affecté à la zone créée avec gestion de VLAN :

Le champ « Alias » permet de mettre un nom long, le champ « nom » étant limité.

Vous pouvez voir que l’état du V-net est marqué comme « new », cela sera identique pour la zone.

Si vous retournez sur l’écran SDN, la zone nouvellement créée n’apparaît pas, il faut cliquer sur « Appliquer » pour que la zone s’active.

Ci-dessous se trouve une capture d’écran après clic sur « appliquer ». La zone va apparaître tout d’abord en mode « pending » (en attente) pour chaque nœud :

Puis apparaîtra en « available » (disponible) :

La zone apparaîtra dans la partie gauche de l’interface. Vous pourrez ensuite gérer les permissions sur cette zone. Exemple ci-dessous avec permission donnée à l’utilisateur « gestion » :

Il restera à affecter la zone SDN aux VM et conteneurs de votre choix.

Ci-dessous exemple pour la VM 102 :

20 - Supervision

La supervision consiste en la surveillance du bon fonctionnement d’un système informatique. Elle permet de déclencher des alertes en cas de problèmes.

Pour cela, il faudra surveiller le bon fonctionnement :

- du matériel : machines en état de marche, état de santé des disques durs, occupation mémoire, usage CPU ;

- du bon fonctionnement des applications : test de réponse serveur web, test d’accès au partage de fichiers.

Les tests d’installation des outils de supervision côté serveur ont été effectués depuis une distribution Debian Bookworm.

20-1 - Zabbix

Zabbix est un outil de supervision open source. Les autres produits équivalents les plus connus sont Nagios et Centreon.

Je vais présenter ici un aperçu du fonctionnement de celui-ci

20-1-1 - Installation serveur de Zabbix

L’installation sera basée sur la version 7 de Zabbix.

Zabbix fourni un .deb pour installer ses dépôts :

wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_7.0-2%2Bdebian12_all.deb

dpkg -i zabbix-release_7.0-2%2Bdebian12_all.deb

apt update

J’ai dû effacer un fichier /etc/apt/sources.list.d/zabbix-tools.list. générant un conflit.

Installation des paquets Zabbix et du serveur de base de données :

apt install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent mariadb-server

Sécurisation minimale de MariaDB :

mysql_secure_installation

Création de la base de données depuis le client MySQL :

~# mySQL

create database zabbix character set utf8mb4 collate utf8mb4_bin;
grant all on zabbix.* to zabbix@localhost identified by 'mot_de_passe';

Il est important de respecter la collation.

Nous lançons ensuite le script fourni pour publier la base :

zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix

Dans fichier /etc/zabbix/zabbix_server.conf, il faudra ensuite modifier la ligne

DBPassword=

Relance et activation du démon Zabbix  :

systemctl restart zabbix-server zabbix-agent
systemctl enable zabbix-server zabbix-agent

Relance du démon Apache :

service apache2 restart

L’accès à l’interface graphique se fera ensuite par http://IP/zabbix

Il faudra ensuite renseigner les identifiants de connexion à la base MySQL :

Restera à nommer le serveur et sélectionner le fuseau horaire :

Avec le mode sombre :

Résumé préinstallation :

Vous aurez ensuite la demande d’authentification. L’utilisateur et le mot de passe par défaut sont Admin/zabbix.

Vous aurez ensuite accès à l’interface suivante :

La première chose à faire sera de changer le mot de passe par défaut depuis « paramètre utilisateur » → « Profil » :

Le clic sur « Actualiser » effectuera une déconnexion immédiate :

Il faudra ensuite vous réauthentifier.

20-1-2 - Installation du client Zabbix sous Linux

Pour installer le client sous Linux, il faudra installer le dépôt Zabbix comme vu précédemment, puis installer le paquet zabbix-agent :

apt install zabbix-agent

Il faudra ensuite configurer le fichier /etc/zabbix/zabbix_agentd.conf.

Il faudra ajouter l’IP du serveur Zabbix sur les lignes Server, et ServerActive. Il faudra également fournir un nom de machine dans Hostname.

La ligne Server correspond au mode passif (c’est le serveur qui vient récupérer les informations), la ligne ActiveServer correspond au mode actif (le client envoie les données au serveur).

Dans ce cas de figure, les deux modes seront activés.

Une fois les modifications effectuées, il faudra redémarrer le service :

service zabbix-agent restart

Reste à intégrer la machine dans Zabbix. Pour cela, il faudra se rendre dans « Collecte de données » → « Hôtes » → « Créer un hôte » :

Dans la configuration, il faudra renseigner :

- le nom d’hôte ;

- le modèle de template (en l’occurrence Linux by Zabbix Agent) ;

- le groupe (permettant d’appliquer des fonctionnalités par groupe de machines) ;

- et enfin l’interface : agent Zabbix et adresse IP de la machine.

Vous pourrez constater la présence d’une liste conséquente de templates allant de la gestion d’onduleurs à la surveillance d’instances Apache en passant par VMWare, les services Azure, AWS, etc.

La machine apparaîtra ensuite dans la liste des hôtes :

Après quelques instants, la disponibilité passera en vert pour la machine nouvellement intégrée.

Vous pouvez voir dans l’écran ci-dessous le tableau de bord intégrant des informations sur le nouvel hôte :

Vous pouvez constater que j’ai remplacé le widget de carte géographique par le widget disponibilité de l’hôte.

20-1-3 - Installation du client Zabbix sous Windows

Le processus sera globalement le même que pour l’installation Linux.

Un installeur est fourni sur le site de Zabbix à l’adresse https://www.zabbix.com/fr/download

Pensez à bien sélectionner l'agent correspondant à la version du serveur.

Il faudra ensuite renseigner les mêmes éléments que pour le client Linux (nom d’hôte, adresse IP du serveur Zabbix) :

Avant d’intégrer la machine dans le tableau de bord Zabbix, il faudra créer un groupe pour Windows :

Vous pourrez ensuite intégrer la machine en sélectionnant le template Windows by Zabbix Agent.

20-2 - InfluxDB Grafana

Grafana est une plateforme de représentation de données sous forme graphique. Associé avec InfluxDB ou Graphite, Grafana est souvent utilisé pour faire de la supervision.

Promox intègre l’envoi d’informations de supervision vers une base InfluxDB ou Graphite.

20-2-1 - Installation InfluxDB

Installation des prérequis :

apt install gnupg2 apt-transport-https

Récupération de la clef de dépôt :

wget https://repos.influxdata.com/influxdata-archive_compat.key

Déplacement du fichier vers le dossier trusted.gpg.d :

cp influxdata-archive_compat.key /etc/apt/trusted.gpg.d/

Ajout du dépôt dans /etc/apt/sources.list :

deb https://repos.influxdata.com/debian stable main

Installation d’InfluxDB :

apt update
apt install influxdb2

Démarrage du service :

service influxdb start

L’accès se fera par l’adresse http://Votre_ip:8086

Le nom d’organisation sera nécessaire ultérieurement. Je crée un bucket (terminologie Amazon S3 pour un conteneur d’objet) par défaut nommé « default » :

Après validation, vous aurez la fenêtre suivante :

Nous n’utiliserons pas la clef d’API retournée.

Il faudra ensuite cliquer sur « quick start » :

Je crée un bucket nommé « proxmox » :

Je créé ensuite une clef d’API en lecture/écriture pour le bucket « proxmox » (pas une clef générale comme la première option le permet) :

Je nomme ici cette clef « proxmox », il faudra cliquer sur l’onglet « bucket » pour pouvoir sélectionner celui précédemment créé et lui affecter les droits :

La clef d’API sera alors renvoyée, à conserver pour la connexion depuis Proxmox :

Le copier-coller par clic sur « copy to clipboard » ne semble pas fonctionner

.

20-2-2 - Paramétrage du serveur de métrique dans proxmox

Le paramétrage du serveur de métrique se fera depuis « centre de données » → « serveur de métriques » → « ajouter », puis sélectionner « InfluxDB » :

Si vous vous connectez sur l’interface InfluxDB, vous pourrez constater la présence de données correspondant à Proxmox dans le bucket concerné :

20-2-3 - Installation Grafana

L’installation de Grafana se fera en récupérant le .deb :

wget https://dl.grafana.com/oss/release/grafana_11.1.0_amd64.deb
dpkg -i grafana_11.1.0_amd64.deb

Vous aurez probablement un message d’erreur de dépendances corrigible par :

apt-get install -f

Grafana ne démarrera pas automatiquement après l’installation, il faudra démarrer son démon et rendre le démarrage persistant :

systemctl daemon-reload
systemctl start grafana-server
systemctl enable grafana-server

La connexion se fera ensuite sur l’interface web par le port 3000 :

Utilisateur et mot de passe par défaut : admin

Vous devrez changer le mot de passe par défaut :

Vous aurez alors le tableau de bord suivant :

Une fois Grafana installé, nous pourrons utiliser la clef d’API précédemment créée, le mieux étant de créer une clef d’API en lecture seule, Grafana n’ayant pas besoin d’un accès en écriture.

Il faudra ensuite cliquer sur datasource pour ajouter notre source de données :

Vous sera ensuite proposée une liste de sources, nous sélectionnerons bien évidemment InfluxDB :

Il vous faudra ensuite renseigner les champs en commençant par changer le nom par défaut, puis changer « InfluxQL » par « flux » dans Query Langage. Il vous faudra ensuite renseigner les mêmes informations que dans Proxmox  :

Vous pourrez ensuite cliquer sur l’URL « building a dashboard » :

Nous utiliserons un dashboard mis à disposition pour Proxmox :

Pour cela, il nous faudra ensuite récupérer le numéro de modèle Grafana depuis l’URL https://grafana.com/grafana/dashboards/

La version de dashboard utilisée pour ce tutoriel est 15356.

Avant de valider, sélectionner le bon flux :

Vous devriez avoir une image comme ci-dessous :

Dans mon cas de figure, les éléments du sommaire apparaissent en « no data », mais les éléments en dessous sont bien renseignés.

Le problème vient probablement d’une incompatibilité totale du dashboard avec la version Proxmox installé.

21 - Maintenance

21-1 - Perte d'un nœud

La perte d’un nœud peut empêcher le démarrage d’une VM d’un autre nœud si le quorum (nombre minimum de nœuds pour le fonctionnement du cluster) n’est pas atteint. D’où l’intérêt d’avoir un nombre suffisant de nœuds.

Avant de pouvoir réintégrer un nouveau serveur avec un même nom, il va falloir supprimer l’ancien du cluster. Il n’y a pas d’options dans l’interface graphique pour sortir un nœud du datacenter, il va falloir le faire en ligne de commande.

Cette opération sera effectuée avec la commande :

pvecm delnode [nom du serveur à sortir]

Si vous avez le message d’erreur « An error occurred on the cluster node: cluster not ready - no quorum? », lancez la commande suivante sur le serveur en ligne :

pvecm expected 1

Le nombre est à adapter à votre configuration si vous avez plus de deux nœuds (bien que la commande devrait fonctionner, quel que soit le nombre de nœuds).

Ne pas oublier de rafraîchir la fenêtre de l’interface graphique du serveur gérant le cluster.

Une fois le serveur perdu supprimé, vous pourrez intégrer son remplaçant avec l’option « Rejoindre la grappe de serveur » comme vu au chapitre gestion d’un datacenter.

21-2 - Nœud intégrant Ceph

Les manipulations ci-dessous concernent l’aspect cluster Ceph.

La commande ceph status vous retournera un message comme celui-ci en cas de perte du nœud :

root@srv1:~# ceph status

cluster:
id:     dab25c59-b552-42a4-b6f1-9327f0a055a8
health: HEALTH_WARN
insufficient standby MDS daemons available
Degraded data redundancy: 47/141 objects degraded (33.333%), 30 pgs degraded, 80 pgs undersized
1/3 mons down, quorum srv1,srv3

services:
mon: 3 daemons, quorum srv1,srv3, out of quorum: srv2
mgr: srv1(active), standbys: srv3
mds: cephfs-1/1/1 up  {0=srv1=up:active}
osd: 3 osds: 2 up, 2 in

data:
pools:   2 pools, 80 pgs
objects: 47 objects, 103MiB
usage:   2.22GiB used, 37.6GiB / 39.8GiB avail
pgs:     47/141 objects degraded (33.333%)
50 active+undersized
30 active+undersized+degraded

root@srv1:~#

Nous pouvons voir que le moniteur de srv2 est out. Nous voyons la présence de trois OSD dont deux « up » et « in » (donc par définition un HS).

Nous retirons le monitor de srv2 :

root@srv1:~# ceph mon remove srv2
removing mon.srv2 at 192.168.1.201:6789/0, there will be 2 monitors

Il va nous falloir retirer le(s) OSD de srv2. Commençons par voir ce qu’il en est :

root@srv1:~# ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.05818 root default
-3       0.01939     host srv1
0   hdd 0.01939         osd.0     up  1.00000 1.00000
-5       0.01939     host srv2
1   hdd 0.01939         osd.1   down        0 1.00000
-7       0.01939     host srv3
2   hdd 0.01939         osd.2     up  1.00000 1.00000

Nous voyons que osd.1 sur srv2 est down. Il n’y a qu’un OSD sur le serveur HS (srv2), nous le supprimons :

root@srv1:~# ceph osd rm osd.1
removed osd.1

Nous supprimons ensuite l’OSD de la crush map :

root@srv1:~# ceph osd crush remove osd.1
removed item id 1 name 'osd.1' from crush map

Puis les informations d’authentification :

root@srv1:~# ceph auth del osd.1
updated

Voyons ce que donne maintenant la commande ceph osd tree :

root@srv1:~# ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.03879 root default
-3       0.01939     host srv1
0   hdd 0.01939         osd.0     up  1.00000 1.00000
-5             0     host srv2
-7       0.01939     host srv3
2   hdd 0.01939         osd.2     up  1.00000 1.00000

Il nous reste ensuite à retirer les dernières traces de srv2 :

root@srv1:~# ceph osd crush remove srv2
removed item id -5 name 'srv2' from crush map

Résultat :

root@srv1:~# ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.03879 root default
-3       0.01939     host srv1
0   hdd 0.01939         osd.0     up  1.00000 1.00000
-7       0.01939     host srv3
2   hdd 0.01939         osd.2     up  1.00000 1.00000
root@srv1:~#

Il m’a fallu ensuite supprimer les entrées dans le fichier /etc/pve/ceph.conf et redémarrer le service cluster :

systemctl pve-cluster restart

Une fois le nœud réinstallé, il suffira de joindre le cluster comme déjà vu.

Pour la partie Ceph, il faudra recréer un monitor sur srv2 depuis l’un des autres serveurs, recréer l’OSD et rajouter un MDS si vous le souhaitez.

Le cluster Ceph devrait se réparer automatiquement. Une fois la réparation effectuée, vous devrez voir « health_ok » après avoir tapé la commande ceph status. Dans le cas contraire, il faudra tenter un ceph health. En cas de problème, les commandes devraient vous donner des informations concernant celui-ci.

22 - Les outils en ligne de commande

Voici un résumé des outils disponibles en ligne de commande.

Les principales commandes spécifiques Proxmox :

- pvecm : PVE Cluster Manager ;

- pveam : gestion des templates ;

- pveceph : gestion Ceph ;

- pvesr : gestion de la réplication ;

- vzdump : sauvegarde de VM et conteneurs (voir vzdump help) ;

- qmrestore : restauration de VM ;

- commandes Proxmox spécifiques à LXC : pct (voir pct help).

Viennent s'ajouter :

- les commandes spécifiques à KVM : qm ;

- les commandes spécifiques à LXC (normalement accessibles ou au moins en partie depuis pct) ;

- les commandes spécifiques à Ceph (normalement accessibles ou au moins en partie depuis pveceph) ;

- les commandes spécifiques à la gestion de LVM, de ZFS, etc.

Plus d'informations sur les outils en ligne de commande.

23 - Options avancées

23-1 - Montage offline d'images disque

Il est possible de monter une image disque d'une VM hors de celle-ci sous réserve que l’hôte puisse gérer le système de fichiers de celle-ci et que la VM soit arrêtée.

23-1-1 - Image disque contenue dans un volume LVM

Il faut commencer par avoir accès aux partitions du volume, /dev/mapper/pve-vm--100--disk--0 étant le disque dur lui-même.

Nous utiliserons la commande suivante :

kpartx -av /dev/mapper/pve-vm--100--disk--0

Ceci retournera :

add map pve-vm--100--disk--0p1 (253:7) : 0 67106816 linear 253:6 2048

Nous pouvons voir qu'Il n’y a qu’une partition dans le disque : pve-vm—100--disk--0p1.

Un simple :

mount /dev/mapper/pve--vm--100--disk--0p1 /mnt

permettra de monter la partition tant que l'OS hôte reconnaît le système de fichiers contenu dans la partition.

23-1-2 - Montage d’une image disque au format KVM qcow2

Cela se fera avec la commande qemu-nbd:

qemu-nbd --connect=/dev/nbd0 /var/lib/vz/images/[id]/[nom_disque].qcow2

Si vous avez une erreur « Failed to open /dev/nbd0: no such file or directory », activez le module nbd :

modprobe nbd

Il faudra ensuite chercher le numéro de la partition à monter. Nous pouvons afficher les partitions avec la commande :

fdisk /dev/nbd0 -l

Il suffira de faire ensuite un montage avec la commande mount, exemple :

mount /dev/nbd0p2 /mnt

Une fois les opérations terminées, il faudra démonter proprement l'image disque :

umount /mnt
qemu-nbd --disconnect /dev/nbd0

23-1-3 - Montage d'une image VMDK

qemu-nbd est utilisable pour monter un fichier vmdk, en suivant le même principe que pour un fichier qcow.

23-1-4 - Montage hors ligne du disque d'un conteneur

Pour un conteneur dans un volume LVM, il faudra effectuer la même opération que pour l’image disque d’une VM comme vu précédemment.

Pour monter un disque de conteneurs au format .raw, nous allons utiliser un périphérique de loopback.

Il n'est pas possible de monter l'image d'un conteneur en cours d’exécution, la commande losetup présentée ci-dessous retournera l'erreur :

losetup: [fichier_image].raw: failed to set up loop device: Device or ressource buzy

Commençons par trouver le premier périphérique de loopback disponible :

losetup -f

La commande va nous retourner un périphérique numéroté, par exemple :

/dev/loop0

Nous montons donc notre image après l'avoir liée à /dev/loop0 :

losetup /dev/loop0 fichier_image.raw
mount /dev/loop0 /mnt

Une fois les opérations souhaitées effectuées, il faudra démonter proprement le volume :

umount /mnt
losetup -d /dev/loop0

23-2 - Gestion de certificats

Un certificat valide sera nécessaire pour accéder à l’interface d’administration Promox en HTTPS sans message d’avertissement. Comme déjà spécifié, pour des questions de sécurité, je déconseillerais l’accès à l’interface d’administration Proxmox via Internet.

Pour gérer les certificats d'un serveur, il faudra aller dans son menu (srv1 dans notre exemple) → « système » → « certificats » :

Vous pouvez voir ci-dessus les certificats autosignés.

Vous pourrez importer les certificats générés par une autorité de certification depuis «Téléverser un certificat personnalisé ». Vous pourrez alors télécharger la clef privée et la chaîne de certificats ou faire un copier-coller.

Vous pourrez utiliser le service de certificats gratuits Let's Encrypt. Il vous faudra alors, dans la partie en bas (ACME), renseigner les domaines à certifier (éditer les domaines) et l'adresse mail qui sera liée aux certificats (compte d'enregistrement).

23-3 - Authentification via LDAP ou Active Directory

Proxmox permet l'authentification via un serveur LDAP ou Active Directory. Pour cela, il faudra aller dans « centre de données » → « Permissions » → « Authentification », « ajouter ».

Cet aspect n’a pas été testé.

En cas d’authentification par LDAP ou AD, gardez à l’esprit que si le serveur LDAP/AD est virtualisé et fait partie du cluster, la non-disponibilité des services empêchera l’authentification.

23-4 - Sécuriser l'accès à votre interface d'administration

Il est possible de restreindre les IP pouvant accéder à l'interface en écrivant dans le fichier /etc/default/pveproxy :

ALLOW_FROM="192.168.1.15"
DENY_FROM="all"
POLICY="allow"

Il faudra ensuite redémarrer le service :

service pveproxy restart

pveproxy utilise la syntaxe Apache2. L'exemple précédent autorise uniquement l’accès à l'interface depuis l'adresse IP 192.168.1.15.

Si votre hôte possède plusieurs cartes réseau, vous pouvez en dédier une pour l’accès à l’interface d’administration sur un réseau autonome.

23-4-1 - Authentification à deux facteurs

L'authentification à deux facteurs est un système de double authentification, la première authentification se fait par mot de passe standard, la seconde par code à usage unique (envoyé par mail ou SMS) ou via un dispositif externe comme une clef USB contenant une clef privée, une empreinte digitale ou un token.

Proxmox gère quatre systèmes pour l'authentification à deux étapes :

- TOTP

- Webauthn

- clefs de récupération

- une Yubikey (clef USB d'authentification de la société Yubicon) ;

L’accès se fera dans le menu en haut à gauche → « TFA » :

23-4-1-1 - Authentification OTP

OTP (One Time Password) est un système de génération de mot de passe à usage unique.

Pour activer celui-ci, il vous faudra avoir une application sur votre téléphone, j’ai utilisé l’application freeOTP.

Il va falloir commencer par aller dans le menu « utilisateur » → « abonnement » :

Il vous faudra renseigner le mot de passe du compte pour lequel vous activez le 2FA, puis le code à usage unique retourné par l’application. Une description sera indispensable.

Vous pouvez voir ci-dessous le code à usage unique enregistré :

Lors de la prochaine connexion, après avoir renseigné le mot de passe, le code d’authentification à 2 facteurs vous sera demandé :

23-4-1-2 - Authentification Webauthn

L’authentification Webauthn est un standard W3C. Ce procédé a besoin d’un équipement externe tel qu‘une clef USB d’authentification ou un équipement NFC.

Il est également possible d’utiliser un TPM.

Webauthn fait partie du projet FIDO2, alliance de promotion de normes d’authentification.

Cette authentification n’a pas été testée (manque de matériel).

23-4-1-3 - Authentification Yubico

Pour ceci, il vous faudra une clef UB Yubikey qui vous permettra de faire une authentification à deux facteurs.

Cette clef est compatible avec les normes :

- FIDO2/Webauthm ;

- U2F ;

- Smart Card ;

- OpenPGP ;

- OTP.

Il existe plusieurs modèles avec notamment le support NFC et biométrique (empreinte digitale).

Cette méthode d’authentification n’a pas été testée faute de Yubikey disponible.

23-4-1-4 - Clefs de récupération

Cette option va générer une liste de clefs de récupération à usage unique. Ceci sert à pallier la perte d’accès à un dispositif 2FA. Vous aurez un écran avec la liste des clefs à conserver :

L’entrée sera visible au même niveau que l’entrée du dispositif 2FA (OTP dans notre cas de figure) :

Lors de la demande d’authentification à deux facteurs, vous aurez l’onglet clef de récupération accessible :

Une fois connecté, vous pourrez désactiver l’authentification à deux facteurs ou régénérer un groupe de clefs) à usage unique.

23-4-1-5 - Dépannage de l’authentification à deux facteurs

Si un utilisateur ne plus se connecter à cause de l’authentification à deux facteurs, vous pourrez lui désactiver celle-ci depuis le menu avec votre compte principal.

Si vous perdez l'accès à l'authentification à deux facteurs pour le compte principal, vous pourrez la désactiver via un accès SSH.

Ci-dessous, la commande pour lister les authentifications à deux facteurs :

pveum user tfa list

qui retournera pour mon cas :

gestion@pam:
recovery: recovery

totp:     d61a2939-2f12-46a6-ae3d-e0a94dfe11cb
totp

root@pam:
recovery: recovery

Vous pouvez voir que pour l’utilisateur gestion, TOTP et les clefs de récupération sont activées et que les clefs de récupération sont activées pour l’utilisateur root.

Je vais supprimer l’activation MFA pour l’utilisateur root :

pveum user tfa delete root@pam

Le rappel de la commande pveum montre qu’il n’y a plus de MFA pour l’utilisateur root :

/# pveum user tfa list
gestion@pam:
recovery: recovery

totp:     d61a2939-2f12-46a6-ae3d-e0a94dfe11cb
totp

23-5 - Suppression message de licence

Lors de la connexion, vous avez un message « Aucune clef d'enregistrement valide » :

Le message est désactivable en modifiant le code dans le fichier /usr/share/javascript/proxmox-wideget-toolkit/proxmoxlib.js.

Recherchez la chaîne « Ext.Msg.show » qui devrait se trouver dans un test « if … .data.status.toLowerCase()!=’active’ commentez le bloc Ext.Msg.show jusqu’au else.

Il faudra redémarrer les service pveproxy avec la commande :

systemctl restart pveproxy.service

Vous n’aurez alors plus le message.

Cette manipulation demande un minimum de compréhension du code Javascript pour correctement commenter le bloc de code et requiert une copie du fichier avant intervention.

Elle pourra ne plus être fonctionnelle lors de l’utilisation d’une version plus récente du produit.

La suppression du message est également possible en achetant une licence, pensez à le faire si vous le pouvez, vous aurez accès à des mises à jour et du support et contribuerez à faire perdurer et évoluer le produit.

24 - Conclusion

Proxmox offre toutes les fonctionnalités que l'on peut attendre d'un gestionnaire de machines virtuelles (sauvegarde, réplication, haute disponibilité). Sans aucun doute, Proxmox est donc un concurrent libre sérieux pour VMWare et Hyper-V. L'ouverture du code et le prix sont inévitablement un gros avantage pour Proxmox.

Bien qu'il soit possible d'installer Docker dans une VM ou un container LXC, le support de celui-ci en natif serait un plus au vu de sa popularité. De mon avis, LXC est plus simple et facile à utiliser que Docker, mais Docker apporte plus de fonctionnalités et il est maintenant un standard.

Malgré une interface graphique complète, il est toujours utile de connaître les lignes de commande permettant les actions équivalentes, et notamment pour des fonctions avancées non présentes dans l’interface graphique. Par ailleurs, les outils externes tels que Ceph ont leurs propres commandes qui ne sont pas toutes implémentées dans l’interface graphique.

L’utilisation de Proxmox pourra prendre de l’ampleur au vu de la nouvelle politique de VMWare supprimant l’accès à ESXi, l’hyperviseur gratuit.

24-1 - Remerciements

Je remercie LittleWhite pour ses relectures techniques ainsi que ClaudeLELOUP et escartefigue pour leur relecture orthographique.