Proxmox, mise en place

Installation proxmox et mise en route

La configuration matérielle est la suivante :

• une carte reseau gigabit,
• trois disques durs : 2x160G+1x500G
• 8 Go RAM, processeur Intel(R) Core(TM)2 Duo CPU E750

Le processus d’installation ne pose pas de problème particulier. Les paramétrages spécifiques utilisées sont :

• pour le disque d’installation, une option de minfree à 10 Go (pour pouvoir garder la main sur une LVM en cas de saturation de l’espace disque),
• le poste est situé sur un réseau local avec un parefeu qui sert de passerelle et de DNS, ce qui donne comme config reseau :

Une fois le serveur proxmox installé et démarré, commencer par se connecter et lancer une mise à jour :

apt-get update && apt-get upgrade

L’interface d’administration de l’hyperviseur est alors accessible à l’adresse suivante :
https://192.168.37.201:8006

A la fin de l’installation, seul le premier disque de 160 Go /dev/sda est utilisé. Il est partitionné en trois parties :

 Device                          Start                 End            Sectors            Size Type               
/dev/sda1                          34                2047               2014           1007K BIOS boot          
/dev/sda2                        2048              262143             260096            127M EFI System
/dev/sda3                      262144           312581774          312319631          148.9G Linux LVM

La partition LVM est organisé de la façon suivante

• un PV (volume physique) /dev/sda3,
• un VG (volume group) nommé pve,
• les LV (volumes logiques) suivants créé automatiquement par le processus d’installation :

--- Logical volume ---
  LV Path                /dev/pve/swap
  LV Name                swap
  VG Name                pve
  LV UUID                tEyVEd-CUjT-QXco-q6zq-rkTH-inXY-6g69Fy
  LV Write Access        read/write
  LV Creation host, time proxmox, 2017-01-26 14:36:14 +0100
  LV Status              available
  # open                 2
  LV Size                6.00 GiB
   
  --- Logical volume ---
  LV Path                /dev/pve/root
  LV Name                root
  VG Name                pve
  LV UUID                Ood2i0-dXiV-tcgS-GdlF-Syhy-EJTA-CBJ7vR
  LV Write Access        read/write
  LV Creation host, time proxmox, 2017-01-26 14:36:14 +0100
  LV Status              available
  # open                 1
  LV Size                37.00 GiB
   
  --- Logical volume ---
  LV Name                data
  VG Name                pve
  LV UUID                1MmBZq-f187-gPFK-ZPQD-0hmt-uHl0-fcn4DD
  LV Write Access        read/write
  LV Creation host, time proxmox, 2017-01-26 14:36:15 +0100
  LV Pool metadata       data_tmeta
  LV Pool data           data_tdata
  LV Status              available
  # open                 9
  LV Size                 95,92 GiB

Dans l’interface de proxmox, cela se traduit ainsi :

Physiquement :

• local correspond au LV ’root’ de chemin /dev/pve/root,
• local-lvm correspond au LV ’data’ de chemin /dev/pve/data

Dans notre configuration actuelle, on a deux disques inutilisés :

• le second disque de 160Go va être ajouté au volume logique ’data’ pour étendre la capacité de stockage des futurs containers.
• le disque de 500Go va être branché sur le système en tant que répertoire (hors LVM)

Augmentation du LV data contenant les conteneurs

Ajoutons le deuxième disque de 160 Go au volume logique ’data’ aussi visible dans l’interface en tant que ’local-lvm’.

Le disque doit avoir une table de partition, et une partition doit être déclarée. Dans notre cas, cette partition utilise tout le volume disponible du disque. Le formatage n’est pas indispensable. Notre partition ici sera /dev/sdc1. Les opération suivantes se font en ligne de commande (connecté en ssh ou via le shell de l’interface graphique de proxmox)

• création du PV (volume physique) :

  pvcreate /dev/sdc1

• il vous indique qu’il va ’swipper’ la partition existante, répondre oui
• on visualise ce qu’on a sous la main comme volume physique :

root@pve37:~# pvdisplay 
  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               pve
  PV Size               148.93 GiB / not usable 3.82 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              38124
  Free PE               2511
  Allocated PE          35613
  PV UUID               dmbbNf-bzuy-kFng-5RIy-yzFX-JP9G-OekIF4
   
  --- Physical volume ---
  PV Name               /dev/sdc1
  VG Name
  PV Size               149.05 GiB / not usable 2.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              38156
  Free PE               0
  Allocated PE          38156
  PV UUID               ABEV1I-fpmB-jYuG-MHoV-4tPG-Oc04-fqMm2M

• on va maintenant étendre le volume group pour incorporer le nouveau disque
  vgextend pve /dev/sdc1
• dernière étape, étendre le LV (volume logique) ’data’ pour utiliser le nouvel espace disponible :
  lvextend -l +100%FREE /dev/pve/data /dev/sdc1
