Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:lvm_snapshot [2016/12/23 20:43] – [Créer/supprimer un volume] zatalyz
+++ fr:lvm_snapshot [2023/06/19 07:42] (Version actuelle) – Erreur pour refaire un snapshot zatalyz
@@ Ligne 34: / Ligne 34: @@
 Si le volume est à utiliser pour du stockage, il faut le formater et lui attribuer un système de fichier :
   mkfs.ext4 /dev/NOM_VG/NOM_LV
+Vérifier que tout va bien en la montant :
+  mkdir /mnt/lv
+  mount /dev/NOM_VG/NOM_LV /mnt/lv
+L'ajouter dans le système où elle sera montée (donc depuis une VM si ce n'est pas depuis le système hôte, et dans ce cas ce sera ''/dev/xvdXX''), dans /etc/fstab pour que ce soit monté au démarrage :
+  /dev/NOM_VG/NOM_LV /mnt/lv ext4 defaults 0 2
 Pour supprimer un volume, s'assurer qu'il est démonté, puis simplement :
@@ Ligne 46: / Ligne 55: @@
 Il faut que la taille du volume soit en rapport avec la table de partition du volume.
-==== lvextend ====
+==== lvextend : augmenter ====
 On commence par augmenter la taille du volume. On peut soit dire combien on veut ajouter (''--size'', soit donner tout de suite la taille finale à laquelle on veut arriver (''-size'') :
@@ Ligne 76: / Ligne 85: @@
   * http://www.microhowto.info/howto/increase_the_size_of_an_ext2_ext3_or_ext4_filesystem.html
-==== lvresize ====
+==== lvresize : augmenter ou réduire ====
-<WRAP center round important 60%>
+''lvresize'' est plus puissant car il permet d'étendre ou de réduire. Mais si on réduit en dessous du dernier bit utilisé sur le volume, on va avoir droit à un volume corrompu((C'est ce qui s'est passé à mon dernier test, donc <wrap hi>sauvegardez ce qu'il y a sur le volume avant.</wrap> Mais je ne connaissais pas toutes ces options)).
-Bien que la proposition suivante soit dans la doc d'Ubuntu, il me semble que l'appliquer bêtement va créer des soucis.
-''lvresize'' est plus puissant car il permet d'étendre ou de réduire. Mais si on réduit en dessous du dernier bit utilisé sur le volume, on va avoir droit à un volume corrompu. C'est ce qui s'est passé à mon dernier test, donc <wrap hi>sauvegardez ce qu'il y a sur le volume avant.</wrap>
+Il faut d'abord réduire la taille du système de fichier, puis réduire la partition elle-même, sans quoi la partition se corrompt.
-</WRAP>
+Si la partition est en ext2, 3 ou 4, on utilise resize2fs.
+Pour connaître la taille minimale de la partition :
+  resize2fs -P /nom/de/la/partition
+Pour réduire à 50G par exemple :
+  resize2fs /nom/de/la/partition 50G
 Utiliser ''lvresize'' (dans l'exemple, on réduit à 100Go) :
-  lvresize -L 100g /dev/mapper/svg-ca
+  lvresize -r -L 100g /dev/mapper/svg-ca
+En théorie, avec l'options -r, pas besoin de faire ''resize2fs'' avant, ''lvresize'' s'occupera de redimensionner le système de fichier puis ensuite la partition. L'option -L indique la taille finale que l'on souhaite obtenir.
 <WRAP center round important 90%>
 Pourquoi sur "mapper" ?
-> Avec LVM en version 1, c'est bien /dev/mvg/Vol1 qui aurait été affiché. Depuis la version 2, LVM utilise le périphérique mapper, ce qui permet pas mal de choses (comme chiffrer les volumes logiques, etc.). Pour simplifier, disons que ces deux notations « /dev/mvg/Vol1 » et « /dev/mapper/mvg-Vol1 » sont synonymes. Dans la pratique, il est conseillé quand même d'utiliser plutôt la forme « /dev/mvg/Vol1 », certaines commandes ne passeront pas autrement. \\ //Source : [[https://doc.ubuntu-fr.org/lvm#systeme_de_fichiers|Ubuntu]]//
+> Avec LVM en version 1, c'est bien /dev/mvg/Vol1 qui aurait été affiché. Depuis la version 2, LVM utilise le périphérique mapper, ce qui permet pas mal de choses (comme chiffrer les volumes logiques, etc). Pour simplifier, disons que ces deux notations « /dev/mvg/Vol1 » et « /dev/mapper/mvg-Vol1 » sont synonymes. Dans la pratique, il est conseillé quand même d'utiliser plutôt la forme « /dev/mvg/Vol1 », certaines commandes ne passeront pas autrement. \\ //Source : [[https://doc.ubuntu-fr.org/lvm#systeme_de_fichiers|Ubuntu]]//
 </WRAP>
@@ Ligne 111: / Ligne 128: @@
 </WRAP>
-Avant de créer un snapshot, il faut s'assurer qu'il aura ce qu'il faut d'espace. Pas besoin de le faire aussi gros que le volume d'origine ! Le plus simple est de vérifier la taille du volume d'origine avec ''df'' ou ''ncdu'' et de compter un peu plus de place.
+Avant de créer un snapshot, il faut s'assurer qu'il aura ce qu'il faut d'espace. Pas besoin de le faire aussi gros que le volume d'origine ! Le plus simple est de vérifier la taille du volume d'origine avec ''df'' ou ''ncdu'' (depuis la VM, pas depuis l'hyperviseur) et de compter un peu plus de place.
 <code># df -h
@@ Ligne 118: / Ligne 135: @@
 </code>
-Donc, ici, prévoir un snapshot de 5Go sera largement assez pour démarrer.
+Donc, ici, prévoir un snapshot de 10Go sera largement assez pour démarrer.
-  lvcreate -L 5g -s -n lv_test_20110617 /dev/volume_groupe/lv_test
+  lvcreate -L 10g -s -n lv_test_20110617 /dev/volume_groupe/lv_test
 Va créer un snapshot du LV "lv_test" à la taille de 10Go qui va avoir comme nom "lv_test_20110617". Attention, la taille d'utilisation du snapshot évolue avec l'utilisation. Si ce snapshot se retrouve rempli à 100%, il devient alors inutilisable (état "INACTIVE") mais pas d’inquiétude car il n'y a pas d’impact pour le LV d'origine((Source : [[https://doc.ubuntu-fr.org/lvm#snapshot]])). <wrap important>
@@ Ligne 127: / Ligne 144: @@
 Lien : https://wiki.archlinux.org/index.php/LVM#Snapshots
-Lors de la création d'un volume logique, l'option -s créé un snapshot d'un volume existant. Il est conseillé de lui donner une taille de 10% du disque initial.
+Lors de la création d'un volume logique, l'option -s créé un snapshot d'un volume existant.
 Un snapshot conserve toutes les modifications apportées au LV d'origine, afin de pouvoir les rejouer à l'envers, soit à la volée si on utilise le snapshot comme périphérique, soit lors d'un merge. Ansi il est vide au départ et se remplit au fur et à mesure que des modifications sont apportées au LV d'origine.
+<WRAP center round tip 90%>
+Si le volume logique est utilisé pour une VM, il vaut mieux éteindre la VM, faire le snapshot, puis rallumer la VM. Cela évitera d'avoir des incohérences lié à ce qui est stocké dans la RAM, le cache disque etc... De même, si une écriture se fait durant le snapshot, cela pourrait amener des incohérences.
+Cela reste un risque faible (le snapshot est relativement rapide) mais éteindre la VM évitera de potentiels problèmes.
+</WRAP>
+==== Utilisation du snapshot pour cloner une VM ====
 Ici je vais expliquer comment dupliquer une VM en utilisant des snapshots pour réduire le temps d'inactivité. Le cas pratique est la copie de Lirria pour faire Spofu.
-==== Création du snapshot ====
+=== Création du snapshot ===
 La création du snapshot sert pour deux raisons :
@@ Ligne 148: / Ligne 174: @@
 La création du snapshot prenant quelques secondes, la VM est arrêté moins d'une minute.
-==== Copie du LV ====
+=== Copie du LV ===
 Le snapshot contenant l'état du LV figé au moment de sa création, il suffit de le copier, on peut utiliser dd sur une partition de même taille que la partition d'origine.
@@ Ligne 166: / Ligne 192: @@
 La dernière commande étant très longue, on peut aller faire autre chose.
-==== Création de la VM ====
+=== Création de la VM ===
 On va reprendre la configuration et les données de lirria, en modifiant ce qui est nécessaire, à savoir l'adresse IP, et le nom. Que ce soit le nom d'hôte dans la VM, ou le nom de la VM dans XEN.
@@ Ligne 200: / Ligne 226: @@
 </WRAP>
+==== Alternative : copier le clone sur un autre serveur ====
+<WRAP center round important 60%>
+En cours de test. Copier une VM est très long, ce n'est pas forcément la façon la plus rapide de procéder, mais parfois, c'est utile.
+</WRAP>
+Une fois le snapshot créé, le copier (= en faire un clone) pour pouvoir relancer la VM de base rapidement.
+Dans l'exemple ici, on va cloner liria pour en faire spofu, et envoyer spofu sur un autre serveur.
+On commence par éteindre liria, faire son snapshot, puis copier ce dernier (sur le même disque dur) avant de relancer liria. Copiez avec ''dd'' avant de relancer liria, sinon le snapshot va enregistrer les modifications et c'est le bazar. Copiez tout le volume ; même si, techniquement, un snapshot plus petit (avec uniquement les données écrites) devrait aussi marcher, nos tests n'ont pas été concluants. Pensez bien à créer le volume logique sur le serveur de destination //avant// de commencer le transfert, sinon il peut y avoir des erreurs pour "manque de place" (même s'il a y a la place).
+Sur le serveur de destination (nuxru), on prépare l'arrivée :
+  screen -DR
+  lvcreate -L 50G -n spofu-disk groska
+  lvcreate -L 4G -n spofu-swap groska
+  mkswap /dev/nuxru/spofu-swap
+Sur le serveur d'origine (groska) :
+  screen -DR
+  xl shutdown lirria
+  lvcreate -s -L 50G -n liria-disk-snap /dev/groska/liria-disk
+  lvcreate -L 50G -n spofu-disk groska
+  dd if=/dev/groska/liria-disk-snap of=/dev/groska/spofu-disk
+  xl create /etc/xen/liria.cfg
+Ensuite, on vérifie que nos deux serveurs peuvent [[fr:ssh#se_connecter_sans_mot_de_passe_methode_non_securisee|communiquer via ssh]], on installe ''pv'' si ce n'est pas fait (cela permet de suivre la progression de l'échange).
+La commande suivante est à exécuter depuis le serveur primaire vers le serveur secondaire (toujours sous screen ou tmux pour qu'une déconnexion ssh ne casse pas la commande) :
+  dd if=/dev/groska/spofu-disk bs=4096 | pv | ssh root@192.168.0.20 dd of=/dev/nuxru/spofu-disk bs=4096
+Il faut ensuite vérifier que le transfert s'est bien passé et donc comparer le checksum des deux volumes :
+  md5sum /dev/groska/spofu-disk
+  md5sum /dev/nuxru/spofu-disk
+Le swap a été créé plus haut ; il suffit de copier le fichier ''/etc/xen/liria.cfg'' sur le nouveau serveur, sous le nom ''spofu.cfg'', en adaptant le chemin pour les partitions et, si besoin, le réseau. Lancer ensuite la vm.
+  xl create -c /etc/xen/spofu.cfg
 ==== Autre usage des snapshots : utilisation du merge ====
@@ Ligne 212: / Ligne 276: @@
 Le snapshot, devenu inutile, est détruit dans l'opération.
+==== Problèmes divers ====
+=== LVS liste des disques qui ont disparus ===
+Cas typique : vous voulez lancer une VM avec Xen et la réponse ressemble à ça :
+<code># xl create /etc/xen/etherpad2.cfg
+Parsing config from /etc/xen/etherpad2.cfg
+libxl: error: libxl_device.c:381:libxl__device_disk_set_backend: Disk vdev=xvda2 failed to stat: /dev/nuxru/etherpad2-disk: No such file or directory
+libxl: error: libxl_create.c:946:initiate_domain_create: Unable to set disk defaults for disk 0
+libxl: error: libxl.c:1575:libxl__destroy_domid: non-existant domain 2
+libxl: error: libxl.c:1534:domain_destroy_callback: unable to destroy guest with domid 2
+libxl: error: libxl.c:1463:domain_destroy_cb: destruction of domain 2 failed
+</code>
+La commande ''lvs'' liste pourtant bien ceci :
+<code>  LV                        VG    Attr       LSize   Pool Origin         Data%  Meta%  Move Log Cpy%Sync Convert
+  etherpad2-disk            nuxru owi-aos---  25.00g
+  etherpad2-swap            nuxru -wi-a-----   1.00g
+  etherpad2_snap_2019-05-07 nuxru swi-a-s---  25.00g      etherpad2-disk 79.15
+  etherpad2_snap_2020-02-20 nuxru swi-a-s---  25.00g      etherpad2-disk 0.00
+</code>
+(Ici notre groupe de volumes logique s'appelle nuxru, et la VM "etherpad" ne répond plus).
+Pourtant, un ''ls'' sur le groupe logique montre qu'il manque des disques :
+<code># ls -l /dev/nuxru/
+total 0
+lrwxrwxrwx 1 root root 7 Feb 20 11:19 etherpad2-swap -> ../dm-9
+</code>
+Il y a encore le swap... mais pas le disque ou les snapshots.
+Ici, la commande ''dmsetup ls'' est notre alliée :
+<code># dmsetup ls
+nuxru-etherpad2_snap_2020--02--20-cow	(254:14)
+nuxru-etherpad2--disk	(254:11)
+nuxru-etherpad2_snap_2020--02--20	(254:15)
+nuxru-etherpad2_snap_2019--05--07	(254:13)
+nuxru-etherpad2_snap_2019--05--07-cow	(254:12)
+nuxru-etherpad2--disk-real	(254:10)
+nuxru-etherpad2--swap	(254:9)
+</code>
+<WRAP center round info 60%>
+''dmsetup ls'' va lister des volumes utilisés et à quoi ils correspondent. On trouve aussi ces volumes quand on fait ''ls /dev/'', tout ce qui commence par "dm-" : ce sont nos volumes utilisés par LVM.
+</WRAP>
+Le deuxième chiffre entre parenthèse correspond à celui du "dm" qu'on cherche. Par exemple, ici, on cherche où est passé la partie "disk" : c'est //nuxru-etherpad2--disk (254:**11**)// ce qui correspond à ///dev/dm-**11**//
+En cas de doute, on peut monter temporairement le disque en question :
+<code>mkdir /media/test
+mount /dev/dm-11 /media/test
+ls /media/test/home/etherpad
+umount /media/test</code>
+Il reste à refaire le lien symbolique (reprenez bien le terme listé dans lvs) :
+<code>
+cd /dev/nuxru/
+ln -s ../dm-11 etherpad2-disk</code>
+Il faut aussi remettre les snapshots en place, qui ont sauté aussi à cette occasion. Ici, il y a une subtilité, car nous avons deux dm qui peuvent correspondre pour la même date (attention c'est dans le désordre quand tout est listé) :
+<code>nuxru-etherpad2_snap_2020--02--20-cow	(254:14)
+nuxru-etherpad2_snap_2020--02--20	(254:15)
+nuxru-etherpad2_snap_2019--05--07	(254:13)
+nuxru-etherpad2_snap_2019--05--07-cow	(254:12)</code>
+Il ne faut pas faire un lien vers les volumes se terminant en ''-cow'', mais sur les autres (et toujours faire attention à la façon dont c'est noté !).
+<code>
+ln -s ../dm-15 etherpad2_snap_2020-02-20
+ln -s ../dm-13 etherpad2_snap_2019-05-07
+</code>
+Après ça, la VM peut être relancée.
+<WRAP center round important 60%>
+Attention, si le lien vers un volume logique a sauté, ce ne sera probablement pas le seul. Vérifier la concordance entre tous les volumes listés dans ''lvs'' et ceux réellement liés dans ''ls -l /dev/nuxru''.
+</WRAP>
+Si jamais vous avez des disques listés comme "real", comme dans l'exemple ci-dessous, liez vers le dm sans ce "real" :
+<code># dmsetup ls
+nuxru-kuckla--disk	(254:4)
+nuxru-kuckla--disk-real	(254:3)
+nuxru-kuckla--swap	(254:2)</code>
+<code>#ls -l
+total 0
+lrwxrwxrwx 1 root root 7 Feb 20 11:19 kuckla-disk -> ../dm-4
+lrwxrwxrwx 1 root root 7 Feb 20 11:19 kuckla-swap -> ../dm-2</code>
+Donc, s'il y avait besoin, ce serait ''ln -s ../dm-4 kuckla-disk'' (et on oublie le dm-3).
+=== Impossible de refaire un snapshot ===
+Après un merge, et malgré un reboot, il y a parfois un souci, et l'erreur suivante apparait lorsqu'on tente de refaire un snapshot du volume :
+  Snapshots of an origin that has a merging snapshot are not supported.
+''lvs'' monntre un pourcentage de "data" sur le volume qu'on tente de faire en snapshot, alors que ce n'est pas un snaphot.
+Cela viendrait d'une incohérence dans le potage. Pour corriger ça, une petite mise à jour des données de LVM via
+  lvchange --refresh <<VG_NAME>>
+Cette fois ''lvs'' va montrer les volumes correctement, et le snapshot est possible.