Transférer LVM sur RAID dans une VM : Différence entre versions
De wikiGite
(→Résolution) |
|||
(Une révision intermédiaire par un autre utilisateur non affichée) | |||
Ligne 1 : | Ligne 1 : | ||
Quel beau titre ! | Quel beau titre ! | ||
− | Lors de la récupération d'un serveur moribond, transféré dans une machine virtuelle, il a fallu jouer avec les partitions et LVM. | + | Lors de la récupération d'un serveur moribond, transféré illico presto dans une machine virtuelle, il a fallu jouer avec les partitions et LVM. |
Résumé. | Résumé. | ||
Ligne 7 : | Ligne 7 : | ||
== Mort du héros, premières galères == | == Mort du héros, premières galères == | ||
Le serveur meurt un jour de sa belle mort. Pas de problèmes disque, ils sont sains, juste la carte mère qui lâche.<br> | Le serveur meurt un jour de sa belle mort. Pas de problèmes disque, ils sont sains, juste la carte mère qui lâche.<br> | ||
− | Les 2 disques étaient en RAID 1. Au-dessus, on | + | Les 2 disques étaient en RAID 1. Au-dessus, on avait le partitionnement LVM. Plutôt que de remettre les disques dans un serveur identique, on décide de transférer le système dans une machine virtuelle (VMware ou autre, pas de différence). |
− | Les PV (Physical Volums) sont donc déclarés au-dessus des périphériques RAID /dev/md*. C'est ce qui posera problème, entre autres, lorsque l'image sera transférée sur un disque unique, style /dev/sda. | + | Les PV (Physical Volums) sont donc actuellement déclarés au-dessus des périphériques RAID /dev/md*. C'est ce qui posera problème, entre autres, lorsque l'image sera transférée sur un disque unique, style /dev/sda, car les PV vont avoir du mal à retrouver leurs petits (ou, en l'occurence, leurs papas). |
On commence par mettre les disques dans une machine qui fonctionne. On démarre avec un CD live, de type SystemRescue ou Trinity, et on branche un disque USB pour recevoir l'image. Une fois au prompt, on fait une image octet par octet avec dd (c'te pôv' bête) | On commence par mettre les disques dans une machine qui fonctionne. On démarre avec un CD live, de type SystemRescue ou Trinity, et on branche un disque USB pour recevoir l'image. Une fois au prompt, on fait une image octet par octet avec dd (c'te pôv' bête) | ||
dd if=/dev/sda of=/media/usb/sda.dmp | dd if=/dev/sda of=/media/usb/sda.dmp | ||
− | /dev/sda est un des 2 disques du RAID. le disque USB est monté sur /media/usb. | + | /dev/sda est un des 2 disques du RAID. le disque USB est monté sur /media/usb, pour ceux qui n'auraient pas compris. |
− | Une fois la machine virtuelle créée, on la lance également avec le live CD. Si l'hyperviseur ne reconnait pas l'usb (comme c'est le cas pour vmware ESXi), on branche le disque usb sur un autre serveur, on le partage en NFS et on le monte dans la VM par le réseau. | + | Une fois la machine virtuelle créée, on la lance également avec le live CD. Si l'hyperviseur ne reconnait pas l'usb (comme c'est le cas pour vmware ESXi), on branche le disque usb sur un autre serveur, on le partage en NFS et on le monte dans la VM par le réseau. Pfffou. |
On recopie alors l'image sur le disque de la VM | On recopie alors l'image sur le disque de la VM | ||
dd if=/media/nfs/sda.dmp of=/dev/sda | dd if=/media/nfs/sda.dmp of=/dev/sda | ||
Ligne 42 : | Ligne 42 : | ||
On crée un second disque virtuel à côté du premier, même taille, mêmes partitions. Il est reconnu en /dev/sdb. On crée les partitions à l'identique du disque d'origine (une partition sdb1 de 260M pour /boot, qui est à part car il ne peut pas être un volume logique, et sdb2 de type LVM sur le reste). | On crée un second disque virtuel à côté du premier, même taille, mêmes partitions. Il est reconnu en /dev/sdb. On crée les partitions à l'identique du disque d'origine (une partition sdb1 de 260M pour /boot, qui est à part car il ne peut pas être un volume logique, et sdb2 de type LVM sur le reste). | ||
− | Mais il faut que le Volum Group s'appelle VolumGroup00 (car c'est ce qu'attendent Grub et le fstab, au moins). On commence donc par renommer le Volum Group existant. | + | Mais il faut que le Volum Group s'appelle VolumGroup00 (car c'est ce qu'attendent Grub et le fstab, au moins, et on a pas envie de refaire les configs). On commence donc par renommer le Volum Group existant. |
vgrename VolGroup00 VolGroup99 | vgrename VolGroup00 VolGroup99 | ||
Ligne 62 : | Ligne 62 : | ||
Et ainsi de suite pour chaque LV, idem, ainsi que /dev/sda1 (/boot) vers /dev/sdb1. | Et ainsi de suite pour chaque LV, idem, ainsi que /dev/sda1 (/boot) vers /dev/sdb1. | ||
− | On arrête la machine virtuelle, et on déconnecte le premier disque. Le second devient donc /dev/sda lorsqu'on redémarre sur le live CD (on en est pas encore à démarrer sur le disque lui-même). On doit réinstaller le chargeur Grub sur le premier secteur du disque, en utilisant chroot. | + | On arrête la machine virtuelle, et on déconnecte de la VM le premier disque. Le second devient donc /dev/sda lorsqu'on redémarre sur le live CD (on en est pas encore à démarrer sur le disque lui-même). On doit réinstaller le chargeur Grub sur le premier secteur du disque, en utilisant chroot. |
On crée un répertoire /media/sysimage, et on monte chacun des LV dans le bon ordre | On crée un répertoire /media/sysimage, et on monte chacun des LV dans le bon ordre | ||
Ligne 81 : | Ligne 81 : | ||
grub-install /dev/sda | grub-install /dev/sda | ||
− | Reboot. ça marche ! | + | Reboot. Bingo : ça marche ! |
Version actuelle datée du 16 août 2011 à 15:17
Quel beau titre !
Lors de la récupération d'un serveur moribond, transféré illico presto dans une machine virtuelle, il a fallu jouer avec les partitions et LVM.
Résumé.
Mort du héros, premières galères
Le serveur meurt un jour de sa belle mort. Pas de problèmes disque, ils sont sains, juste la carte mère qui lâche.
Les 2 disques étaient en RAID 1. Au-dessus, on avait le partitionnement LVM. Plutôt que de remettre les disques dans un serveur identique, on décide de transférer le système dans une machine virtuelle (VMware ou autre, pas de différence).
Les PV (Physical Volums) sont donc actuellement déclarés au-dessus des périphériques RAID /dev/md*. C'est ce qui posera problème, entre autres, lorsque l'image sera transférée sur un disque unique, style /dev/sda, car les PV vont avoir du mal à retrouver leurs petits (ou, en l'occurence, leurs papas).
On commence par mettre les disques dans une machine qui fonctionne. On démarre avec un CD live, de type SystemRescue ou Trinity, et on branche un disque USB pour recevoir l'image. Une fois au prompt, on fait une image octet par octet avec dd (c'te pôv' bête)
dd if=/dev/sda of=/media/usb/sda.dmp
/dev/sda est un des 2 disques du RAID. le disque USB est monté sur /media/usb, pour ceux qui n'auraient pas compris.
Une fois la machine virtuelle créée, on la lance également avec le live CD. Si l'hyperviseur ne reconnait pas l'usb (comme c'est le cas pour vmware ESXi), on branche le disque usb sur un autre serveur, on le partage en NFS et on le monte dans la VM par le réseau. Pfffou. On recopie alors l'image sur le disque de la VM
dd if=/media/nfs/sda.dmp of=/dev/sda
cette fois la source est le disque usb monté sur /media/nfs/, et la cible le disque virtuel /dev/sda.
Au reboot, malheur : il affiche
Volume group "VolGroup00" not found ... kernel panic !
OK : raté.
Diagnostic
Si on redémarre sur le live CD, on s'aperçoit que les partitions LVM sont visibles. On peut même monter les LV (logical volums) sans erreur. Le seul problème, c'est le PV qui est bizarre
# pvdisplay --- Physical volume --- PV Name /dev/md126 ... ...
La partition n'est plus md0 comme sur l'ancien serveur, mais md126. De toute façon, /dev/md* n'existe pas ici, puisqu'on a pas de RAID. Il est donc normal que le VG ne monte pas.
On ne peut pas, à priori, dire au PV qu'il est maintenant sur /dev/sda1 au lieu de /dev/md0 ou md126, sans devoir le détruire et le recréer, ce qui détruirait les données qu'il contient.
Donc, il faut "refaire l'enveloppe", et y réinjecter les données.
Résolution
On crée un second disque virtuel à côté du premier, même taille, mêmes partitions. Il est reconnu en /dev/sdb. On crée les partitions à l'identique du disque d'origine (une partition sdb1 de 260M pour /boot, qui est à part car il ne peut pas être un volume logique, et sdb2 de type LVM sur le reste).
Mais il faut que le Volum Group s'appelle VolumGroup00 (car c'est ce qu'attendent Grub et le fstab, au moins, et on a pas envie de refaire les configs). On commence donc par renommer le Volum Group existant.
vgrename VolGroup00 VolGroup99
On repère les volumes logiques existant, avec leur taille
lvdisplay
et on recrée les volumes sur le nouveau Volum Group
pvcreate /dev/sdb1 vgcreate VolGroup00 /dev/sdb2 lvcreate -n root -L 4G lvcreate -n swap -L 4G lvcreate -n home -L 36G ....
Et ainsi de suite pour chaque LV.
Puis on transfère LV par LV
dd if=/dev/VolGroup99/root of=/dev/VolGroup00/root dd if=/dev/VolGroup99/home of=/dev/VolGroup00/home ...
Et ainsi de suite pour chaque LV, idem, ainsi que /dev/sda1 (/boot) vers /dev/sdb1.
On arrête la machine virtuelle, et on déconnecte de la VM le premier disque. Le second devient donc /dev/sda lorsqu'on redémarre sur le live CD (on en est pas encore à démarrer sur le disque lui-même). On doit réinstaller le chargeur Grub sur le premier secteur du disque, en utilisant chroot.
On crée un répertoire /media/sysimage, et on monte chacun des LV dans le bon ordre
mount /dev/VolGroup00/root /media/sysimage mount /dev/VolGroup00/home /media/sysimage/home ...
Etc... On oublie pas la partition boot
mount /dev/sda1 /media/sysimage/boot
Pour que le chroot fonctionne, il faut aussi faire un lien de /proc et /dev dans l'espace chrooté
mount -t proc none /media/sysimage/proc mount -o bind /dev /media/sysimage/dev
Il reste à passer en chroot
chroot /media/sysimage
/media/sysimage devient la nouvelle racine du système (/). Vérifier /etc/mtab et /etc/fstab, pour éliminer des références aux anciens volumes ou partitions.
On peut installer Grub sur le disque sda
grub-install /dev/sda
Reboot. Bingo : ça marche !