Astuces Proxmox

Sommaire

Introduction inutile (?)
Conseils avant l’installation
Création d’un espace de stockage en LVM/Thin provisioning
Changer l’ID d’une VM
Changer le nom d’une VM
Supprimer le lock (verrou) sur une VM
Monter un disque d’une VM sur le proxmox (ou ailleurs) pour dépannage
Importer une VM (disque raw ou qcow2)
En cas de problèmes d’affichage des statistiques
Augmenter la taille d’un disque à chaud (y compris le disque système !)
Supprimer l’avertissement concernant la licence/support
Réduire l’espace occupé par les images disque au strict nécessaire

Introduction

En matière de virtualisation, les ESX (hyperviseurs vmware) ont encore un quasi monopole. Mais devant les avantages des solutions 100% libres comme proxmox, cela pourrait bien changer. Des versions « gratuites » d’ESX existent bien, mais elles sont très limitées, et dès que vous voudrez faire quoi que ce soit de plus que de lancer une VM (par exemple la sauvegarder de façon efficace…) il vous faudra passer aux versions payantes et aligner des dizaines de milliers d’euros en licences diverses. Alors oui, proxmox reste plus limité d’un point de vue fonctionnalité, mais pour des besoins simples il semble beaucoup plus adapté. Je vous laisse regarder des comparatifs ici ou la.

Si vous ne connaissez pas du tout proxmox et si vous voulez savoir ce qu’il vaut par rapport à un ESX, je vous conseil cet article. Notez qu’il a plus de 2 ans, et que certains des remarques formulés ne sont plus exactes. L’absence de sauvegarde non incrémentales des VMs par exemple sera vite un mauvais souvenir avec l’arrivée de Proxmox Backup (actuellement en beta). Les fonctionnalités promises sont plus qu’alléchantes !

Après avoir installé mon premier proxmox en production et avec maintenant un an de recul, j’ai décidé d’écrire ce billet pour rassembler quelques « trucs et astuces » qui m’ont bien rendus services. Ces tutos fonctionnent parfaitement en utilisant la version actuelle (6.2) de proxmox VE.

Conseils avant l’installation

Voila ce que j’aurai bien aimé savoir avant d’utiliser la solution en production:

Ne pas se tromper sur le hostname

Il faut savoir que le nom de la machine est automatiquement utilisé dans la configuration de proxmox. Le contenu du fichier /etc/hostname est donc très important, car il est TRÈS difficile de modifier ce nom après coup. (et quand je dis très difficile, je parle de devoir tout arréter, de devoir modifier le contenu de base sqlite etc). De plus, le modifier sur un serveur « standalone », avec toutes les VM arrêtées n’est déjà pas facile, mais modifier ce nom sur un noeud qui fait parti d’un cluster semble être réellement mission impossible. « Il y en a qui ont essayé, ils ont eu des problèmes ! » Bref, pour vous éviter bien des soucis par la suite, choissisiez judicieusement le nom de votre serveur dès le départ, en étant certain que vous n’aurez jamais besoin de le changer.

Bien choisir son système de stockage

Le choix du système de stockage que vous allez utiliser pour vos VMs est vraiment déterminant. Par défaut, c’est du LVM/thin provisioning qui est mis en place. C’est parfait lorsque vous n’avez qu’un seul hyperviseur, mais ne sera sûrement pas le meilleur choix dans une optique de cluster, avec la volonté de basculer des machines virtuelles d’un serveur physique à l’autre par exemple.

La page du wiki de proxmox consacrée à cette problématique est très bien faite. Je recopie ici le tableau le plus important, celui qui doit guider votre choix d’architecture et votre « sous système de stockage ». Dans ce tableau « shared » indique qu’il est possible d’avoir un stockage partagé entre plusieurs serveurs physiques, et donc de très simplement basculer une VM (ou un conteneur) d’un serveur à un autre (à condition que les snapshots soient également possibles). Dans tous les cas je vous conseil très vivement de toujours choisir une solution compatible avec les snaphots. Pouvoir prendre un instantané rapide d’une machine permet de faire la sauvegarde de cette VM sans l’arrêter ou un retour arrière rapide en cas de mise à jour problématique par exemple.

Comme vous pouvez le voir, ce ne sont pas les choix qui manquent. A vous de voir quelle solution est la plus adaptée à vos besoin et au matériel dont vous disposez. Les plus attentifs noteront l’absence de BtrFs. J’ignore si c’est lié, mais des tests assez poussés ont conclus que BtrFS se comporte (ou comportait ?) assez mal d’un point de vue performance pour l’hébergement de VMs.

