PROXMOX

Virtualisation de vos serveurs

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 : 16 février 2020

- 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

- 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

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

- 5. Le stockage dans Proxmox

- 6. Le réseau dans Proxmox

- 7. Création et utilisation d'une VM

- 7-1. Les prérequis

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

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

- 7-4. Modification de réglages d'une VM

- 7-4-1. Ajout d'un disque à la VM

- 7-5. Snapshot

- 7-5-1. Administration avancée

- 7-6. Cloner une VM

- 7-7. Migrer une VM

- 7-8. Créer un template

- 8. Création d’un conteneur

- 8-1. Prérequis : un template de conteneurs

- 8-2. Création du conteneur

- 9. Sauvegarde

- 9-1. Sauvegarde sur support externe

- 9-2. Planification des sauvegardes

- 9-3. Sauvegardes incrémentales

- 10. Import/export de VM

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

- 10-2. export

- 10-3. Alternative

- 11. Gestion d'un datacenter

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

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

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

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

- 11-2. Migration d’une VM

- 12. Réplications

- 13. Haute disponibilité

- 13-1. Activation de la haute disponibilité sur une VM

- 13-2. Gestion globale de la haute disponibilité

- 13-3. Groupe de haute disponibilité

- 13-4. Fencing

- 14. Stockages distribués

- 14-1. Stockage ZFS

- 14-2. Stockage Ceph

- 14-3. Stockage GlusterFS

- 15. Maintenance

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

- 15-1-1. Nœud intégrant Ceph

- 15-2. Haute disponibilité

- 16. Les outils en ligne de commande

- 17. Options avancées

- 17-1. Gestion de pools

- 17-1-1. Création d'un pool

- 17-1-2. Gestion d'un pool de ressources

- 17-2. Montage offline d'images disque

- 17-2-1. Image disque contenue dans un volume LVM

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

- 17-2-3. Montage d'une image vmdk

- 17-2-4. Montage hors ligne du disque d'un conteneur

- 17-3. Gestion de certificats

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

- 17-5. Authentification via LDAP ou Active Directory

- 17-6. Authentification à deux facteurs

- 17-6-1. Activer l'authentification Oath

- 17-6-2. Activer l'authentification Yubico

- 17-6-3. Dépannage de l’authentification à deux facteurs

- 17-7. Suppression message de licence

- 17-8. Mise à jour Proxmox 5 vers Proxmox 6

- 18. Conclusion

- 18-1. Remerciements

1 - Description

Proxmox est un environnement open source (licence aGPL) avec service de support payant s'appuyant sur l'hyperviseur Linux KVM et sur LXC. 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.

Au moment de la publication de ce tutoriel, la version 6.0 de Proxmox ainsi que Debian 10 Buster viennent d'être publiés. Le tutoriel est basé sur la version 5.3.

La version 6.0 apporte les changements suivants :

Proxmox 5.3

Proxmox 6.0

Basé sur Debian stretch 9.6

Basé sur Debian Buster 10.0

Noyau 4.15.18

Noyau 5

Qemu 2.12.1

Qemu 4.0.0

LXC 3.0.2

LXC 3.1

Ceph Luminous 12.2.8

Ceph Nautilus 14.2.x

Pas de changement apparent au niveau de l'interface graphique. Les apports des nouvelles versions du noyau, de Qemu et de LXC sont intéressants, mais Debian Buster et Proxmox 6 venant de sortir, attendez quelque temps pour obtenir des correctifs améliorant la stabilité.

Le changement de version majeure de Ceph peut générer des difficultés de par sa complexité en cas de mise à jour.

2 - Installation

Proxmox peut être installé soit à partir d’un fichier ISO, soit à travers le gestionnaire de paquets de votre système déjà en place. Proxmox n'est disponible que pour Debian.

2-1 - Installation depuis l'ISO

L'ISO permettant l'installation de Proxmox au moment de l'écriture de ce tutoriel est téléchargeable ici. Celui-ci est basé sur Debian Stretch.

Voici l'écran de démarrage :

Après avoir démarré, nous aurons le premier écran d'installation suivant :

Puis :

Proxmox effacera d'éventuelles données présentes.

Le bouton options permettra de personnaliser le partitionnement.

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 (vous pouvez personnaliser à votre guise).

Il faudra ensuite renseigner le mot de passe et l'adresse mail de l'administrateur :

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

L’installation s’effectue ensuite automatiquement :

L'écran en fin d'installation vous aurez l'écran suivant vous rappelant l'URL d'accès à l'interface d'administration :

Adresse de la forme : https://[adresse_ip/FQDN]:8006.

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.

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 des dépôts pour :

- Debian Jessie (version 4.x) ;

- Debian Stretch (version 5.x) ;

- Debian Buster (version 6.x).

Proxmox est fourni depuis Debian Squeeze, mais les versions antérieures à celles basées sur Jessie sont obsolètes.

Commençons par récupérer la clé de sécurité du dépôt :

wget http://download.proxmox.com/debian/proxmox-ve-release-5.x.gpg
apt-key add proxmox-ve-release-5.x.gpg

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

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

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

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

