Skip to content

GitLab

Last edited by zorun
Page history

Administration Proxmox

Création de VM

Voir la page dédiée.

Création d'un template d'OS

Le principe est d'installer un OS assez minimal (sans interface graphique) et de le transformer ensuite en template. Ce template pourra être "cloné" à volonté pour produire autant de VM que nécessaire.

Pour cela, il faut commencer par créer une machine virtuelle manuellement.

Choisir un nom de VM explicite avec l'OS et la version, par exemple : template-debian10. Ca pourra être renommé plus tard si besoin.

Pour le matériel, choisir :

  • ISO : l'image CD de l'OS souhaité (il faut l'avoir uploadé avant)
  • CPU : 1
  • RAM : 2 GB
  • Disque : 40 GB sur stockage "fast", activer discard

Pour le réseau, choisir le VLAN 2131 dans le bridge vmbr0, désactiver le firewall.

Démarrer la VM : elle devrait booter sur le CD.

Configurer le réseau de la VM en statique, avec l'IP réservée pour les templates : 193.23.164.131. Selon l'OS, il pourra être nécessaire d'utiliser la configuration réseau alternative. Cette configuration est uniquement nécessaire pour l'installation de l'OS : la configuration finale sera écrite par cloud-init.

Partitionner le disque avec une unique partition qui prend tout le disque, en ext4. Cela permettra de facilement étendre la partition pour les VM qui veulent davantage de stockage. Ne pas mettre de swap.

Ne pas mettre de mot de passe root (ce qui désactive le compte root), et créer un utilisateur gresille avec les droits sudo. Pour le mot de passe, mettre un mot de passe aléatoire, il sera écrasé par cloud-init lors de l'instantiation de VM.

Choisir le miroir standard pour l'OS (pour Debian : deb.debian.org). Installer un OS relativement minimal (pas d'interface graphique), avec un serveur SSH. Pour Debian, choisir aussi utilitaires usuels du système.

A la fin de l'installation, la VM reboote sur le système. Se logguer en SSH ou sur la console.

Installer les paquets cloud-init et cloud-guest-utils. Le premier permet de configurer la VM depuis proxmox (réseau, mot de passe). Le second contient l'utilitaire growpart qui permet facilement d'agrandir la partition à l'intérieur de la VM.

Eteindre la VM, supprimer le lecteur CD dans Hardware. Ajouter un disque cloud-init dans la page Hardware. Dans la page cloud-init, configurer comme pour une VM normale : utilisateur gresille, mot de passe aléatoire ou clé SSH, serveur DNS 100.100.100.100, puis configuration réseau (IP 193.23.164.131/32 et gateway 100.100.100.100). Cliquer sur "Regenerate Image".

Démarrer de nouveau la VM, et vérifier que le réseau est bien configuré. Il devrait y avoir une alerte SSH parce que la clé hôte a été changée par cloud-init, c'est normal.

Diminuer le timeout de grub dans /etc/default/grub : par défaut c'est 5 secondes, passer à 1 seconde. Lancer update-grub.

Activer les mises à jour automatiques de paquet. Pour Debian :

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades  # Répondre Yes

Activer le service régulier fstrim qui dit à ZFS de libérer la place prise par les fichiers supprimés. Pour Debian :

sudo systemctl enable fstrim.timer

Nettoyer le système :

sudo apt autoremove  # Désinstalle les paquets inutiles
sudo apt clean       # Supprimer les paquets .deb téléchargés
sudo fstrim -av      # Libère l'espace inutilisé dans ZFS

Eteindre la VM et la convertir en template dans l'interface proxmox (clic droit dans la VM dans le bandeau de gauche).

Dans Options, mettre "Start at boot" à "Yes".

Et voilà, le template est prêt à être utilisé !

Mise à jour d'un template d'OS