D’ailleurs, en parlant de performances, il existe un petit outil intégré a Proxmox pour connaître l’efficacité de votre système de stockage. Le stockage en question doit être accessible au travers d’un point de montage. Dans cet exemple, il s’agit du répertoire /perf. Voila la commande à lancer et un exemple de résultat:

pveperf /perf
CPU BOGOMIPS: 134423.36
REGEX/SECOND: 2510150
HD SIZE: 9.78 GB (/dev/mapper/data-perf)
BUFFERED READS: 247.08 MB/sec
AVERAGE SEEK TIME: 4.30 ms
FSYNCS/SECOND: 4399.90
DNS EXT: 32.10 ms
DNS INT: 0.87 ms (cyberdef.net)

Rien de stupéfiant ici, Les résultats sont clairement moins bon que pour un SSD, mais nettement meilleur sur sur un disque dur standard puisqu’il s’agissait d’un raid de disques locaux tournant à 15K tours/minutes.

Création d’un espace de stockage en LVM/Thin provisioning

Par défaut, Proxmox utilise LVM en thin provisioning pour le stockage. Mais il n’utilise que le premier disque, celui sur lequel on fait l’installation. Dans une « vraie » configuration, vous allez forcément avoir des disques dédiées pour le stockage de vos VMs. Et ce sera à vous de choisir le type de stockage à utiliser (voir la section conseils tout en bas de ce billet) et son emplacement.

LVM/Thin est le meilleur choix pour les installations simples, ou le serveur Proxmox ne fera jamais parti d’un cluster. Ajouter un espace de stockage utilisant cette technologie est facile (vous pouvez par exemple aller voir un mini how to très bien fait ici). Mais ce billet oubli un détail. Lors de la création (ou plutôt conversion) du volume logique en « thin-pool », LVM crée en fait deux volumes. Le principal qui stockera réellement les données. Et un autre volume, plus petit, pour stocker les meta-donnéees du premier. C’est ce second volume qui stockera toutes les informations des snapshots etc. Or, par défaut, il semble que l’espace automatiquement alloué à ce second volume ne soit parfois pas assez important.

Je vous recommande donc de vérifier vous même la taille de ces volumes:

lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
base-201-disk-0 data Vri---tz-k 16.00g thin 
[lvol0_pmspare] data ewi------- 1.00g 
thin data twi-aotz-- 3.00t 10.79 2.09 
[thin_tdata] data Twi-ao---- 3.00t 
[thin_tmeta] data ewi-ao---- 1.00g 
vm-101-disk-0 data Vwi-aotz-- 20.00g thin 47.66 
vm-101-disk-1 data Vwi-aotz-- 60.00g thin 4.95 
vm-102-disk-0 data Vwi-aotz-- 20.00g thin 60.32 
vm-102-disk-1 data Vwi-aotz-- 60.00g thin 51.15
[...]

Observez cette sortie de commande, et plus particulierement les deux lignes du millieu. Ici le volume logique « principale » fait 3 To et s’appelle en réalité « thin-tdata ». Son volume pour ses meta-données s’appelle thin-meta et à une taille de 1Go. Cette taille, j’ai du l’augmenter moi même à 1 Go car au départ elle était beacoup plus petite. Pour faire cela, c’est exactement comme pour augmenter la taille de n’importe quel volume logique (ici on ajoute 1Go):

lvresize -L +1G /dev/data/thin_tmeta

Notez aussi que grâce à l’option ‘-a’ de lvs qui affiche l’ensemble des volumes logiques existants, on voit aussi des informations supplémentaires comme le taux de remplissage réel de ce volume (et donc l’espace réellement sur le disque en thin provisioning !). Par exemple le disque virtuel situé dans le volume logique « vm-101-disk-1 » (le second disque de la VM ayant l’ID 101), se présente comme un disque de 60 Go. Mais en réalité seul 4.95% de l’espace disponible est réellement occupé et donc réellement utilisé sur le disque. Tout le reste est utilisable par n’importe quel autre volume.

Changer l’ID d’une VM

Pour modifier la valeur de l’identifiant d’une machine virtuelle (par exemple pour passer de 200 à 201), suivez les étapes suivantes (ici le stockage utilisé est LVM/thin, le groupe de volume utilisé s’appelle data, et il n’y a qu’un seul disque dur, à vous d’adapter cette partie…):

Éteindre la VM
lvrename data/vm-200-disk-0 data/vm-201-disk-0
cd /etc/pve/nodes/proxmox/qemu-server/
mv 200.conf 201.conf
Éditer le fichier 201.conf pour modifier le nom des disques
Recharger l'IHM. (F5 sur le navigateur)
Relancer la VM. via l'IHM. C'est bon :)

Changer le nom d’une VM

Rien de plus facile, mais comme j’avais mis du temps à le trouver, je l’indique ici :