• on tapant lvdisplay, on observe l’augmentation du volume utile

  --- Logical volume ---
    LV Name                data
    VG Name                pve
    LV UUID                1MmBZq-f187-gPFK-ZPQD-0hmt-uHl0-fcn4DD
    LV Write Access        read/write
    LV Creation host, time proxmox, 2017-01-26 14:36:15 +0100
    LV Pool metadata       data_tmeta
    LV Pool data           data_tdata
    LV Status              available
    # open                 9
    LV Size                244.97 GiB

Supprimer les traces d’un LVM sur un disque

Les manipulations sur les LVM sont délicates et il peut arriver de rendre inutilisable un volume group. Cette expérience malencontreuse que j’ai vécu m’a fait découvrir que supprimer les traces d’un LVM, c’est pas si simple !
En gros, une fois que votre volume groupe ne répond plus, la seule solution est d’effacer tout contenu du disque, je veux dire par la, table de partition comprise !

Booter à partir d’un livecd :

• utiliser la commande ’fdisk /dev/sdx’
• creer une nouvelle table de partition ’o’ puis l’écrire ’w’
• ne surtout pas oublier de rebooter,
• tester un vgdisplay pour vérifier qu’il n’y a pas plus de trace du LVM. Au beosin, créer une partition sur tout le disque et formater-la, reboot et revérification.

Cette expérience malheureuse m’amène aux préconisations suivantes :

• bien gérer les sauvegardes (comme d’hab’ me direz-vous),
• ne pas placer ces sauvegardes sur une LVM commune aux autres objets (containers, vm, ISO, template...), voir préférer utiliser une classique partition mono-disque EXT4.

Ajout d’un répertoire de sauvegarde sur un disque seul

Au vu des mésaventures vécues avec LVM, je suis parti sur l’option de mettre mes sauvegardes sur un espace de stockage avec une partition "classique" en ext4. On va utiliser ici le disque de 500Go visible sur le système en tant que /dev/sdb. Au préalable, ce disque a été initialisé avec une seule partition en ext4, accessible donc en tant que /dv/sdb1.

• Proxmox étant une distribution debian enrichie , on va tout simplement déclarer le disque dans /etc/fstab tel que :
  /dev/sdb1       /mnt/backup     ext4    defaults,noatime,nodiratime,errors=remount-ro   0       1
• Il faut aussi créer le point de montage, et dans la foulée on va monter le disque :

  mkdir /mnt/backup
  mount /mnt/backup

• pour rendre accessible ce volume dans l’interface de proxmox, on va dans "Datacenter->Stockage" et on fait "Ajouter->Répertoire", on remplit les paramètres comme suit :

Le volume est désormais disponible pour les sauvegardes

Ajout d’un disque NFS

Dans le cas ou on dispose d’un serveur NFS sur le même réseau que le noeud proxmox, il est très facile de ’monter’ un partage NFS sur le serveur proxmox, ce qui peut être très intéressant, notamment pour les sauvegardes. Aucune surprise ici, tout peut se passer dans l’interface graphique :

• aller sur datacenter, rubrique stockage
• choisir dans la liste déroulante "Ajouter->NFS"
• indiquer les paramètres de votre partage comme celui-ci en exemple :

Il est à noter que proxmox accède au partage NFS en tant que root, si vous avez des soucis avec la configuration du serveur NFS, c’est du côté de l’autorisation d’accès à root qu’il faut chercher les solutions.

Résumé espaces stockage

A ce stade et avant de "jouer" avec les containers, notre interface nous présente les espaces de stockage suivants :

• backup : espace de stockage des sauvegardes, hors LVM, accessible sur l’OS de proxmox au point de montage /mnt/backup,
• local : contient les LV ’root’, ’swap’, on va y stocker les templates, images ISO, éventuellement des sauvegardes,
• local-lvm : correspond au LV ’data’, il contiendra les containers et vm (images disque),
• serveur37 : le disque NFS que l’on a monté, il nous permettra de faire des backup en dehors de l’ordinateur portant proxmox, il est accessible sur l’OS de proxmox au point de montage /mnt/pve/serveur37

Création de container

Tous les containers créés l’ont été à partir des templates que l’on peut trouver sur turnkeylinux, on trouve également des images de VM (iso). C’est accessible directement dans l’interface de proxmox :

• aller dans "pve->local",
• cliquer sur le bouton template. On télécharge celui qui nous intéresse.

  2017-01-27 12:11:55 (15.8 MB/s) - ’/var/lib/vz/template/cache/debian-8-turnkey-lamp_14.1-1_amd64.tar.gz.tmp.5602’ saved [198934451/198934451]
  download finished
  TASK OK

• une fois le container téléchargé, on clique en haut sur "Créer CT" et on suit les instructions. Le mot de passe à définir est celui de l’utilisateur root du futur container.
  Voici en vidéo le processus entier, création, premier lancement et première mise à jour des paquets du container :

