La virtualisation n'est plus aujourd'hui réservée à une infrastructure à base de Microsoft Hyper-V ou VMWare Vsphere. Il en existe beaucoup d'autres, dont celui que je vais déployer dans les pages qui suivent : Proxmox.
Proxmox est un hyperviseur de type 1, pouvant être utilisé en mode bare-metal donc directement installable sur une infrastructure matérielle et capable de la piloter. A contrario, les systèmes de virtualisation orientés utilisateurs comme VirtualBox ou VMWare Player/Workstation, requièrent pour leur part un système d'exploitation sur lequel s'appuyer pour fournir des solutions de virtualisation, certes fonctionnelles, mais moins efficaces car devant être traduite par l'OS qui les supporte.
Proxmox est basé sur un noyau Debian embarquant les systèmes Qemu pour la virtualisation, ainsi que KVM, la gestion des containers, une interface de gestion, la possibilité de réaliser des sauvegardes directement depuis cet environnement, ainsi que beaucoup d'autres choses telles que les clusters et le passthrough pour améliorer la gestion des accès disques et la sécurité des données et des accès.
Proxmox est un système extrêmement complet, mis à disposition sous forme de kit d'installation communautaire, donc sans support autre que l'Internet. Il existe évidement une autre solution d'usage, faisant appel à un mode de licence et de support payant, garants de réactivité importante dans les résolutions de problèmes et le suivi des évolutions de version.
Pour nos besoins généraux, la solution communautaire est largement suffisante et nous permet de réaliser absolument tout ce dont nous avons besoin, voire même plus encore.
Documentation officielle : https://pve.proxmox.com/wiki
Les drivers VirtIO sont dédiés à KVM et permettent aux machines virtuelles hébergées par Proxmox de pouvoir utiliser directement des périphériques, sans passer par des versions émulées des pilotes de périphériques. Les drivers sont spécifiquement conçus pour les environnements Windows.
Pour rappel, lorsque vous mettez en place des machines virtuelles avec les environnements Windows, choisissez des périphériques VirtIO plutôt que les versions émulées. Cela sera meilleur pour la planète (ah bon ?)... En tous les cas cela permettra d'obtenir de meilleures performances à l'usage.
Télécharger les versions stables ici : https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers
Et en fin de mise en place de Windows, n'oubliez-pas d'installer les Qemu-Guest (virtio-win-guest-tools), disponibles sur l'ISO que vous avez téléchargé précédemment pour pouvoir interagir avec la VM depuis Proxmox et de récupérer, notamment, l'IP privée que vous pourrez consulter dans le Résumé de la VM.
Une fois que Proxmox est installé, il est relativement simple de créer un cluster hyper convergé avec cet hyperviseur. Pour la suite des opérations, nous appellerons noeud tout serveur physique composant le cluster. Il est fortement recommandé à ce niveau de disposer de plusieurs cartes réseau afin de séparer les flux entre le cluster, le stockage, les autres VMs, ... Généralement au moins 3 ports réseau sont donc utilisés, et plus si possible.
Depuis le serveur qui va être le premier noeud du cluster, cliquez sur le menu Datacenter, puis Cluster et Create a cluster.
Renseignez le nom du cluster et l'IP avec laquelle vous souhaitez communiquer avec le cluster, cliquez sur le bouton Create
Toujours dans la rubrique Cluster, cliquez sur le bouton Join Information pour obtenir la clé de connexion au cluster et appuyez sur le bouton Copy information pour la stocker dans le presse papier.
ATTENTION : pour joindre un cluster, le serveur que vous allez ajouter doit être vierge de toute VM ou de tout container.
Maintenant, depuis le deuxième serveur, celui qui va être intégré au cluster que nous venons de mettre en place, toujours depuis son menu Datacenter, cliquez sur la rubrique Cluster et sur le bouton Join a cluster.
Copiez la clé obtenue lors de l'étape précédente, saisissez le mot de passe du premier serveur et cliquez sur le bouton Join en bas à droite de cette fenêtre. Le bouton portera le nom que vous aviez défini pour le cluster au départ des opérations.
A la fin des opérations, après probablement une déconnexion de l'interface de gestion de Proxmox, les deux noeuds du cluster devraient apparaître dans la liste des serveurs.
L'intérêt du cluster est de pouvoir déplacer les machines virtuelles - ou les containers - d'un noeud sur l'autre pour réaliser des opérations de maintenance par exemple. Pour cela il suffit de cliquer sur une VM, de choisir le noeud de destination et de cliquer enfin sur le bouton Migrate.
Sur le noeud à conserver, ouvrir un shell et saisir les commandes suivantes :
$ pvecm nodes
Affichage de la liste des noeuds disponibles dans le cluster
$ pvecm delnode <node>
Supprime la référence du noeud du cluster
$ pvecm expected 1
Informe le noyau qu'il n'y a pas de quorum restant
$ systemctl stop pve-cluster
Provoque l'arrêt du cluster
$ pmxcfs -l
Démarre le cluster en mode local
$ rm -f /etc/pve/cluster.conf /etc/pve/corosync.conf
Suppression des fichiers de configuration du cluster
$ rm -f /etc/cluster/cluster.conf /etc/corosync/corosync.conf
Suppression des fichiers de configuration du cluster
$ rm /var/lib/pve-cluster/.pmxcfs.lockfile
Suppression du fichier qui contenait la clé de jonction au cluster
$ systemctl stop pve-cluster
Arrêt du cluster
$ reboot
Durant la création du container, il faut décocher la case Unprivileged container
. Dans notre exemple nous partons sur une installation
Ubuntu standard, template que nous avions au préalable chargé dans le repository local de notre
serveur Proxmox. 
. Tout le reste a été paramétré basiquement pour
les besoins de la démonstration.
Une fois le container créé (en quelques secondes si vous avez une machine convenable), et avant de
démarrer le container, allez dans Options > Features puis appuyez sur le bouton Edit.
. Cochez ensuite les options de partage que vous souhaitez prendre
en compte. Dans notre cas, nous n'avons qu'un partage Samba donc nous ne prenons que SMB/CIFS.
. Cela modifier les Features en précisant que vous allez
disposer d'un montage de type CIFS. 
.
Cependant, pour pouvoir utiliser un montage de disque différent de ceux généralement rencontrés sur les environnements Linux/Unix (NFS et FUSE par exemple), il faudra disposer du helper mount.cifs pour utiliser le partage SAMBA/CIFS. Si vous n'en disposez pas, et donc vous n'avez pas le fichier /sbin/mount.cifs, il vous faut l'installer par
$ sudo apt get update
$ sudo apt get install cifs-utilsCommencez par créer un répertoire pour accueillir le point de montage du partage.
$ sudo mkdir /mnt/sharedir$ sudo mount -t cifs -o username=share_user //windows_share_ip/share_name /mnt/sharedirVous pouvez également fournir le mot de passe dans le commande mount par
$ sudo mount -t cifs -o username=share_user,password=share_password //windows_share_ip/share_name /mnt/sharedirPour accéder à un partage sur un domaine :
$ sudo mount -t cifs -o username=share_user,domain=windows_domain,password=share_password //windows_share_ip/share_name /mnt/sharedirPour des raisons de sécurité, fournir des mots de passe sur une ligne de commande est peu recommandé. Il est conseillé de passer par un fichier contenant les credentials que vous seul pouvez lire. Le format est le suivant (en supposant que le fichier s'appelle /etc/wincreds) : username=share_user password=share_password domain=windows_domain Enregistrez le fichier et changez ses droits par
$ sudo chown root: /etc/wincreds
$sudo chmod 600 /etc/wincreds$ sudo mount -t cifs -o credentials=/etc/wincreds //windows_share_ip/share_name /mnt/sharedirATTENTION : par défaut le montage est propriété de root et les droits des fichiers sont de 0777. Les options dir_mode et file_mode de la commande mount permettent de gérer ces droits d'accès
$ sudo mount -t cifs -o credentials=/etc/wincreds,dir_mode=0755,file_mode=0755 //windows_share_ip/share_name /mnt/sharedirPour automatiser le montage, il faut inscrire l'équivalent de la ligne de commande de montage dans le fichier /etc/fstab. Pour cela,
$ sudo nano /etc/fstab
//windows_share_ip/share_name /mnt/sharedir cifs credentials=/etc/wincreds,file_mode=0755,dir_mode=0755 0 0$ sudo mount -aUne fois que le point de montage n'est plus utile, il est possible de le démonter en faisant
$ sudo umount /mnt/sharedir$ sudo fuser -m /mnt/sharedirSi vous avez Proxmox alors vous disposez d'un espace de stockage. Celui-ci peut être amené à évoluer en ajoutant des disques et Proxmox sait bien se débrouiller dans ce genre de situation. Il suffit juste de savoir comment faire...et cette page est là pour vous aider justement (c'est bien fait le hasard tout de même...)
Pour utiliser un disque, une fois inséré dans votre serveur, il faut que celui-ci soit vierge.
Commencez par aller dans l'interface graohique pour voir si votre disque est bien reconnu et cliquez
sur le noeud Proxmox > Disks. Cela va vous afficher la liste des disques et partitions pris en charge par
Proxmox. Dans mon cas, un seul disque dur pour supporter l'OS et le stockage des VMs.
Commencez par trouver le disque physiquement dans la liste des disques disponibles. Lancez un shell et faîtes une commande d'initialisation de disque (remplacez /dev/sdb par le device de votre périphérique)
$ sudo fdisk /dev/sdbDepuis le menu DataCenter de Proxmox, allez sur Storage et Add. Prenez l'option SMB/CIFS pour utiliser un partage réseau de type NAS. Identifiez-vous et sélectionnez le contenu que va gérer ce partage. Pour faire simple nous allons supposer que ce NAS va nous permettre de stocker l'intégralité des formats de stockage proposés (Disk image, ISO image, Container templates...). Le stockage ainsi défini pourra être utilisé depuis n'importe lequel des serveurs faisant partie d'un cluster par exemple.
Si vous supprimez un disque pour réaffecter l'espace disque à Proxmox (par exemple le disque local-lvm qui est dédié par défaut au thin provisionning pour les VMs), il faut exécuter les commandes de gestion du LVM depuis le shell du serveur en question. Nous allons supprimer le disque, puis redimensionner l'espace alloué au gestionnaire LVM et enfin redimensionner la partition.
$ lvremove /dev/pve/data
$ lvresize -l +100%FREE /dev/pve/root
$ resize2fs /dev/mapper/pve-rootLe stockage ZFS peut être mis en High Availability et fonctionner comme le réplica d'Hyper-V. C'est ce que nous allons faire ici.
Il vous faut tout d'abord disposer d'un environnement avec 3 noeuds proxmox, de préférence avec chacun deux cartes réseau :
Pour monter le cluster, procédez comme suit. Sur chaque noeud devant participer au cluster, cliquez sur Datacenter > Cluster, puis :
Le NOM utilisé pour le stockage ZFS DOIT ETRE LE MEME sur toutes les machines
Faire Datacenter > Storage et choisir le stockage ZFS précédemment créé. Dans la combobox Nodes, sélectionner tous les noeuds disposant de ce stockage.
Lors de la création de VM, bien penser à affecter le stockage de cette VM sur le stockage ZFS que nous avons mis en place. Une fois la VM prête à l'emploi, il est possible de procéder à la gestion de sa réplication. Il faut aller sur VM > Replication > Add. Dans la fenêtre de paramétrage, vous pouvez spécifier le rythme de la réplication. Répétez l'opération autant de fois qu'il y a de VM et de serveurs à faire participer à la réplication.
Datacenter > HA > Add et ajoutez la ou les VM créées pour que les réplications s'effectuent sur les serveurs concernés.
Passer sous le shell et faire
$ zfs destroy zfs-poolSur un cluster Proxmox, une VM peut être mise en mode haute-disponibilité. Ce que cela signifie ? Simplement que si jamais un noeud s'arrête, les VM qu'il exécute seront reprise en charge par un autre noeud du cluster. Le temps d'indisponibilité sera réduit au strict minimum, à savoir le transfert de la partie RAM des VM puisque normalement le stockage est censé se situer sur un espace partagé.
Pour mettre une VM en mode HA (High Availability) il suffit de sélectionner le noeud où se trouve la VM > HA et faire Add au niveau de la partie Ressources. ATTENTION : il faudra avoir signalé à Proxmox, dans la partie Datacenter > Options > HA Settings de basculer dans la policy shutdown_policy=migrate.
En préambule à la configuration d'un cluster, sachez qu'il vous faut :
Nous utilisons un ensemble de 3 noeuds et le stockage s'effectue par l'intermédiaire du système de fichiers distribué Ceph. Sur le noeud 1, on clique sur Datacenter > Ceph > Install Ceph. Dans l'étape Info sélectionner la version reef qui est un peu plus rapide que la version quincy. Sélectionner également le repository No-Subscription. Une fois l'installation terminée, Ceph nous propose la configuration de son environnement de réseau. Par défaut, Ceph dispose de deux réseaux :
Il faut maintenant répéter les mêmes actions sur le reste des noeuds de votre cluster. Lors de la mise en place de Ceph sur les autres noeuds, il sera affiché que la configuration est déjà initialisée. C'est une bonne information car cela signale que les machines sont bien en phase avec la configuration attendue. Le warning sur la configuration de Ceph est lié au fait que le moniteur n'a pas été déclaré pour les autres noeuds. Pour cela, sur chaque noeud > Ceph > Monitor, puis bouton Create en sélectionnant le moniteur Ceph sur le noeud en cours d'installation. Le principe de Ceph est d'être son propre gestionnaire de cluster (vous libérant du principe de quorum) donc un moniteur sur chaque noeud Ceph est la bonne pratique.
Maintenant que nous avons les managers, on peut créer le pool en allant, depuis le noeud 1, sur l'option Ceph > Pools et appuyer sur le bouton Create. Mettre un nom pour le pool (du genre proxpool ou équivalent) et Create. C'est par ce biais que nous pouvons disposer d'un environnement hautement disponible car chaque noeud partage automatiquement le pool et toute VM mise dans cet espace partagé pourra migrer automatiquement en cas de problème d'un noeud.
Sur chaque noeud du cluster, cliquer sur OSD > Create: OSD. Il n'y a rien à changer dans la configuration proposée.
Par contre, la notion de manager est différente. Son rôle est de gérer l'interface principale de la GUI Ceph et de porter l'IP d'accès. Il dispose de sa propre GUI installable depuis un shell lancé sur la machine portant le moniteur et
$ apt install ceph-mgr-dashboardceph mgr module enable dashboardceph dashboard create-self-signed-certecho MOT_DE_PASSE_SECURISE > passwd.txt
ceph dashboard ac-user-create admin -i passwd.txt administratorceph mgr module disable dashboard
ceph mgr module enable dashboardSur la partie Datacenter de Proxmox, dans la rubrique HA, il faut créer un groupe par Datacenter > HA > Groups > Create. Sélectionner tous les noeuds devant faire partie de ce groupe. Mettre un nom qui signifie l'usage du groupe (HAgroup par exemple). La notion de Restricted signifie que, si vous avez une VM qui est attachée à un hardware particulier (video passtrhough ou NIC passthrough par exemple) elle ne devra pas migrer car le hardware ne sera probablement pas disponible sur un autre noeud. Le paramètre NoFallBack signale qu'une VM neprendra pas sa position initiale lorsque la ressource hardware est de nouveau disponible après un crash de noeud.
Lors de l'affectation de disques au stockage Proxmox, il est généralement conseillé de réaliser un effacement du disque avant son utilisation. En cliquant sur le nom de votre hyperviseur puis Disks, vous affichez la gestion des disques. Le bouton Wipe Disk se situe en haut à droite de l'interface.
Si vous obtenez une erreur du type sdx has a holder (500), cela va vous bloquer pour l'usage de ce disque. Les 4 solutions possibles à ma connaissance :
pvs et supprimez le groupe de volumes
présent sur le disque avec la commande vgremovedmsetup ls et supprimez le
mapping avec la commande dmsetup remove <id du mapping>
Une autre situation pouvant survenir est que vous récupérez des disques SAS et qui ne sont pas
utilisables en l'état dans Proxmox à cause des structures et protections spécifiques au SAS. Sous Linux,
utilisez la commande sg_format disponible dans le paquet sg3-utils
pour réaliser un formatage de vos unités disques. Utilisez au préalable la commande sg_scan -i
pour identifier les périphériques. Toutes les commandes de ce paquet sg3-utils sont relatives à la manipulation
des périphériques SCSI.
Proxmox stocke ses fichiers de configuration à plusieurs endroits selon le type de machine :
zfs list. Il n'y a pas de point de montage mais restent accessibles comme n'importe quel autre disque
depuis /dev comme /dev/zvol/<pool>/...
En cas de problème avec la GUI de Proxmox, il est toujours possible de se connecter à l'hyperviseur par SSH et de générer de nouveaux
certificats par exemple avec pvecm updatecerts. De nouveaux certificats sont disponibles dans /etc/pve/local.
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_certs_api_gui https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_examples_11
Si le fichier de configuration d'une VM affiche une information du genre scsi0: local:1000/vm-1000-disk-0.qcow2,size=250G alors
Il vous faut regarder le chemin /var/lib/vz/images/1000/vm-1000-disk-0.qcow2 pour trouver le disque virtuel. Vérifiez avec la commande
pvesm path local:1000/vm-1000-disk-0.qcow2.
Pour réaliser un backup d'une VM, sans passer par l'interface graphique de Proxmox, vous pouvez utiliser la commande vzdump.
Avant de commencer la mise à jour assurez-vous d'avoir réalisé des sauvegardes de vos conteneurs et VMs. Depuis DataCenter > Backup créez un job de sauvegarde ou faites les sauvegardes manuellement.
Les informations sur les différentes roadmaps et méthodes de mise à jour se trouvent sur le Wiki : https://pve.proxmox.com/wiki/Downloads.
Proxmox est par défaut configuré pour récupérer les mises à jour des packages Entreprise mais cela requiert une licence que nous ne
possédons pas. Il nous faut remplacer cette licence par celle sans souscription. Pour cela, cliquer sur le nom du serveur puis
Updates > Repositories.
On peut voir que la licence Entreprise est présente. On commence par ajouter la licence *No Subscription* par un appui sur le
bouton *Add*
Sélectionnez maintenant le paquet entreprise pour ne plus le prendre en charge dans les mises à jour et appuyez sur *Disable*
Il est maintenant temps de lancer les mises à jour en cliquant sur le nom du serveur Proxmox > Updates.
Cliquer ensuite sur *Refresh* (ne faites pas attention aux erreurs liées aux licences entreprise) puis *Upgrade*.
Pour réaliser la même opération avec l'interface du Shell, il faut éditer le fichier */etc/apt/sources.list.d/pve-entreprise.list* et mettre un '#' en début de ligne pour mettre le paquet en commentaire. Editer également le fichier */etc/apt/sources.list* et ajouter la ligne correspondant au mode *no subscription*
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscriptionapt update et s'il n'y a pas d'erreur mettez à jour les
packages par apt dist-upgrade
Rebootez et vérifiez que les versions correspondent à celles attendues avec la commande pveversion -v
Un container est surtout utilisé pour sa capacité de donner accès à des micro services. Un container LXC pour un grand nombre d'activités est déjà existant et facilement téléchargeable et installable sur le Proxmox local. Avant d'utiliser un container LXC, il faut s'assurer de disposer de son template en local sur le disque. Un certain nombre de templates sont disponibles depuis local > CT Templates.
La mise en place d'un container ne diffère que de peu de choses par rapport à une VM classique :
Un des avantages certains des containers sur les VMs est que le container va démarrer beaucoup plus vite qu'une VM. Par exemple, pour installer docker simplement il suffirait (exemple tiré de Nginx Proxy Manager):
curl -sSL https://get.docker.com/ | sh pour récupérer
le script d'installation de docker et de procéder à son installation automatiquementmkdir -p ~/docker/npm)
puis faire un cd ~/docker/npm. Créer ensuite un fichier docker-compose.ymlversion: '3.8'
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
ports:
# These ports are in format <host-port>:<container-port>
- '80:80' # Public HTTP Port
- '443:443' # Public HTTPS Port
- '81:81' # Admin Web Port
# Add any other Stream port you want to expose
# - '21:21' # FTP
# Uncomment the next line if you uncomment anything in the section
# environment:
# Uncomment this if you want to change the location of
# the SQLite DB file within the container
# DB_SQLITE_FILE: "/data/database.sqlite"
# Uncomment this if IPv6 is not enabled on your host
# DISABLE_IPV6: 'true'
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencryptdocker compose up -d qui va lire le fichier docker-compose.yml
précédemment créé et installer le reverse proxy nginx sur Docker..Se rendre sur le noeud à protéger par un certificat et accéder à la rubrique System > Certificates. Il va nous falloir générer un certificat pour pouvoir l'uploader sur Proxmox.
Pour créer le certificat, on passe par OpenSSL. Commencer par vérifier que openssl est installé sur votre système (pas celui de Proxmox mais un autre)
comme une machine linux par exemple. Faites openssl version. Si la commande renvoie une information c'est tout
bon sinon il faudra procéder à l'installation de la bibliothèque OpenSSL.
On commence par générer une clé privée pour l'autorité de certification :
openssl genrsa -aes256 -out ca-key.pem 4096Maintenant que nous avons une clé pour notre autorité de certification, créons cette autorité...
openssl req -new -x509 -sha256 -days 3650 -key ca-key.pem -out ca.pemMaintenant nous devons générer le certificat autosigné. Pour cela nous faisons comme pour la clé privée de l'autorité de certification
openssl genrsa -out cert-key.pem 4096Ensuite il nous faut créer une demande de génération de certificat, adressée à notre autorité privée.
openssl req -new -sha256 -subj "/CN=proxmox" -key cert-key.pem -out cert.csrUne partie importante maintenant est de créer un fichier de configuration nommé extfile.cnf de la façon suivante
echo "subjectAllName=DNS:proxmox.domaine.tld,IP:192.168.1.42" << extfile.cnfMaintenant tous les éléments sont réunis pour pouvoir créer le certificat autosigné.
openssl x509 -req -sha256 -days 3650 -in cert.csr -CA ca.pem -CAkey ca-key.pem -out cert.pem -extfile extfile.cnf -CAcreateserialSur Proxmox, il nous faudra renseigner une chaine spécifique que nous créons comme suit :
cat cert.pem >> fullchain.pem
cat ca.pem >> fullchain.pemDans l'interface de Proxmox > System > Certificates, faire Upload Custon Certificate pour obtenir une fenêtre avec deux zones à remplir. La première attend la copie du contenu du fichier cert-key.pem. La seconde zone attend la copie de la chaine de certificats que nous avons générée dans le fichier fullchain.pem.
Maintenant il faut faire en sorte que notre navigateur reconnaisse ce certificat comme valide. Il suffit d'enregistrer le fichier ca.pem avec une extension *.crt comme par exemple ca.crt. Cela va permettre sous Windows d'intégrer automatiquement le certificat en sélectionnant la destination Local Machine (Ordinateur local) puis le store Trusted Root Certification Authorities
La configuration du noeud Proxmox s'effectue depuis System > Network
Les notions de Linux Bridge sont équivalentes aux notions de virtual switches. Les bridges reposent sur l'utilisation d'une carte réseau physique sous-jacente et seront disponibles pour les machines virtuelles ou les clusters. Le nom d'une carte réseau, comme enp2s0, est toujours composé (sous Proxmox / Debian en tous les cas), par le type de carte en, le port physique p, le numéro du port 2 et enfin par le numéro du slot dans lequel se trouve la carte physique s0. Le port physique peut être référencé par p pour un port PCI ou o pour une carte onboard, ou u pour une carte réseau USB.
Si plusieurs cartes réseaux doivent être supportées pour un bridge, vous pouvez créer un OVS Bond pour améliorer les performances et disposer de liens de secours si une carte venait à ne plus fonctionner.