Cliquer sur la VM / Options / Éditer le nom

Supprimer le lock (verrou) sur une VM

En cas d’interruption d’une sauvegarde, un verrou se met en place, rendant toute nouvelle sauvegarde impossible. Pour retirer ce verrou (ici par exemple sur la vm ayant l’ID 102) utilisez la ligne de commande suivante :

qm unlock 102

Monter le disque d’une VM

Si une machine virtuelle ne peut plus être lancé pour une raison triviale (erreur dans le fichier /etc/fstab par exemple), il est évidement très pratique de pouvoir accéder au contenu de son disque directement depuis l’hyperviseur. L’exemple qui suit utilise un stockage en mode LVM/Thin, mais le principe sera le même quel que soit le type de stockage utilisé:

Localiser l’image disque de la VM, et observer le partitionnement de ce disque. Ici il s’agit du premier disque de la VM ayant l’ID 101, un volume logique qui se trouve dans le groupe de volume nommé data:

fdisk -l /dev/data/vm-101-disk-0

Comme j’aime bien les choses simples, je ne fais toujours qu’une seule partition sur les disques « virtuels ». Comme pour les disques physiques, cette partition commence au secteur 2048 (ce que vous indique la commande fdisk -l). Pour monter le système de fichier en question, la commande est donc :

mount -o loop,offset=$((2048 * 512)) /dev/data/vm-101-disk-0 /mnt

Et voila. Le contenu du disque de votre VM est maintenant accessible dans le répéertoire /mnt. Vous n’avez plus qu’a effectuer les corrections nécessaires, démonter le disque et relancer la machine virtuelle:

umount /mnt ; qm start 101

ATTENTION : N’accédez JAMAIS à un disque en cours d’utilisation, donc un disque actuellement utilisé par une VM en cours de fonctionnement !

Importer une VM (disque raw ou qcow2)

Avant d’utiliser proxmox j’utilisai simplement kvm et le « gestionnaire de machines virtuelles » de debian. Je devais donc migrer toute ces VMs sur le nouveau serveur proxmox. Voici la méthode que j’ai employée pour le faire.

Si votre VM tourne encore sur l’ancien serveur, vérifier que le paquet qemu-guest-agent à été installé, sinon installez le. Vérifier aussi le contenu du fichier /etc/fstab. Sous proxmox les disques s’appelleront sda, sdb etc. (Il existe une autre façon de faire, mais elle est moins efficace). Puis éteignez votre VM, et copier (scp ?) le fichier disque au format raw ou qcow2 sur le serveur proxmox. Vous n’avez plus qu’a créer une nouvelle machine virtuelle qui utilisera le disque en question. Ici 200 est l’ID de la nouvelle VM. Choisissez celui que vous voulez à condition qu’il soit unique. Notez aussi que « disks-hdd » est le nom que j’ai donné au stockage dédié aux images disques dans l’IHM de proxmox. (Par défaut, proxmox fait un stockage « local » lors de l’installation)

qm create 200 --net0 virtio,bridge=vmbr0 --name webconf --bootdisk scsi0 --scsihw virtio-scsi-pci --ostype l26
qm importdisk 200 fichier_disque.qcow2 disks-hdd

Une fois la VM crée, allez dans l’IHM pour modifier ses propriétés en fonction des besoins (cpu, ram, ajout de carte réseau, « ajout du disque », ordre de boot etc.)
Activer aussi l’usage de qemu-guest-agent dans la section options:

Lancer la VM.
Vérifier si l’interface réseau à changée, et si oui adapter la conf réseau en conséquence.
Vérifier le bon fonctionnement de qemu-guest-agent. Pour cela, lancer en ligne de commande sur l’hyperviseur :

qm agent 200 ping

Si tout se passe bien, aucun message ne doit apparaître. Rebooter la VM si besoin pour prendre en compte des éventuelles modifications au niveau réseau. C’est bon !

En cas de problème d’affichage des statistiques

Il peut arriver que l’affichage des statistiques (cpu consommé, ram, réseau etc) ai un soucis. Cela peut toucher aussi bien les données de l’hyperviseur que les graphs des VMs. Les graphs restent alors complètement vides. Si cela se produit, commencez par vérifier que le serveur est bien à la bonne heure. Si le problème ne vient pas de la, le plus simple est de tout ré-initialiser. En effet,
les données de ces graphiques sont enregistrées dans des bases de données circulaires qui peuvent se corrompre en cas d’arrêt imprévu par exemple. Pour tout supprimer :