Remarque :
La configuration réseau est spécifique dans cette vidéo. Elle exploite la mise en place d’un bridge permettant de partager une adresse IP publique pour plusieurs containers. Cf article sur la configuration reseau avec proxmox

Une fois que les containers tournent bien, la première chose à bien dominer, c’est les sauvegardes et les copies de container. L’interface graphique permet de facilement faire des sauvegardes, mais dès qu’on va vouloir faire des choses plus complexes, la ligne de commande est votre ami.

Sauvegarde de container

On va sauvegarder le container créé dans la vidéo précédente. On se connecte en ssh sur le serveur proxmox :

ssh -l root 192.168.37.201
vzdump 110 -storage backup -compress lzo

Décryptons :

• 110 : c’est le vmid du container (que ce soit une VM ou un CT, la documentation parle de vmid),
• -storage backup : on indique ici sur quel espace déclaré comme pouvant recevoir les sauvegardes on va utiliser. On utilise ici l’espace créé précédemment monté sur /mnt/backup
• - compress lzo : niveau de compression, voir la doc pour les différentes possibilités
  Voici le retour du shell sur cette commande :

  root@pve37:~# vzdump 110 -storage backup -compress lzo
  INFO: starting new backup job: vzdump 110 --storage backup --compress lzo
  INFO: Starting Backup of VM 110 (lxc)
  INFO: status = running
  INFO: CT Name: ct-lamp-test
  INFO: backup mode: snapshot
  INFO: ionice priority: 7
  INFO: create storage snapshot 'vzdump'
    Logical volume "snap_vm-110-disk-1_vzdump" created.
  INFO: creating archive '/mnt/backup/dump/vzdump-lxc-110-2017_01_27-12_39_30.tar.lzo'
  INFO: Total bytes written: 759439360 (725MiB, 7.9MiB/s)
  INFO: archive file size: 330MB
  INFO: remove vzdump snapshot
    Logical volume "snap_vm-110-disk-1_vzdump" successfully removed
  INFO: Finished Backup of VM 110 (00:01:35)
  INFO: Backup job finished successfully

Ce qui est intéressant ici, c’est d’observer qu’il a utilisé le mode "snapshot" car le container est en cours d’exécution C’est fort pratique de pouvoir sauvegarder en cours d’exécution, mais la documentation insiste sur le fait que çà comporte des risques. Du coup il existe deux autres modes :

• suspend : un peu comme snapshot, mais moins risqué
• stop : arrête le container, évite donc tout risque d’échec. Le container est redémarré à la fin de la sauvegarde.
• Ces modes peuvent être précisé dans la ligne de commande :
  vzdump 110 -storage backup -compress lzo --stop

Restauration de container

Pour restaurer un container sauvegardé comme dans l’exemple précedent, une seule ligne de commande :
pct restore 110 local-lvm /mnt/backup/dump/vzdump-lxc-110-2017_01_27-12_39_30.tar.lzo
Explications :

• 110 : le vmid de destination, il peut être le même que le container que l’on a sauvegardé, auquel cas il s’agit d’une restauration en lieu et place, ou différent, il s’agit alors d’une copie,
• local-lvm : l’espace cible du container, il peut la aussi être égal ou différent de celui de la sauvegarde
• /mnt...39_30.tar.lzo : le chemin du fichier qu’on restaure.

Copie d’un container

Inutile de chercher pendant des heures une commande ’pct clone’ qui marche, comme le dit la documentation, c’est experimental, et je peux le confirmer ! J’ai tout cassé en voulant utiliser cette commande, donc ne vous fatiguez pas, en fait c’est on ne peut plus simple :
pct restore 115 local-lvm /mnt/backup/dump/vzdump-lxc-110-2017_01_27-12_39_30.tar.lzo
Et voilà ! Il suffit de définit un vmid non utilisé dans votre architecture et il créé ce container, copie du fichier de sauvegarde correspondant au container 110.

Redimensionnement d’un container

Agrandir la taille d’un container se fait très facilement via l’interface de proxmox, tout comme modifier la RAM disponible ou la puissance processeur affectée. Mais si pour ces deux éléments RAM et processeur, le retour en arrière est tout aussi simple, pour l’espace disque, il n’est pas possible via l’interface graphique de réduire la taille du disque.
Cette opération délicate se fait en quatre étapes (toujours sur notre container d’exemple identifié ’110’) :

• arrêter le container,
• sauvegarder le container (cf chapitre précédent),
• détruire le container
  pct destroy 110
• restaurer le container de la façon suivante
  pct restore 110 /mnt/backup/dump/vzdump-lxc-110-2017_01_27-12_39_30.tar.lzo --rootfs local-lvm:4G
  On indique avec l’option "—rootfs local-lvm:4G " que la partition root est restauré sur l’espace de stockage "local-lvm" sur 4Go.

Attention ! Cette opération n’est possible que si le volume de données présent sur le container est inférieur à la taille redéfinie, sinon perte de données !