Pour la version Debian Buster, il faudra utiliser le fichier proxmox-ve-release-6,x,gpg ainsi que le dépôt buster au lieu de stretch.

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 reboot est donc nécessaire.

Une fois le reboot 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

Pour commencer, il faut comprendre la notion de datacenter du point de vue de Proxmox. Un datacenter va être un point unique de gestion des ressources. Une ressource sera :

- un serveur ;

- des espaces de stockage (stockés sur un serveur, partagé ou non entre les différents serveurs, des NAS externes, des systèmes de fichiers distribués, etc.) ;

- des templates 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 VM ;

- des conteneurs.

Un datacenter Proxmox peut contenir un seul serveur. Vous verrez quand même le terme de datacenter dans l'interface d'administration alors qu'il n'y a qu'une machine.

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

La version sur laquelle est basé ce tutoriel est la version 5.3-8 de Proxmox.

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

Il faudra vous authentifier avec le mot de passe root en ayant sélectionné « Linux PAM standard authentication ».

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

Il suffira de cliquer OK.

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

Nous voyons la liste des serveurs du datacenter (dans ce cas uniquement srv1).

Vous verrez ensuite les espaces disques des serveurs pour srv1 par défaut en cliquant sur srv1 (ou en allant sur stockage) :

- local ;

