Transformation d'une machine physique Gnu/Linux vers VMware
Par Yannick le jeudi, 4 décembre 2008, 23:45 - GNU/Linux - Lien permanent
Juste un retour d'expérience...
J'ai eu besoin de transformer un serveur physique avec une Ubuntu, en serveur sous VMware. (Ce n'est pas moi qui choisi.. pas de trolls svp ;) )
A priori, le soft VMware pour faire cela ne fonctionne que si la source est un OS Windows, et des outils comme liveview semblent avoir un un support Gnu/Linux partiel.
J'ai donc voulu tenter d'abord avec l'utilisation d'un simple dd et cela semble avoir parfaitement fonctionné.
J'avais lu l'article de Sp4rKy sur u-classroom et je l'ai un peu adapté...
Pour ne pas avoir à refaire depuis le début en cas d'échec, je suis passé par une image intermédiaire.
Comme le serveur physique n'avais pas de port USB pour copier sur un disque externe, j'ai fait le transfert par le réseau.
La procédure suivante devrait donc pouvoir être simplifiée dans d'autres cas de figure, pour directement copier d'un disque vers l'autre sans passer par une image intermédiaire.
- Backup
Sur la machine intermédiaire qui recoit l'image, tout ce qui arrive sur le port 9000 sera copié dans un fichier sur le disque USB:
nc -l -p 9000 | dd of=/media/disk/imageSrv
Boot du serveur à cloner sur un liveCD, puis copie du disque vers la machine intermédiaire 1.1.1.1:
dd if=/dev/sda | nc 1.1.1.1 9000
Après quelques heures, on obtient l'image brute:
ll /media/disk/imageSrv
-rw-rr1 user user 136G 2048-10-10 10:10 /media/disk/imageSrv
- Restauration dans VMware
Boot de la VM sur un liveCD, tout ce qui arrive sur le port 9000 sera copié sur le disque:
nc -l -p 9000 | dd of=/dev/sda
Depuis le poste qui contient l'image brute, on envoi l'image vers la VM 2.2.2.2:
dd if=/media/disk/imageSrv | nc 2.2.2.2 9000
Après quelques heures, on n'a plus qu'à rebooter en croisant les doigts.
- Divers
A priori, le seul problème rencontré, est le réseau qui ne montait pas, voici les explications:
La carte réseau étant désormais virtuelle, avec une nouvelle MAC, Ubuntu a attribué à la nouvelle carte, le nouveau nom eth1.
Vu que dans /etc/interfaces, seule eth0 était déclarée, il n'y avais donc pas d'ip pour ma nouvelle interface eth1.
Il suffit alors de supprimer la référence AncienneMAC <-> Eth0 dans le fichier /etc/udev/rules.d/70-persistent-net.rules et de rebooter pour que la nouvelle MAC puisse se caler sur eth0. (Sinon au lieu de rebooter, il semble que l'on puisse corriger le fichier, couper networking, restarter udev, démarrer networking)
Si le liveCD contient cryptcat, il faut l'utiliser à la place de netcat afin de chiffrer les transferts.
Commentaires
Bravo. Excellent article. Je me demandais comment virtualiser une vieille passerelle SMTP tournant sous debian, je crois avoir trouvé ici ma réponse.
Par contre c'est qu'elle type d'infrastructure VMware ? (serveur,ESX ?)
Par ailleurs, cela :
<i>Il suffit alors de supprimer la référence AncienneMAC <-> Eth0 dans le fichier /etc/udev/rules.d/70-persistent-net.rules</i>
est très utile par la suite quand on exporte puis importe des VM (du moins dans ESX)
Le dd over ethernet c'est pas mal, par contre c'est long (en lan faut eviter la compression on perd trop de temps cpu).
Je lui prefere le rsync over ssh. En gros il faut booter sur un live cd ubuntu et recreer les partitions sur le HD, puis lancer un rsync de tout sauf /proc. Enfin reinstaller grub.
Très bon article.
J'ai été exposé à un cas de figure similaire. Comme tu le dis l'opération est possible sans passer par une image intermédiaire. Il est même possible d'effectuer le clonage à chaud sans arrêter le serveur qui doit être cloné (bien sûr c'est un peu brutal et ça ne garantit pas la cohérence de données, mais pour cloner rapidement un serveur de prod sur un serveur de dev, c'est une option intéressante).
Il est aussi possible de cloner uniquement la partition qui nous intéresse (ex: /dev/sda1) mais dans ce cas la partition destination doit occuper exactement le même espace.
Enfin, dans mon cas, j'ai du faire quelques modifications supplémentaires :
_ Recompil du noyau sur le serveur destination pour inclure le support du "matériel" VMware.
_ Changement de l'IP.
_ Quelques modifications supplémentaires dans les rares fichiers de conf où l'IP est en dur.
Merci pour vos commentaires
feilong > Dans mon cas c'est effectivement de l'ESX.
phx> Comment tu fais pour le /proc cible ?
Vince > As tu testé par toi meme le dd a chaud ? Tu confirmes que ca a fonctionné pour toi ?
J'ai testé par moi-même avec succès. Le contexte était le suivant :
Disque source : un disque physique.
Disque destination : un disque virtuel d'une machine VMware, de même capacité.
Le disque source a été cloné à chaud pendant que la machine VMware destination était bootée avec un rescue CD (donc à froid).
Après, comme je l'ai déjà dit, cela ne garantit en rien la cohérence des données d'origine sur le disque destination. Dans mon cas, la destination était un serveur de dev, ce qui ne me crée pas d'états d'âmes si quelques fichiers sont incohérents.