Partir d'un template existant :

  • cloner le template pour en faire une VM (faire un "Full Clone")
  • configurer cloud-init avec l'IP réservés aux templates (193.23.164.131/32 + gateway 100.100.100.100), ainsi qu'un mot de passe aléatoire pour l'utilisateur gresille (voir installation par template)
  • vérifier dans "Hardware" que le VLAN associé à la carte réseau est bien 2131
  • démarrer la VM
  • s'y connecter en SSH : ssh gresille@193.23.164.131, ou pire par la console sur l'interface proxmox. Si on s'est déjà connecté à un autre template sur la même IP, il faudra supprimer l'entrée dans known_hosts.
  • normalement, cloud-init met à jour la machine au boot : vérifier que c'est bien le cas, faire les mises à jour si besoin
  • faire les modifs voulues
  • faire un apt autoremove pour désinstaller les paquets inutiles
  • faire un apt clean pour supprimer les .deb téléchargés
  • lancer un fstrim avec fstrim -av ou systemctl start fstrim.service pour libérer la place des fichiers supprimés
  • éteindre la VM et la convertir en template dans l'interface proxmox
  • supprimer l'ancien template
  • renommer le nouveau template pour qu'il ait le même nom que l'ancien template.

Migration à chaud d'une VM

Explications

But : déplacer une VM d'un hyperviseur à l'autre, sans éteindre la VM

Avantages :

  • c'est complètement transparent pour la VM, elle reste allumée lors de la migration (pas de coupure)
  • on peut migrer la VM vers un pool de stockage différent (par exemple d'un pool HDD vers un pool SSD). Attention, l'intégralité de l'espace disque alloué sera copié dans ce cas, cf. ci-dessous.

Inconvénients :

  • il faut copier la RAM de la VM, ce qui peut être un peu long selon la quantité de RAM de la VM, son activité, et la vitesse du réseau. Mais vu que la VM reste allumée, ce n'est pas trop gênant.
  • si la VM n'a pas de stockage répliqué : l'intégralité de l'espace disque alloué doit être copié. Une VM avec 100 GB alloué nécessitera de copier 100 GB sur le réseau, même si la VM n'en utilise que 5 GB. Et copier 100 GB, ça va être très long.

Si la VM a un stockage répliqué : Proxmox est intelligent et réutilise la copie de disque existante sur l'hyperviseur de destination. Il va donc uniquement copier ce qui a été modifié depuis la dernière réplication, et ça va aller beaucoup plus vite.

Manipulation

  • Vérifier que la VM est allumée.
  • Vérifier qu'il y a bien une réplication en place, et que la dernière réplication est récente. Regarder vers quel hyperviseur la réplication a lieu.
  • Si il n'y a pas de réplication en place : mettre en place une règle de réplication, et attendre qu'elle finisse. Il est possible de sauter cette étape, la copie sera alors faite en même temps que la migration. Ce sera généralement bien plus long.
  • Vérifier qu'il y a assez de RAM sur l'hyperviseur de destination.
  • Cliquer sur "Migrate" et choisir l'hyperviseur de destination.
  • Suivre la progression

Migration à froid d'une VM

But : déplacer une VM éteinte d'un hyperviseur à l'autre

Avantage :

  • il n'y a pas besoin de copier l'intégralité de la RAM
  • seuls les blocs disques vraiment utilisées sont copiés (si une VM utilise 5 GB sur 100 GB alloués, seuls 5 GB seront copiés)

Inconvénient :

  • la VM subit une coupure le temps de la migration
  • la copie ne peut se faire que vers un pool ZFS du même nom (HDD vers HDD, ou bien SSD vers SSD)

Dans l'ensemble, c'est moins intéressant que réplication + migration à chaud. Ça peut être utile pour des VMs qu'il n'est pas possible d'allumer pour la migration.

Maintenance sur un serveur

Pour bricoler sur un serveur, commencer par migrer toutes les VMs vers un autre hyperviseur.

Mise à jour Proxmox

Pour les mises à jour courante, c'est comme sous Debian, à coup de apt-get.

Pour les mises à jour majeure, c'est plus complexe et il faut suivre les instructions de la doc Proxmox.