- local-lvm (présent uniquement depuis l’installation avec le live-cd ou si vous avez installé un LVM (voir partie ajout LVM).

La vue par défaut présente l’arborescence du datacenter , l’onglet datacenter affichant :

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

- cluster : permet de créer/rejoindre un cluster ;

- options : réglages d'options telles que la disposition du clavier, 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 :

- utilisateurs : pour ajouter des utilisateurs (stockés dans le fichier /etc/pve/user.cfg pour les utilisateurs pve locaux) ;

- groupes : création de groupes pour les utilisateurs ;

- gestion de pools ;

- rôles : les différents rôles pour les utilisateurs. Exemple de rôle prédéfini : administrateur, PVEDatastoreAdmin : permettant d'administrer un datastore. Il est possible de créer ses propres rôles, dans ce cas, vous pouvez créer un rôle de démarrage ou création de VM par exemple, ceci permettant de déléguer une partie de l'administration à certains utilisateurs telle que le droit VM.PowerMgmt pour démarrer/arrêter une VM par exemple. Ceci étant une fonction avancée et utile pour la gestion d'un cluster volumineux.
Plus d'informations sur les privilèges Proxmox ;

- Authentification : gère les méthodes d'authentification utilisées par Proxmox :

- Par défaut :

- pam : Authentification PAM standard de Linux,

- pve : Authentification interne à Proxmox,

- Méthodes supplémentaires :

- Active Directory,

- Serveur LDAP.

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

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

- Support : accessible uniquement dans la version payante.

Un clic sur srv1 permettra d’obtenir les options suivantes :

- 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 où vous pouvez inscrire ce que vous souhaitez ;

- Shell : ouvre une console sur le serveur via VNC ;

- 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,

- Hosts : permet la modification du fichier /etc/hosts,

- temps : permet le réglage de la timezone,

- syslog : accès au contenu de syslog ;

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

- Disques : affiche les différents disques physiques du serveur (accès à l'état 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 ;

- ZFS.

- résumé

- contenu

- permissions

Dans la partie gauche, vous pourrez avoir différentes arborescences de vues pour ces affichages :

- vue serveur (par défaut) ;

- vue dossier ;

- vue stockage ;

- vue pool.

Un pool est un regroupement de ressources.

Avant de créer une VM ou un conteneur, nous allons aborder le stockage et la gestion du réseau dans Proxmox.

5 - Le stockage dans Proxmox

Pour le stockage, Proxmox gère des magasins de données. Les différents magasins de données disponibles dans Proxmox sont :

- les dossiers standards ;

- les points de montage SMB, NFS ;

- les volumes LVM pour les disques virtuels des VM (par défaut si installé depuis l'ISO) ;

- les périphériques SAN via le protocole iSCSI ;

- les volumes ZFS ;

- les espaces de stockage distribués Ceph ;

- les espaces de stockage distribués et/ou répliqués GlusterFS.

Les magasins de données vont contenir :

- des VM/conteneurs ;

- des ISO ou templates de conteneurs.

Si LVM est présent, les VM seront automatiquement stockées dans des volumes LVM (un volume LVM par disque virtuel) dans l’espace de stockage local-lvm, les ISO ou templates seront eux stockés dans l'espace de stockage local.

Un magasin de données Ceph permettra le stockage de tout élément.

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

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ément contenu par l’espace de stockage (images, sauvegardes, templates, etc.) ;

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

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

- export pour montage NFS ;

- point de partage pour montage CIFS ;

- choix du Volume Group pour LVM ;

- Volume Name pour GlusterFS.

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 la GUI de Proxmox si besoin.

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

6 - Le réseau dans Proxmox

La gestion des cartes réseau se gère depuis système → réseau :

Pour pouvoir utiliser le réseau avec une VM, il vous faudra créer un Bridge ou utiliser un Bond (que nous verrons un peu plus bas). 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 pourront utiliser une autre carte.

Si vous avez installé Proxmox depuis le CD, 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 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 via 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 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.

7 - Création et utilisation d'une VM

7-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 uploader un fichier ISO qui nous permettra de procéder à l’installation de notre OS virtualisé depuis un média d'installation.

Si nous cliquons sur l’onglet « Stockage » de notre datacenter, nous verrons un stockage local(srv1), et un stockage local-lvm(srv1).

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

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

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

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.

L'ISO sera alors disponible et visible.

Si l'upload é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.

7-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 via le bouton droit sur le nom de votre serveur à gauche.

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’id VM par défaut conviendra, libre à vous de le modifier tant qu’il reste unique. Il restera à renseigner le nom de la VM :

Cocher l’écran « Advanced », nous permettra de cocher démarrer au boot. Cette option permet de démarrer automatiquement la VM si l’hôte est redémarré. Il est également possible de gérer une temporisation de démarrage et d’arrêt, ainsi que l’ordre de démarrage.

Le second écran va vous demander :

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

- le type d'OS : choix entre Linux/Windows/Solaris/Other. Ceci va optimiser les réglages pour l’OS souhaité (réglages que vous pourrez changer).

Sur l‘écran suivant, nous allons créer un disque virtuel. Par défaut, celui-ci sera en SCSI (vous pourrez sélectionner le numéro de périphérique sur le bus). Vous pourrez sinon utiliser un disque SATA, IDE, ou VirtIO :

Les options avancées permettront d’effectuer de l’émulation SSD, et d’affiner les réglages I/O.

VirtIO va permettre d’améliorer les performances si vous utilisez un driver 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 : qcow, 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.

Vous pourrez ensuite effectuer les réglages CPU (nombre de cœurs, socket, son type)

Les options avancées permettront de sélectionner le nombre de CPU virtuels (le nombre de cœurs disponibles dans la VM), de gérer les limites.

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

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

Les options avancées permettront de gérer le « memory ballooning », technique permettant de récupérer de la RAM allouée aux autres VM, mais non utilisée : en gros : du surboooking entre la RAM affectée aux différentes VM.

L’écran suivant concernera les réglages réseau :

Seul le mode pont est disponible. Pas de mode NAT (qui était présent dans la version précédente), 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.

Vous aurez ensuite l’écran récapitulatif de la VM.

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

Une fois la VM créée, elle apparaîtra sur la partie gauche, et 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 snapshot, les réplications, et les sauvegardes.

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.

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.

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

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

Une fois celle-ci démarrée, vous pourrez voir la console en cliquant « console », ou ouvrir une fenêtre de console en allant dans le menu console → NoVNC (NoVNC est un client et une bibliothèque VNC en JavaScript) :

Vous pourrez passer en plein écran en cliquant sur la flèche dans la fenêtre NoVNC :

7-4 - Modification de réglages d'une VM

Pour changer les réglages d’une VM, il vous faudra cliquer dessus dans la partie gauche, puis sélectionner matériel à droite :

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

Exemple pour la carte réseau :

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

Certains réglages seront modifiables à chaud, mais d'autres nécessiteront l'arrêt de la VM.

7-4-1 - 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 disque 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.

7-5 - Snapshot

Un snapshot est une photographie à un instant T d'une VM. Après la création d'un snapshot, à chaque modification du disque virtuel, chaque bloc d'origine est d'abord copié dans le snapshot avant d'être modifié. Il est donc possible de revenir à un état initial ou d'utiliser celui-ci pour une sauvegarde par exemple, afin d'avoir un état cohérent en cas de modifications pendant celle-ci. La sauvegarde correspondra à l’état initial (donc sans prise en compte des modifications pendant celle-ci).

Le fichier snapshot est dépendant du disque d’origine, donc inexploitable sans celui-ci.

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

La valeur « NOW » 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 snapshot » va vous afficher la fenêtre suivante :

Vous pourrez donner un titre à votre snapshot et mettre un commentaire. « Inclure la RAM » 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 de la machine avec arrêt brutal.

Sur l'écran suivant, vous pourrez voir le snapshot ainsi que l’état actuel (NOW) :

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

Annuler un snapshot va donc supprimer la copie des blocs modifiés depuis sa création. 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.

7-5-1 - Administration avancée

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

La configuration de la VM est sauvegardée dans un snapshot, si celle-ci est modifiée, la restauration utilisera donc l’état de configuration initial en plus du disque initial.

Dans le fichier de configuration de la VM, une entrée supplémentaire « vmstate : » indique le disque virtuel supplémentaire (fichier qcow, volume LVM, volume ZFS selon la configuration d'origine) contenant le snapshot.

7-6 - 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 que la VM source, du moins tant que vous ne les changez pas.

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.

7-7 - Migrer une VM

Migrer une VM 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 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

7-8 - 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 en template, il faudra cliquer dessus via le bouton droite et sélectionner convertir en template :

Vous aurez une demande de confirmation.

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

Il ne s'agit pas de juste changer l’icône.

Dorénavant quand vous accéderez à cloner, vous aurez une option supplémentaire intéressante :

Vous pourrez sélectionner deux modes :

- clonage lié : un snapshot est créé sur la VM source. 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, seront autonomes, 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.

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 à 0 dans le fichier de configuration de la VM.

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.

8 - Création d’un conteneur

8-1 - Prérequis : un template de conteneurs

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

Vous pourrez en récupérer en cliquant « template » en allant dans le serveur (srv1 dans notre cas) → local →contenu :

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

- la section system ;

- la section turnkeylinux.

La section system va contenir des images telles que Centos6 7, Fedora28, Alpine 3.8.

La section turnkeylinux va contenir des images telles que Owncloud, Prestashop, NodeJS, c'est-à-dire des templates tout faits prêts à utilisation.

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

Si vous avez votre propre template, celui-ci sera uploadable de la même façon que pour un ISO.

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

8-2 - Création du conteneur

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

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

- le nœud de destination en cas de plusieurs serveurs ;

- le nom du conteneur ;

- son mot de passe ;

- éventuellement une clé SSH.

Cocher « unprivileged container » est recommandé en termes de sécurité. Un « privileged container » aura un UUID de 0.

Sur le second écran, vous sélectionnerez le stockage de destination (si vous avez plusieurs stockages), le modèle de conteneur :

Vous pourrez ensuite sélectionner la taille du disque :

Cocher «advanced » permettra d’activer le quota, de gérer les ACL.

Vous sélectionnerez enfin le nombre de cœurs et la mémoire affectée au conteneur :

Les options avancées permettent de mettre une limite CPU.

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

L’écran suivant concernera le réseau :

Et enfin les DNS :

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.

Le conteneur en création :

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

Le disque du conteneur se trouvera dans l'espace de stockage dans le dossier images/[id contenur]/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.

9 - 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 :

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.

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

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

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.

9-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 niveau, 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 correspondant au point de montage, pouvant ainsi saturer le disque contenant le dossier accueillant le point de montage.

9-2 - Planification des sauvegardes

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

Vous créerez alors un job de sauvegarde, ou vous sélectionnerez :

- les nœuds à sauvegarder (en cas de présence de plusieurs serveurs), par défaut tous ;

- l'espace de stockage où mettre les sauvegardes ;

- les jours et heures de déclenchement des sauvegardes ;

- le mode de sélection :

- inclure les VM sélectionnées (par défaut),

- exclure les VM sélectionnées,

- tout ;

- l'adresse e-mail où envoyer le rapport ;

- le type de rapport :

- toujours,

- en cas d'erreurs ;

- le mode de sauvegarde :

- snapshot,

- suspendre,

- stopper.

Une planification peut être éditée pour être modifiée.

9-3 - Sauvegardes incrémentales

Les sauvegardes seront des sauvegardes complètes, pas de possibilité de sauvegardes incrémentales.

Il existe un patch non officiel écrit par ayufan. Celui-ci ajoute les options adéquates dans l'interface graphique pour paramétrer des sauvegardes incrémentales en demandant au bout de combien de sauvegardes incrémentales une sauvegarde complète est faite.

Pour installer ce patch, une fois la commande git clone indiquée sur le site, effectuée, il faudra lancer le script correspondant à votre version avec l'option APPLY (voir la documentation sur la page git).

Exemple avec la version 5.9 :

bash pve-5.3-9-diff-backup-addon apply

Ce patch va ajouter le champ « Full backup Every » : qui va déterminer à quelle fréquence une sauvegarde complète sera effectuée. Par défaut, cette valeur est à 0, ce qui signifie qu'une sauvegarde complète sera effectuée à chaque fois. Une fois cette valeur modifiée, toutes les sauvegardes entre la période « Full Backup Every » seront des sauvegardes incrémentales.

Le patch modifie la commande de sauvegarde vzdump en y ajoutant l'option --fullbackup.

Proxmox ne propose pas de sauvegardes incrémentales par défaut, la logique étant de plutôt utiliser la réplication.

En cas d'utilisation de ce patch, attention à prendre celui correspondant à votre version. Il peut y avoir décalage entre votre version de Proxmox et la dernière version de patch disponible. Il peut être dans ce cas dangereux de l'utiliser.

10 - Import/export de VM

Dans le domaine de la virtualisation, il existe un format, 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 le même type 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 restera à convertir les fichiers images disque dans un format connu par l'hyperviseur si nécessaire, 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.

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

Vous ne pourrez pas importer directement une appliance au format .ova dans Proxmox.

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

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 101 alpine.ovf local-lvm
warning: unable to parse the VM name in this OVF manifest, generating a default value
invalid host ressource /disk/vmdisk1, skipping
root@proxmox:~#

Nous pouvons constater un Warning et un message de ressource invalide lié à un disque. La VM apparaît quand même dans l'interface de Proxmox, mais sans disque. Ceci confirme que l'import n'est pas forcément simple et automatique.

Une autre commande qm permet l'importation de disques :

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

Nous l'appliquons pour intégrer le disque dans la VM nouvellement créée :

# qm importdisk 100 alpine-disk001.vmdk local --format qcow2
Formatting '/var/lib/vz/images/100/vm-100-disk-0.qcow2', fmt=qcow2 size=10737418240 cluster_size=65536 preallocation=metadata lazy_refcounts=off refcount_bits=16
(6.00/100%)
…
#

J'ai ajouté l'option --format qcow2 de façon à générer une image en qcow2. qm importdisk permet de générer un disque en format raw, qcow2, ou vmdk.

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 qcow. En cas de format différent, il faudra passer par qemu-img que nous verrons dans la partie export, ou par un produit tiers.

Ci-dessous, écran une fois l’import du disque effectué :

Le disque a bien été ajouté, mais il apparaît en non utilisé. Le fait de cliquer sur « éditer », et de fermer la fenêtre par « ajouter » va présenter le disque correctement. J’en profite pour le passer en SATA, plutôt qu'IDE par défaut, conformément à la VM d'origine.

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

10-2 - 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.

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 qui vous servira à créer la définition d'une nouvelle VM dans un autre hyperviseur que KVM.

10-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.

11 - 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 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 des VM, des conteneurs (démarrage, arrêt, modification, suppression, etc., des espaces de stockages du datacenter, quelle que soit leur position dans le cluster.

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

11-1 - Création d'un cluster

Nous commençons par préparer un hyperviseur supplémentaire sur une autre machine.

Une fois le second serveur préparé, il vous faudra aller sur datacenter → cluster puis « créer un cluster » sur le premier nœud :

Il vous sera demandé le nom du cluster  :

Il n'est pas nécessaire de renseigner l'adresse du cluster.

Cluster en cours de création :

Le nom de votre cluster apparaîtra entre parenthèses à côté de datacenter :

Intégrons maintenant notre serveur supplémentaire après sa préparation depuis le menu datacenter → cluster, en cliquant sur joindre le cluster :

Il vous sera demandé :

- les informations du cluster ;

- son adresse ;

- son mot de passe ;

- son empreinte.

Vous trouverez les informations dans datacenter → cluster → information de jonction sur le premier serveur, à côté du bouton de création de cluster :

Copier le champ information va automatiquement renseigner le champ empreinte et l’adresse IP, il restera à rentrer le mot de passe.

Machine en cours de jonction :

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) :

Écran pris depuis srv2.

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 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 via le 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 minimum de fonctionnement) n'est pas atteint pour éviter une situation de split-brain. Voir le chapitre maintenance.

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

11-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. Pour cela il faudra :

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

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

11-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 (exemple 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 selon le format. Il n'y aura bien évidemment pas d'extension en cas de volume logique 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 id 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=....

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ètre 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'id 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 installation personnalisée.

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

Pour rendre les VM invisibles, 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 en fonction continueront de fonctionner.

Chaque machine virtuelle en fonction est vue comme un processus de l'hôte. Vous pouvez les voir via 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.

11-2 - Migration d’une VM

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

Pour migrer une VM, il faudra cliquer bouton droite sur celle-ci, puis choisir « migration »

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

J'ai pu constater une erreur de migration avec une VM liée à un ISO dans un espace local  :

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

Il est également possible 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 : id 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.

É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

2019-03-16 21:03:58 ERROR: migration finished with problems (duration 00:14:33)
migration problems

Malgré le message d’erreur, la migration a fonctionné.

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

12 - Réplications

La réplication permet d'avoir une copie d'une VM prête à remplacer la VM en cours d’exécution en cas de problème.

Il sera nécessaire d'utiliser des volumes ZFS ou à accès concurrentiel comme Ceph pour pouvoir utiliser la fonction de réplication.

Un job de réplication sera créé depuis datacenter → réplication ou serveur → réplication (choix équivalent)

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)

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

Vous aurez ensuite l’entrée de réplication disponible (en erreur sur l’écran), vous pourrez accéder aux logs, et déclencher une réplication immédiate :

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

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

Pour activer automatiquement une réplique, consultez le chapitre sur la haute disponibilité HA.

13 - Haute disponibilité

La haute disponibilité est une notion signifiant qu'un système d'informations 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 faut pour cela un système redondant.

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

- un onduleur ;

- un système de disques en RAID ;

- une double alimentation électrique ;

- cartes réseau montées en agrégation de liens ;

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

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

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

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.

Le système devra être capable de détecter la perte d'un nœud hébergeant une VM 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). 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é.

13-1 - Activation de la haute disponibilité sur 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 HA (pour high availability) :

Vous aurez l'écran suivant :

Éléments à renseigner :

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

- Max relocate : nombre maximum d'essais de déplacement après échec de démarrage ;

- groupe : sera vue dans la section suivante ;

- Request state : é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é.

13-2 - Gestion globale de la haute disponibilité

La gestion globale de la haute disponibilité s'effectuera dans datacenter → HA :

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

La partie Ressource présente les VM intégrées à la gestion de la haute disponibilité.

13-3 - 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 de restreindre par exemple des VM à pouvoir par exemple se trouver sur deux serveurs parmi trois, de gérer prioritairement sur quel serveur elles doivent se trouver.

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.

13-4 - 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.

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 un reset de la machine, ceci afin de détecter un éventuel blocage.

14 - Stockages distribués

14-1 - Stockage ZFS

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

- intégrité des données forte ;

- gestion de volume intégré ;

- gestion de snapshots ;

- intégration de RAID logiciel ;

- 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 :

Vous pourrez créer un volume ZFS multidisque avec support RAID. (RAID-0 mirror, RAID-10 RAID 1 encapsulé dans un RAID-0 , RAID-5, RAIDZ : RAIDZ RAID-5 avec un disque de parité, trois disques minimum RAIDZ2 : RAID-5 avec deux disques de parité minimum quatre disques, RAIDZ3, RAID-5 avec trois disques de parité minimum cinq disques.

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.

14-2 - Stockage Ceph

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

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

La présentation dans ce tutoriel sera succincte.

Pour l’exploiter, il vous faudra trois nœuds pour garantir le quorum (nombre minimum de ressources pour qu'un vote puisse être légitime et éviter un split-brain) et minimum un disque dur libre par nœud.

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 et est même contreproductif 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.

- 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.

Si vous allez dans la partie Ceph du tableau de bord :

Pour les versions antérieures à 6, vous pourrez constater un message d’erreur « binary not installed : usrbin/ceph-mon (500) ».

Il va falloir installer les paquets Ceph :

pveceph install

Nous activons la gestion réseau :

pveceph init --network 192.168.1.0/24

puis initialisons le premier moniteur :

pveceph createmon

Cette dernière opération est faisable depuis l’interface graphique.

Sur la version 6 de Proxmox, l'installation a été améliorée. Depuis le menu Ceph vous avez maintenant la possibilité d'installer directement celui-ci sans devoir passer par la ligne de commande.

Il ne s'agit que d'habillage, le clic sur la proposition d'installation déclenchant simplement l'ouverture d'une fenêtre de terminal demandant la confirmation de l'installation des paquets Ceph.

Nous pouvons ensuite voir le moniteur dans le panneau Ceph :

Nous pouvons voir un « health warn », le cluster Ceph ne comprenant qu’un moniteur et aucun osd.

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 Journal/DB disk). Il est conseillé d'utiliser des disques SSD pour les journaux pour des questions de performances.

Nous allons ensuite dans l’onglet CephFS. Il va nous falloir créer tout d’abord un serveur de métadonnées (MDS) :

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

Depuis srv2, nous pouvons voir la présence du CephFS :

Nous ajoutons un MDS sur srv2 pour la redondance.

Nous créons un pool de trois machines avec un minimum de deux.

Nous créons ensuite un moniteur sur le second serveur :

Le moniteur va être créé :

Pour créer l’osd du second serveur, il faudra utiliser son interface web. Nous pourrons ensuite voir les osd des deux serveurs :

Une fois l'espace de stockage Ceph créé, il va falloir l'ajouter depuis Datacenter → stockage :

Comme montré ci-dessus, il va falloir sélectionner « RBD », ce qui ouvrira l'écran suivant :

Le pool du CephFS créé précédemment est automatiquement sélectionné. Reste à sélectionner le contenu du stockage : image disque ou conteneur.

Le CephFS est alors disponible pour le stockage de VM :

14-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.

Il n'y a pas de gestion avancée de GlusterFS dans Proxmox, mais vous pouvez créer un espace de stockage sur un GlusterFS existant.

Proxmox ne recommande pas l'utilisation de GlusterFS pour stocker de grosses VM, car 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.

15 - Maintenance

15-1 - Perte d'un nœud

Il n’y a pas d’option de suppression d’un nœud depuis l’interface graphique.

Pour sortir un nœud définitivement du cluster, il faudra lancer la commande :

pvecm delnode [nom du serveur à sortir]

Si vous n'avez que deux serveurs, vous n'aurez pas de quorum, et vous aurez le message d'erreur suivant lors de la tentative de sortie du nœud :

cluster not ready - no quorum ?

Il vous faudra dans ce cas taper la commande suivante avant la sortie du nœud :

pvecm expected 1

15-1-1 - Nœud intégrant 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 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 Ceph, il faudra recréer un monitor sur srv2 depuis un des autres serveurs, recréer l’osd, rajouter un MDS si vous le souhaitez.

Le cluster Ceph devrait s’autoréparer, une fois l'autoré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.

15-2 - Haute disponibilité

Comme vu dans le précédent chapitre, la haute disponibilité permet de pallier automatiquement la perte d'un nœud, le système allant automatiquement basculer les VM d'un nœud à l'autre en cas de perte de leur nœud d'origine.

Une fois le problème résolu, il vous restera à éventuellement rebasculer les VM sur leur nœud initial, d'éventuellement refaire le réglage au cas où le nœud rétabli devient une machine de secours (pour éviter de redéplacer les VM).

16 - 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 réplication ;

- vzdump : sauvegarde de VM et conteneurs (vzdump help) ;

- qmrestore : restauration de VM ;

- commandes Proxmox spécifiques à LXC : pct (pct help).

Un appel à man suivi du nom de la commande vous donnera plus d'informations.

Viennent s'ajouter :

- les commandes spécifiques à KVM : qm (man 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.

17 - Options avancées

17-1 - Gestion de pools

Un pool est un regroupement de ressources. Celui-ci vous permettra de centraliser et donc faciliter la gestion d'une partie du datacenter.

17-1-1 - Création d'un pool

Pour créer un pool, il vous faudra vous rendre dans le menu datacenter → Permissions → Pools, puis créer :

Il vous faudra ensuite entrer le nom du pool :

Le pool apparaître ensuite sur la gauche en dessous des serveurs :

En allant dans l'onglet Membres, vous pourrez voir que le pool est vide.

17-1-2 - Gestion d'un pool de ressources

Dans le pool nouvellement créé, vous pourrez ajouter :

- des stockages ;

- des VM ou des conteneurs.

Pour ajouter un élément au pool : clic sur le pool → Membres → créer :

Exemple d'ajout de machine virtuelle :

Vous pourrez sélectionner une ou plusieurs VM du datacenter, quel que soit le serveur l'hébergeant si vous en avez plusieurs en cluster.

Vous pouvez également intégrer des conteneurs. Le menu d'ajout ne propose pas d'ajouter spécifiquement un conteneur, il faudra choisir machine virtuelle. Vous pouvez voir un conteneur sélectionnable dans l'image ci-dessus.

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.

17-2 - Montage offline d'images disque

Il est possible de monter une image disque d'une VM 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.

17-2-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.

17-2-2 - Montage d’une image disque au format KVM qcow2

Cela se fera via 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 les afficher 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

17-2-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.

17-2-4 - Montage hors ligne du disque d'un conteneur

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 : (aucun périphérique de loopback utilisé ici, à adapter selon le retour de la commande losetup)

/dev/loop0

Nous montons donc notre image après l'avoir lié à /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

17-3 - Gestion de certificats

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 « Upload Custom Certificate ». Vous pourrez alors uploader le fichier de certificat 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 renseigner les domaines à certifier (éditer les domaines), et l'adresse mail qui sera liée aux certificats (compte d'enregistrement).

17-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.

Proxmox ne prévoit pas la possibilité de changer le port de son interface Web. Ceci reste possible via l'utilisation de Nginx monté en proxy par exemple.

17-5 - Authentification via LDAP ou Active Directory

Proxmox permet l'authentification via un serveur LDAP ou Active Directory. Pour cela, il faudra aller dans datacenter → Permissions → Authentification, ajouter.

Je trouve l'intérêt réduit, car ces services ne gèrent que l'authentification, pas les autorisations. Il vous faudra donc créer une correspondance en créant des droits (utilisateurs/groupes).

Il est logique que la correspondance ne puisse pas être faite pour les droits. Comment savoir qu'un utilisateur de l'AD a le droit de lancer une VM, ou de la sauvegarder ?

17-6 - 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 clé USB contenant une clé privée, une empreinte digitale, ou un token.

Proxmox gère deux systèmes pour l'authentification à deux étapes :

- une Yubikey (clé USB d'authentification de la société Yubicon) ;

- Oath.

17-6-1 - Activer l'authentification Oath

Il va falloir commencer par créer la clé Oath. Proxmox fournit un outil en ligne de commande pour cela : oathkeygen qui vous retournera un id comme 7FUAWH2J2J2FLPAD.

Vous pourrez également utiliser l'outil qrencode permettant la création d'un QR-code qui pourra ensuite être utilisé par un client 2FA (sur votre smartphone par exemple).

Exemple de code pour générer une clé et son QR-Code :

root@srv1:~# clear && OATHKEYID=$(oathkeygen) && echo -e OATH key ID for $USER: $OATHKEYID && qrencode -t ANSIUTF8 -o - $(echo "otpauth://totp/PVE:$USER@"$(hostname --fqdn)"?secret=$OATHKEYID")
OATH key ID for root: 7FUAWH2J2J2FLPAD
█████████████████████████████████████████
█████████████████████████████████████████
████ ▄▄▄▄▄ █ ▄▄ █▄▄ █▀███▄██▄█ ▄▄▄▄▄ ████
████ █   █ ██▄█▀▀▄█▀▀█ ▄▄ ██▀█ █   █ ████
████ █▄▄▄█ █ ▀▀▄ ▀▀▄ ▄▄█ ▀ ███ █▄▄▄█ ████
████▄▄▄▄▄▄▄█ ▀▄█▄▀▄█▄█ ▀ █▄▀▄█▄▄▄▄▄▄▄████
████▄▄▄▀▀ ▄▀ ▄█▄ ▄█▄ ▀  █▀█ ▀ ▄ ▄▀█  ████
████ █▄▀▄▄▄▄█▄ ▀ ▄ ▀ ▄█▄▀▄▄ █▄▄▀▀▀▄▀▄████
█████ ▄ ▀ ▄ █  ██  ██ █▀█▀█ ▀▀▄▄█▀█▄ ████
████ ▀ ▀▀▄▄▄▀  ▄█▀█▄█▀ ▄ █▀▄▄█ ▄▄ ▄█▄████
█████▄   █▄▀███▄ ▄█▄ ▀▀ ▀▀█▄ █▄▀█▄▀  ████
████▄▄██▀▀▄█▄ ▄▀ ▄ ▀  ▀▄▀▄▀▄ ▀▄ ▄▄▄█▄████
█████▀▄▀▀▀▄██▀▄██  █▄▀▄  ██ ▀  ▀██▀▀ ████
████▄▄ ▀▄▀▄▀▄▄█▄█▀█▄▀ █ ▄▄▀ ▀▄▀▀▀▄█▀ ████
████▄▄█▄▄▄▄▄▀ ▀▄ ▄██ █  ▀▀ █ ▄▄▄  ▀█▀████
████ ▄▄▄▄▄ █▀▀ ▀ ▄ ▀█ ▀ ██▀▀ █▄█ ███ ████
████ █   █ ███ ██  ██▄   █▀   ▄▄  ▀▄▀████
████ █▄▄▄█ █ █ ▄█▀█▄█▄▀▄▀█ █▀███▄▀█▄▄████
████▄▄▄▄▄▄▄█▄▄▄▄▄▄█▄███▄▄███▄▄██▄███▄████
█████████████████████████████████████████
█████████████████████████████████████████
root@srv1:~#

qrencode n'est pas installé par défaut, il vous faudra l'installer.

Une fois votre clé créée, il faudra aller activer l'authentification à deux étapes. Pour cela, allez dans datacenter → Permissions → Authentification :

Cliquez ensuite sur la méthode d'authentification que vous utilisez (par défaut PAM ou PVE). Nous nous baserons sur la méthode utilisée par défaut à savoir le compte root@pam.

Après double-clic sur la ligne « pam », nous aurons la fenêtre suivante :

Il faudra aller dans le menu déroulant TFA, et sélectionner OATH, vous pourrez jouer sur le temps de validité d'une tentative de connexion (30 secondes par défaut), ainsi que la longueur minimale du mot de passe.

À la prochaine déconnexion, OATH sera nécessaire pour vous authentifier. Il est donc impératif d'avoir généré la clé et que celle-ci soit renseignée (procédure vue ci-dessus).

À la prochaine connexion, vous aurez l'écran suivant :

17-6-2 - Activer l'authentification Yubico

Le principe est le même que pour Oath. L'écran des réglages vous demandera :

- un ID API Yubico ;

- une clé d'API Yubico ;

- une URL Yubico.

Il faudra être en possession d'une clé Yubikey.

Vous pouvez utiliser les serveurs d'authentification Yubicloud ou votre propre serveur d'authentification.

17-6-3 - Dépannage de l’authentification à deux facteurs

Si vous perdez l'accès à l'authentification à deux facteurs, vous pouvez la désactiver en supprimant le fichier /etc/pve/domains.cfg.

17-7 - Suppression message de licence

Lors de la connexion, vous avez un message « Aucune clé d'enregistrement valide » :

Le message est désactivable en modifiant le code dans le fichier /usr/share/pve-manager/js/pvemanagerlib.js. Proxmox étant open source, rien ne s'y oppose.

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.

17-8 - Mise à jour Proxmox 5 vers Proxmox 6

Avant toute chose, il faudra effectuer des sauvegardes des VM. Si vous avez plusieurs nœuds, envisagez de déplacer les VM sur un autre avant de faire une mise à jour.

Si vous utilisez plusieurs serveurs en cluster, il vous faudra commencer par faire la mise à jour de Corosync.

Opération à effectuer sur tous les nœuds.

Ajoutez le dépôt suivant à votre fichier /etc/apt/source,list :

deb download.proxmox.com/debian/corosync-3 stretch main

Stopper corosync sur tous les nœuds :

systemctl stop pve-ha-lrm
systemctl stop pve-ha-crm

Puis, effectuez la mise à jour proprement dite :

apt-get update
apt-get upgrade

Vous pourrez ensuite redémarrer les services pve-ha-lrm et pve-ha-crm sur tous les nœuds.

Une fois corosync à jour, effectuez la mise à jour vers Debian Buster et Proxmox 6.

La mise à jour se fera en mettant à jour le fichier /etc/apt/source,list. Il faudra remplacer les occurrences de stretch par buster, télécharger le fichier de clé comme expliqué au chapitre 1, puis faire la mise à jour comme suit :

apt-get update
apt-get upgrade

18 - Conclusion

Certaines fonctionnalités sont absentes (mais leur fréquence d'utilisation ne nécessite peut-être pas l'accès depuis l’interface graphique). J'ai constaté des problèmes de stabilité, peut-être dus à mon environnement de test, comme l'upload d'ISO, ou l'échec apparent de certaines fonctionnalités (faux positif lié à un problème de rafraîchissement).

Il ne faut pas hésiter à utiliser la ligne de commande en complément.

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 (bien que Docker apporte plus de fonctionnalités).

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.

18-1 - Remerciements

Je remercie LittleWhite pour sa relecture technique ainsi que ClaudeLELOUP pour sa relecture orthographique.