Outils personnels

Transférer LVM sur RAID dans une VM : Différence entre versions

De wikiGite

(Résolution)
(Résolution)
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 (chargeur de démarrage) 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). On commence donc par renommer le Volum Group existant.
 
  vgrename VolGroup00 VolGroup99
 
  vgrename VolGroup00 VolGroup99
  

Version du 28 janvier 2011 à 09:47

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.

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 a un 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.

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.

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. 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). 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 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. ça marche !