rm /var/lib/rrdcached/db/pve2-node/*
rm /var/lib/rrdcached/db/pve2-storage/*
rm /var/lib/rrdcached/db/pve2-vm/*

Normalement cela doit suffire pour que tout reparte correctement dans l’IHM (patientez évidement au moins 5 ou 10 minutes pour que de nouvelles données soient enregistrées). Si cela ne suffisait pas, il est aussi possible de relancer le service concerné:

systemctl restart pvestatd

Augmenter la taille d’un disque à chaud

Dans cet exemple nous allons augmenter la taille du disque système (disque unique) d’une VM ayant l’id 200. Ce disque ne contient qu’une seule partition, utilisée pour le / de la VM.

On commence par vérifier le nom du contrôleur disque (normalement scsi0 dans ce cas) avec la commande :

qm config 200

On décide d’augmenter la taille du disque de 4 Go:

qm resize 200 scsi0 +4G

Vous pouvez aller vérifier dans la VM (via la commande « dmesg » sous linux), que l’OS à bien détecté le changement de taille. Il ne reste plus qu’a étendre la partition, puis le système de fichier. Sous parted, indiquez une nouvelle fin à 100%. L’extension du système de fichier ensuite prendra par défaut l’ensemble de l’espace disponible:

apt install parted  #Installez parted si ce n'est pas déjà fait
parted /dev/sda

(parted) resizepart
Partition number? 1
Warning: Partition /dev/sda1 is being used. Are you sure you want to continue?
Yes/No? Yes
End? [17,2GB]? 100%
(parted) p
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sda: 21,5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1049kB 21,5GB 21,5GB primary ext4 boot

#Quitter parted avec q.

Maintenant que la partition est bien étendue à l’ensemble du disque, il ne vous reste plus qu’a étendre le système de fichier qu’elle contient:

resize2fs /dev/sda1

Et c’est terminé ! Vous venez d’augmenter la taille du disque système de la VM entièrement à chaud 🙂

Supprimer l’avertissement concernant la licence/support

Proxmox est complètement libre. Vous pouvez l’installer ou vous voulez, faire ce que vous voulez avec et utiliser l’ensemble de ses fonctionnalités sans débourser un centime. Mais les développeurs ont aussi besoin d’argent pour vivre et continuer le développement.

Par défaut, les installations sans licences font donc apparaître, au moment de la connexion à l’interface graphique un petit bandeau d’information pour rappeler qu’aucune licence n’a été achetée pour cette plateforme, et que vous n’aurez pas d’autre support que la bonne volonté de la communauté en cas de soucis etc. Je comprend parfaitement la démarche, et j’invite tous les admins sys de la planète (surtout ceux qui bossent dans des grosses structures et qui utilisent du libre) à pousser leur hiérarchie à l’achat de licence. Mais parfois ce n’est pas possible. Et l’affichage systématique de ce rappel devient vite pénible. Alors supprimons le:

cd /usr/share/javascript/proxmox-widget-toolkit
cp proxmoxlib.js proxmoxlib.js.bak  # sauvegarde rapide "au cas ou"

Il faut maintenant éditer le fichier proxmoxlib.js avec l’éditeur de votre choix (nano, vi…) Cherchez une ligne qui ressemble à ceci :

if (data.status !== 'Active') {

ou même à cela:

 if (res === null || res === undefined || !res || res
.data.status !== 'Active') {

Tout ce qui ce trouve dans le « alors » de ce test concerne l’avertissement de sécurité. L’idée est donc de bypasser totalement ce test en faisant en sorte qu’il ne se vérifie jamais. L’avertissement ne sera donc jamais affiché. Remplacez donc l’ensemble de ce if par:

if (false) {

Il ne reste plus qu’a relancer un service de proxmox (et peut etre aussi à vider le cache de votre navigateur):

systemctl restart pveproxy.service

Voila, adieu l’avertissement.

Réduire l’espace occupé au strict nécessaire

Lorsque vous créez vos machines virtuelles, n’oubliez pas de cocher la case « Discard » dans la section consacrée au disque dur:

Au contraire, n’hésitez pas à décocher la case « Backup » si vous ne souhaitez pas sauvegarder cette VM, ou si il s’agit d’un disque supplémentaire (pas le disque système de la VM donc) non destiné à des données importantes.

A partir du moment ou la case « Discard » est cochée, vous pourrez toujours réduire l’espace occupé par le disque dur virtuel au strict minimum, même si il à été précédemment utilisé à 100% avant qu’il y ai suppressions de fichiers par exemple. Pour cela, il vous suffit de lancer, directement dans la machine virtuelle la commande magique suivante :

fstrim -av

Cette commande vous indiquera combien d’espace vous venez de récupérer. La vérification est simple à partir de l’hyperviseur, avec la commande : lvs -a (si vous utilisez un stockage en LVM bien sur). Il vous suffit de regarder la différence avant/après au niveau de la colonne « Data% »